From: short <> Date: Thu, 2 Oct 2003 19:40:58 +0000 (+0000) Subject: a href X-Git-Url: https://git.jankratochvil.net/?a=commitdiff_plain;h=fc5c156b45c59a636966a46a1277e8e42179ccf4;p=www.jankratochvil.net.git a href --- diff --git a/project/captive/doc/APITypes.html.pl b/project/captive/doc/APITypes.html.pl index 0194268..ddc1992 100755 --- a/project/captive/doc/APITypes.html.pl +++ b/project/captive/doc/APITypes.html.pl @@ -52,10 +52,10 @@ print <<"HERE"; - - - - + + + +
Function type ItemsPortion
@{[ a_href '#functype_pass','pass' ]} 81 26%
@{[ a_href '#functype_wrap','wrap' ]} 2 0%
@{[ a_href '#functype_native_reactos','native-ReactOS' ]} 113 36%
@{[ a_href '#functype_native_libcaptive','native-own' ]} 116 38%
@{[ a_href 'APITypes.html.pl#functype_pass','pass' ]} 81 26%
@{[ a_href 'APITypes.html.pl#functype_wrap','wrap' ]} 2 0%
@{[ a_href 'APITypes.html.pl#functype_native_reactos','native-ReactOS' ]} 113 36%
@{[ a_href 'APITypes.html.pl#functype_native_libcaptive','native-own' ]} 116 38%
Function Implementation Types Statistics
@@ -69,8 +69,8 @@ print <<"HERE"; contain already prepared content at the runtime. There is a problem with patched libraries where it is necessary to also fully implement the data symbol as - @{[ a_href '#functype_native','native implementation' ]} since there is no - possibility to @{[ a_href '#functype_pass','pass' ]} the data symbol instead of + @{[ a_href 'APITypes.html.pl#functype_native','native implementation' ]} since there is no + possibility to @{[ a_href 'APITypes.html.pl#functype_pass','pass' ]} the data symbol instead of the original W32 data location and therefore there will be two instances of such data variable place. As there will be also the uncaught references for such W32 data location from the patched @@ -110,8 +110,8 @@ print <<"HERE";

Pass from UNIX Code

Control flow begins in some standard UNIX code. Such code is always - using @{[ a_href '#calltype_cdecl','cdecl call type' ]} for all its - intracalls. Native functions + using @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl call type' ]} for all its + intracalls. Native functions compiled from ReactOS sources use their own @{[ a_href '#calltype','cdecl/stdcall/fastcall' ]} declarations but these call type modifications are discarded during compilation for @@ -184,7 +184,7 @@ print <<"HERE"; will return to the UNIX jump table relay which will debug dump the return value and it will finally pass the control back to the UNIX caller in the standard UNIX - @{[ a_href '#calltype_cdecl','cdecl call type' ]}.

+ @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl call type' ]}.

@{[ doc_img 'fig/functype_patched_pass_fromunix', 'Function Type: pass from UNIX Code' ]} @@ -192,7 +192,7 @@ print <<"HERE";

Pass from W32 Code

This function type is similiar to the - @{[ a_href '#functype_pass_fromunix','previous one' ]} with the exception + @{[ a_href 'APITypes.html.pl#functype_pass_fromunix','previous one' ]} with the exception of more complicated entry point. Unfortunately W32 libraries call their own functions directly, using the call instructions without any patchable jump table. Even the @@ -200,7 +200,7 @@ print <<"HERE"; according to the relocation table record as such library intra-call instruction has no relocation due to its relative argument offset on i386. This time the double-breakpoint - mechanism @{[ a_href '#functype_pass_fromunix','described above' ]} gets + mechanism @{[ a_href 'APITypes.html.pl#functype_pass_fromunix','described above' ]} gets handy since it will catch the entry point when the function gets called. SIGSEGV handler gets invoked by the hlt instruction and it will @@ -222,8 +222,8 @@ print <<"HERE";

The jump table relay used for the callers from W32 code is a different one than the relay being used for the callers - @{[ a_href '#functype_pass_fromunix','from UNIX code' ]}. UNIX code always - uses relay with external @{[ a_href '#calltype_cdecl','cdecl call type' ]} + @{[ a_href 'APITypes.html.pl#functype_pass_fromunix','from UNIX code' ]}. UNIX code always + uses relay with external @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl call type' ]} but in this case a relay with the appropriate @{[ a_href '#calltype','cdecl/stdcall/fastcall call type' ]} is used.

@@ -247,9 +247,9 @@ print <<"HERE";

Wrapping of Call from UNIX Code

The code control flow has no special hardcore features since it is - very similiar to the direct pass to + very similiar to the direct pass to W32 function from UNIX code. All the wrapping is done in the - standard UNIX @{[ a_href '#calltype_cdecl','cdecl call type' ]} manner. + standard UNIX @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl call type' ]} manner. Jump table debug dumping relays are provided twice — the "outer" one to trace the parameters from the function caller and the "inner" one to trace the call from the wrapper to the @@ -263,8 +263,8 @@ print <<"HERE";

Wrapping of Call from W32 Code

This scheme is a combination of the - previous wrap of a call from - UNIX code and the direct pass from + previous wrap of a call from + UNIX code and the direct pass from the W32 code. The control is caught and redirected by SIGSEGV handler from the breakpoint placed at the entry to the original W32 function code. The second entry @@ -279,7 +279,7 @@ print <<"HERE"; @{[ vskip() ]} -

Some functions can be passed to the original +

Some functions can be passed to the original code but they need their parameters to be checked/prepared. Currently, such wrapping is only needed for the ExAllocateFromPagedLookasideList() function @@ -326,7 +326,7 @@ print <<"HERE"; the callee are provided with full source file debug information for the debugger. Also the callee usually debug dumps its entry/exit parameters by custom debug dumps in the - ReactOS implementations. + ReactOS implementations. @{[ doc_img 'fig/functype_native_fromunix', 'Function Type: native from UNIX Code' ]} @@ -356,7 +356,7 @@ print <<"HERE"; code with the appropriate @{[ a_href '#calltype','cdecl/stdcall/fastcall call type' ]} while the relay will call the implementation of the native function in the - standard UNIX @{[ a_href '#calltype_cdecl','cdecl call type' ]} manner.

+ standard UNIX @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl call type' ]} manner.

Native Implementation of "patched" Library Function Called from W32 Code

 @@ -364,12 +364,12 @@ print <<"HERE"; 'Function Type: native of patched from W32 Code' ]}

The calling scheme is similiar to the - previous call of + previous call of unpatched library function from W32 code but the call control is redirected from the entry point of the original W32 binary implementation by the breakpoint and its SIGSEGV handler as in - the case of passing control from W32 + the case of passing control from W32 call.

The original W32 function implementation located in the original @@ -395,7 +395,7 @@ print <<"HERE";

Some functions are already implemented in the $ReactOS project and they can be used as they are. Although it would be - possible to pass some function calls to the + possible to pass some function calls to the original code it is more handy to provide native implementation as there is better control of the data handling during debugging sessions due to the provided debugging symbols.

@@ -415,7 +415,7 @@ print <<"HERE";

Functions that were not possible to - @{[ a_href '#functype_pass','pass' ]} were reimplemented by this project + @{[ a_href 'APITypes.html.pl#functype_pass','pass' ]} were reimplemented by this project and placed in the project's implementation directories @{[ a_href '#reactos_nocare','instead of extending' ]} $ReactOS code.

diff --git a/project/captive/doc/About.html.pl b/project/captive/doc/About.html.pl index 2a8922c..95b20a6 100755 --- a/project/captive/doc/About.html.pl +++ b/project/captive/doc/About.html.pl @@ -128,7 +128,7 @@ print <<"HERE"; Microsoft Windows XP as they are freely downloadable at: @{[ a_href 'http://www.microsoft.com/WindowsXP/pro/downloads/servicepacks/sp1/checkedbuild.asp' ]}

- There may be @{[ a_href '#law','legal reasons' ]} you would not be allowed + There may be @{[ a_href 'Architecture.html.pl#law','legal reasons' ]} you would not be allowed to use there files if you own license to a different version of Microsoft Windows. Legal rights will very depending on your country.

diff --git a/project/captive/doc/CacheManager.html.pl b/project/captive/doc/CacheManager.html.pl index f144239..cc519f1 100755 --- a/project/captive/doc/CacheManager.html.pl +++ b/project/captive/doc/CacheManager.html.pl @@ -155,7 +155,7 @@ print <<"HERE"; Fortunately it is safe to never destroy SharedCacheMap and leave it leaked - everything gets clean in the - @{[ a_href '#sandbox','sandboxed environment' ]} soon anyway.

+ @{[ a_href 'Details.html.pl#sandbox','sandboxed environment' ]} soon anyway.

There exist Map and Pin type objects for each SharedCacheMap although they look very similiar. @@ -209,10 +209,10 @@ print <<"HERE"; There can exist multiple Pin mappings of the same page (although sharing the same memory space). This detaching must be implemented even in the - @{[ a_href '#synchronous','single-threaded' ]} W32 implementation + @{[ a_href 'Details.html.pl#synchronous','single-threaded' ]} W32 implementation of this project as it is affecting the behaviour of Cache Manager. It was never - @{[ a_href '#TraceFS','seen' ]} how to behave if multiple dirty Pin + @{[ a_href 'CacheManager.html.pl#TraceFS','seen' ]} how to behave if multiple dirty Pin mappings of the same page exist.

@@ -265,7 +265,7 @@ print <<"HERE";

You can now pray a bit and snap the resulting Cache Manager tracing from WinDbg by - @{[ a_href '#WinDbg','W32 remote kernel debugging' ]}:

+ @{[ a_href 'Reverse.html.pl#WinDbg','W32 remote kernel debugging' ]}:

@{[ doc_img 'ntdebug-windbg-boot','Successfuly connected WinDbg' ]} diff --git a/project/captive/doc/CallType.html.pl b/project/captive/doc/CallType.html.pl index 02f44d8..a0be358 100755 --- a/project/captive/doc/CallType.html.pl +++ b/project/captive/doc/CallType.html.pl @@ -45,7 +45,7 @@ print <<"HERE";

API Function Calling Conventions

Standard UNIX code compiled by GCC (GNU C Compiler) running on host - $gnulinux always uses @{[ a_href '#calltype_cdecl','cdecl' ]} ABI (Application + $gnulinux always uses @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl' ]} ABI (Application Binary Interface) calling convention. This calling convention is also the default declaration type of UNIX functions.

@@ -104,7 +104,7 @@ print <<"HERE"; arguments are cleaned by the callee. Possible inconsistencies in the number of function arguments with the function prototype used by the caller will result in fatal crash. Variable arguments lists cannot be - passed by this convention – use @{[ a_href '#calltype_cdecl','cdecl' ]} + passed by this convention – use @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl' ]} instead.

@@ -125,7 +125,7 @@ print <<"HERE"; EDX respectively. Possible inconsistencies in the number of function arguments with the function prototype used by the caller will result in fatal crash. Variable arguments lists cannot be - passed by this convention – use @{[ a_href '#calltype_cdecl','cdecl' ]} + passed by this convention – use @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl' ]} instead.

GCC (GNU C Compiler) native support for this calling convention diff --git a/project/captive/doc/Components.html.pl b/project/captive/doc/Components.html.pl index 49da0dd..d69062c 100755 --- a/project/captive/doc/Components.html.pl +++ b/project/captive/doc/Components.html.pl @@ -99,7 +99,7 @@ print <<"HERE"; non-persistent memory buffering of all the possible write requests.

sandbox commit buffer is involved only in the - case @{[ a_href '#sandbox','sandboxing feature' ]} is active. It will + case @{[ a_href 'Details.html.pl#sandbox','sandboxing feature' ]} is active. It will buffer any writes to the device during the sandbox run to prevent filesystem damage if the driver would fail in the meantime. If the filesystem gets finally successfully unmounted this sandbox buffer can be @@ -117,7 +117,7 @@ print <<"HERE"; Now we need to transparently @{[ captive_srcfile 'src/libcaptive/sandbox/sandbox.idl','connect' ]} the device interface of GIOChannel type through - @{[ a_href '#sandbox','CORBA/ORBit' ]} to the sandboxed slave. + @{[ a_href 'Details.html.pl#sandbox','CORBA/ORBit' ]} to the sandboxed slave.

Such device is still only a UNIX style GLib GIOChannel type at this point. As we need to supply it @@ -145,7 +145,7 @@ print <<"HERE";

The filesystem driver is called by the core W32 kernel implementation of libcaptive in - @{[ a_href '#synchronous','synchronous way' ]} in single-shot manner instead of + @{[ a_href 'Details.html.pl#synchronous','synchronous way' ]} in single-shot manner instead of the several reentrancies while waiting for the disk I/O completions as can be seen in the original Microsoft Windows NT. @@ -178,7 +178,7 @@ print <<"HERE"; a custom application accessing the W32 filesystem driver.

-

@{[ a_href '#sandbox','CORBA/ORBit' ]} hits us again – we need to +

@{[ a_href 'Details.html.pl#sandbox','CORBA/ORBit' ]} hits us again – we need to @{[ captive_srcfile 'src/libcaptive/sandbox/sandbox.idl','translate' ]} the @{[ a_href '#client_interface','custom filesystem API interface' ]} out of the sandboxed slave to the UNIX space.

@@ -189,7 +189,7 @@ print <<"HERE"; demultiplexing single API operations to multiple its connected sandbox slaves in transparent way as each of them handles - @{[ a_href '#mounted_one','just one filesystem device' ]}.

+ @{[ a_href 'Details.html.pl#mounted_one','just one filesystem device' ]}.

The rest of the story is not much special for this project since this is a common UNIX problem how to offer user space implemented UNIX filesystem @@ -225,7 +225,7 @@ print <<"HERE"; needs multiple operating threads (each UNIX kernel operation needs one free lufsd slot/thread to not to fail immediately). As libcaptive is - @{[ a_href '#synchronous','single-threaded' ]} all the operations + @{[ a_href 'Details.html.pl#synchronous','single-threaded' ]} all the operations get always synchronized by liblufs-captivefs before their pass over to libcaptive.

diff --git a/project/captive/doc/Details.html.pl b/project/captive/doc/Details.html.pl index 0f08196..547a552 100755 --- a/project/captive/doc/Details.html.pl +++ b/project/captive/doc/Details.html.pl @@ -84,7 +84,7 @@ print <<"HERE"; it expects to get full PC hardware access privileges and thus some datastructures do not get initialized by it (need to be trapped later at runtime stage). Some of the missing initializations are solved by - @{[ a_href '#functype_wrap','API functions wrapping' ]}. + @{[ a_href 'APITypes.html.pl#functype_wrap','API functions wrapping' ]}.

pros: Lightweight, easier to debug.

@@ -94,7 +94,7 @@ print <<"HERE";

Filesystem Driver Inside Virtual Address Space

 -

Unlike @{[ a_href '#method_ntoskrnl','previous method' ]} here we do not use +

Unlike @{[ a_href 'Details.html.pl#method_ntoskrnl','previous method' ]} here we do not use even ntoskrnl.exe as the complete kernel part of W32 is emulated from the project source files. cdfs.sys driver was successfuly ran @@ -119,13 +119,13 @@ print <<"HERE"; unimplemented function is fatal and results in program termination. When we need to implement any required API function we have multiple choices to do so: - @{[ a_href '#functype_pass','Direct pass to original ntoskrnl.exe' ]}, - @{[ a_href '#functype_wrap','Wrap of the original ntoskrnl.exe function' ]}, - @{[ a_href '#functype_native_reactos','Native implementation – $ReactOS' ]}, - @{[ a_href '#functype_native_wine','Native implementation – $Wine' ]} + @{[ a_href 'APITypes.html.pl#functype_pass','Direct pass to original ntoskrnl.exe' ]}, + @{[ a_href 'APITypes.html.pl#functype_wrap','Wrap of the original ntoskrnl.exe function' ]}, + @{[ a_href 'APITypes.html.pl#functype_native_reactos','Native implementation – $ReactOS' ]}, + @{[ a_href 'APITypes.html.pl#functype_native_wine','Native implementation – $Wine' ]} or - @{[ a_href '#functype_native_libcaptive','Native implementation – project specific' ]}. - + @{[ a_href 'APITypes.html.pl#functype_native_libcaptive','Native implementation – project specific' ]}. +

Sandboxing of W32 filesystem

@@ -174,7 +174,7 @@ print <<"HERE";

Library is called unpatched if no original binary code is needed since all of its functions are completely emulated by - @{[ a_href '#functype_native','the native implementations' ]} of this project. + @{[ a_href 'APITypes.html.pl#functype_native','the native implementations' ]} of this project. The typical unpatched representative is hal.dll as it specializes on the hardware dependent code and therefore it must be completely replaced by this project @@ -281,8 +281,8 @@ print <<"HERE"; PE-32 use the appropriate W32 specific @{[ a_href '#calltype','cdecl/stdcall/fastcall call types' ]}, .so must be completely compiled in the standard - UNIX @{[ a_href '#calltype_cdecl','cdecl call type semantics' ]}. - @{[ a_href '#functype_native','Native function implementations' ]} do not need + UNIX @{[ a_href 'CallType.html.pl#calltype_cdecl','cdecl call type semantics' ]}. + @{[ a_href 'APITypes.html.pl#functype_native','Native function implementations' ]} do not need to be explicitely exported by captivesym as they are resolved automatically by the UNIX dynamic system linker. It may be surprising you will have to fix all such missing symbol exports if you @@ -301,7 +301,7 @@ print <<"HERE"; itself. It was considered as a more sane way to support multiple W32 mounted disks by completely separately running project instances in a different UNIX processes communicating from their sandboxes via - @{[ a_href '#sandbox','CORBA sandbox interface' ]}. This sandboxing + @{[ a_href 'Details.html.pl#sandbox','CORBA sandbox interface' ]}. This sandboxing feature is not yet deployed although its code is already prepared.

The project also does not support any state cleanup to be able to load @@ -315,11 +315,11 @@ print <<"HERE"; captive_shutdown() the process address space is no longer usable for any further project operations and the process is expected to be terminated in the manner compatible with its driving - @{[ a_href '#sandbox','CORBA sandbox interface' ]} control master.

+ @{[ a_href 'Details.html.pl#sandbox','CORBA sandbox interface' ]} control master.

Each sandbox executing the untrusted W32 binary filesystem driver code is connected through its - @{[ a_href '#sandbox','CORBA sandbox interface' ]} at the point of upper + @{[ a_href 'Details.html.pl#sandbox','CORBA sandbox interface' ]} at the point of upper layer libcaptive-specific filesystem API, at the point of the bottom layer of GIOChannel device access and also for transfers of GLib logging @@ -430,7 +430,7 @@ print <<"HERE"; returns for any further write requests STATUS_LOG_FILE_FULL error code. Apparently it is caused by the fact this project is - @{[ a_href '#synchronous','single-threaded' ]} and it ignores the spawn + @{[ a_href 'Details.html.pl#synchronous','single-threaded' ]} and it ignores the spawn of parallel journalling thread during ntfs.sys initialization.

@@ -444,7 +444,7 @@ print <<"HERE"; during the final filesystem unmount.

For these reasons it was mandatory to support - @{[ a_href '#parent_connector','transparent volume remounting' ]}.

+ @{[ a_href 'Details.html.pl#parent_connector','transparent volume remounting' ]}.

ParentConnector volume remounter

 diff --git a/project/captive/doc/LinuxNTFS.html.pl b/project/captive/doc/LinuxNTFS.html.pl index bcac49b..019de55 100755 --- a/project/captive/doc/LinuxNTFS.html.pl +++ b/project/captive/doc/LinuxNTFS.html.pl @@ -55,7 +55,7 @@ print <<"HERE";

> It would have to run as part of the kernel which would mean that if it went wrong it could crash the machine. With no source, we might not be able to work around the problem.
- @{[ a_href '#sandbox','Nope' ]}, + @{[ a_href 'Details.html.pl#sandbox','Nope' ]}, @{[ a_href 'http://lufs.sourceforge.net/lufs/','Linux Userland File System (LUFS)' ]} moves the filesystem implementation to UNIX userland where the Microsoft Windows filesystem is completely unarmed by Captive jail of chroot(2), @@ -82,7 +82,7 @@ print <<"HERE"; the other kernel coders would not investigate any problems if someone had used the NTFS wrapper.
It does not apply to this project due to the implemented - @{[ a_href '#sandbox','filesystem separation' ]}.

+ @{[ a_href 'Details.html.pl#sandbox','filesystem separation' ]}.

HERE diff --git a/project/captive/doc/Related.html.pl b/project/captive/doc/Related.html.pl index ba147d3..a107dcb 100755 --- a/project/captive/doc/Related.html.pl +++ b/project/captive/doc/Related.html.pl @@ -75,7 +75,7 @@ print <<"HERE";

DOS based @{[ a_href 'http://www.gnu.org/licenses/gpl.html','GPL-2.0' ]} read-write NTFS driver. Filesystem structures are reverse engineered in the - way of @{[ a_href '#LinuxNTFScompet','Linux-NTFS Project' ]}. As it is not very + way of @{[ a_href 'Related.html.pl#LinuxNTFScompet','Linux-NTFS Project' ]}. As it is not very actively maintained it reaches a lower level of NTFS compatibility.

@@ -88,7 +88,7 @@ print <<"HERE"; a network file sharing through a VMware virtual network card.

You need @{[ '$299' ]} for this product and you need to - give up your system security by running un@{[ a_href '#sandbox','sandbox' ]}ed + give up your system security by running un@{[ a_href 'Details.html.pl#sandbox','sandbox' ]}ed closed-source program in your GNU/Linux.

@{[ a_href 'http://www.winehq.com/','Wine Project' ]}

 diff --git a/project/captive/doc/TODO.html.pl b/project/captive/doc/TODO.html.pl index cfad1b0..6a9b468 100755 --- a/project/captive/doc/TODO.html.pl +++ b/project/captive/doc/TODO.html.pl @@ -57,7 +57,7 @@ print <<"HERE"; 'Mark Russinovich' ]}.

I assume its execution falls completely - @{[ a_href '#existing_emulation','out of scope' ]} + @{[ a_href 'Architecture.html.pl#existing_emulation','out of scope' ]} of this project as it is W32 userland.

This possibility was not yet investigated in any way.