return $r;
}
-sub captive_srcfile ($)
+sub captive_srcfile ($;$)
{
-my($filename)=@_;
+my($filename,$text)=@_;
- a_href 'http://cvs.jankratochvil.net/viewcvs/*checkout*/priv/captive/'.$filename.'?rev=HEAD',$filename;
+ a_href 'http://cvs.jankratochvil.net/viewcvs/*checkout*/priv/captive/'.$filename.'?rev=HEAD',
+ ($text || $filename);
}
my $freespeech=a_href 'http://www.gnu.org/philosophy/free-sw.html','Free';
my $gnulinux='GNU/Linux';
-# FIXME:
-# Compatibility with NT4 etc. - just legal reasons.
-
-# FIXME:
-# name="cache_manager" Cache Manager
-
-# FIXME:
-# name="sandbox"
+print <<"HERE";
-print <<"HERE";
+<h1>About</h1>
+
+ <h2>Reasons for the Implementation</h2>
+
+ <p>Currently there is no possibility to any of the available $freespeech
+ ($freespeech used in the following text in the meaning of
+ "@{[ a_href 'http://www.gnu.org/philosophy/free-sw.html','free as in speech' ]}")
+ operating systems to reliably write to the most common disk partition
+ filesystem type – <span class="productname">Microsoft NTFS</span>. It would
+ be already supported a long time ago but there is no proper documentation of
+ <span class="productname">NTFS</span> filesystem data structures available.
+ Since <span class="productname">Microsoft</span> corporation continues in its
+ propagation of <span class="productname">Microsoft Windows NT</span>
+ (<span class="productname">NT</span> identifier used in the following text
+ applies to all the products of <span class="productname">Microsoft</span>
+ <span class="productname">NT</span> series such as
+ <span class="productname">NT 4.0</span>,
+ <span class="productname">2000</span> as NT-5.0
+ and
+ <span class="productname">XP</span> as NT-5.1.)
+ based operating systems <span class="productname">NTFS</span> is the default
+ disk file system type for vendor preinstalled <span class="productname">Microsoft Windows</span>.
+
+ <p>Unfortunately the <span class="productname">NTFS</span> filesystem has too
+ complex data structure to allow a complete reverse enginnering process in
+ reasonable time. Currently available $freespeech solutions such as $LinuxNTFS
+ filesystem have already implemented reliable reverse
+ engineered read-only access. However <a name="reliability">reliabile</a>
+ read-write part of the access would require much better
+ knowledge of the <span class="productname">NTFS</span> data structures.
+ Currently only rewriting of already existing file data blocks is supported
+ by $LinuxNTFS — no file creation, no file deletion, no directory operations etc.
+ Also any future versions of <span class="productname">NTFS</span> filesystem
+ would require another major reverse engineering effort.</p>
+
+
+ <h2>Challenges of the Project</h2>
+
+ <p>The <a name="NTFSgoal">ultimate goal</a> of this project is definitely the
+ free implementation of @{[ a_href '#reliability','reliable' ]} read-write <span
+ class="productname">NTFS</span> filesystem driver. This project chose to
+ solve this problem in the style of $Wine project by using the original binary
+ <span class="fname">ntfs.sys</span> and emulating all the required layers of
+ <span class="productname">Microsoft Windows NT</span> for it.</p>
+
+ <p>Unfortunately this effort is tainted by only partial and generally
+ insufficient documentation of API between filesystem driver
+ (<span class="fname">ntfs.sys</span>) and the
+ <span class="productname">Microsoft Windows NT</span>
+ ("@{[ a_href 'http://mail.gnu.org/archive/html/libtool/2000-09/msg00000.html','W32' ]}"
+ in the following text) kernel <span class="fname">ntoskrnl.exe</span>. Note
+ that this API is a different than the one being used in the $Wine project
+ since <span class="productname">Wine</span> implements only the user space
+ part of W32.</p>
+
+
+ <h2>Microsoft Windows Versions Compatibility</h2>
+
+ <p>Currently this project supports only driver files of
+ <span class="productname">Microsoft Windows XP</span> (NT-5.1)
+ in the following releases:</p>
+ <ul>
+ <li>Microsoft Windows XP Service Pack 1a Checked Build U.S.</li>
+ <li>Microsoft Windows XP Service Pack 1a Free Build U.S.</li>
+ <li>Microsoft Windows XP (No Service Pack) Checked Build U.S.</li>
+ <li>Microsoft Windows XP (No Service Pack) Free Build U.S.</li>
+ </ul>
-<h1>Reasons for the Implementation</h1>
-
- <p>Currently there is no possibility to any of the available $freespeech
- ($freespeech used in the following text in the meaning of
- "@{[ a_href 'http://www.gnu.org/philosophy/free-sw.html','free as in speech' ]}")
- operating systems to reliably write to the most common disk partition
- filesystem type – <span class="productname">Microsoft NTFS</span>. It would
- be already supported a long time ago but there is no proper documentation of
- <span class="productname">NTFS</span> filesystem data structures available.
- Since <span class="productname">Microsoft</span> corporation continues in its
- propagation of <span class="productname">Microsoft Windows NT</span>
- (<span class="productname">NT</span> identifier used in the following text
- applies to all the products of <span class="productname">Microsoft</span>
- <span class="productname">NT</span> series such as
- <span class="productname">NT 4.0</span>,
- <span class="productname">2000</span> as NT-5.0
- and
- <span class="productname">XP</span> as NT-5.1.)
- based operating systems <span class="productname">NTFS</span> is the default
- disk file system type for vendor preinstalled <span class="productname">Microsoft Windows</span>.
-
- <p>Unfortunately the <span class="productname">NTFS</span> filesystem has too
- complex data structure to allow a complete reverse enginnering process in
- reasonable time. Currently available $freespeech solutions such as $LinuxNTFS
- filesystem have already implemented reliable reverse
- engineered read-only access. However <a name="reliability">reliabile</a>
- read-write part of the access would require much better
- knowledge of the <span class="productname">NTFS</span> data structures.
- Currently only rewriting of already existing file data blocks is supported
- by $LinuxNTFS — no file creation, no file deletion, no directory operations etc.
- Also any future versions of <span class="productname">NTFS</span> filesystem
- would require another major reverse engineering effort.</p>
-
-
-<h1>Challenges of the Project</h1>
-
- <p>The <a name="NTFSgoal">ultimate goal</a> of this project is definitely the
- free implementation of @{[ a_href '#reliability','reliable' ]} read-write <span
- class="productname">NTFS</span> filesystem driver. This project chose to
- solve this problem in the style of $Wine project by using the original binary
- <span class="fname">ntfs.sys</span> and emulating all the required layers of
- <span class="productname">Microsoft Windows NT</span> for it.</p>
-
- <p>Unfortunately this effort is tainted by only partial and generally
- insufficient documentation of API between filesystem driver
- (<span class="fname">ntfs.sys</span>) and the
- <span class="productname">Microsoft Windows NT</span>
- ("@{[ a_href 'http://mail.gnu.org/archive/html/libtool/2000-09/msg00000.html','W32' ]}"
- in the following text) kernel <span class="fname">ntoskrnl.exe</span>. Note
- that this API is a different than the one being used in the $Wine project
- since <span class="productname">Wine</span> implements only the user space
- part of W32.</p>
+ <p>The latest list of supported driver files can be found in:
+ @{[ captive_srcfile 'src/install/acquire/w32-mod-id.captivemodid.xml' ]}</p>
+
+ <p>Microsoft Windows NTFS filesystem driver is capable of accessing even
+ the older formats of the filesystem. Porting to Microsoft Windows 2003
+ Server is expected to be done soon. There can be also a danger of Microsoft
+ Windows upgrading NTFS disk filesystem where you would no longer be able
+ to access your NTFS disk by your original
+ <span class="productname">Microsoft Windows</span> version.
+ This upgrade does not happen as it occurs only during complete CD-ROM
+ Microsoft Windows system installation – such operation is not performed
+ by this project.</p>
+
+ <p>There is no problem technically obtaining the needed driver files of
+ <span class="productname">Microsoft Windows XP</span> as they are freely
+ downloadable at:
+ @{[ a_href 'http://www.microsoft.com/WindowsXP/pro/downloads/servicepacks/sp1/checkedbuild.asp' ]}</p>
+ There may be @{[ a_href '#law','legal reasons' ]} you would not be allowed
+ to use there files if you own license to a different version of
+ <span class="productname">Microsoft Windows</span>. Legal rights will very
+ depending on your country.</p>
<h1>Architecture</h1>
<span class="fname">.so</span> file for the production version of the
original <span class="constant">PE-32</span> binary file.</p>
- <h2>Reverse Engineering</h2>
+ <a name="reverse"><h2>Reverse Engineering</h2></a>
<p>This project has no intentions to reverse engineer and document the
filesystem data structures themselves since they are being encapsulated by
<p>PDB file found at '.\\FILENAME.pdb'</p>
</blockquote>
- <h3><span class="productname">WinDbg</span> Windows NT kernel debugging</h3>
+ <a name="WinDbg"><h3><span class="productname">WinDbg</span> Windows NT kernel debugging</h3></a>
<p><span class="productname">WinDbg</span> is downloadable from:
@{[ a_href 'http://www.microsoft.com/whdc/ddk/debugging/installx86.mspx' ]}</p>
various methods described in this document.
The "<span class="constant">libcaptive</span>" box cannot be
further dissected as it is just an implementation of a set of
- @{[ a_href 'http://cvs.jankratochvil.net/viewcvs/*checkout*/priv/captive/src/libcaptive/ke/exports.captivesym?rev=HEAD',
- 'API functions' ]}.
+ @{[ captive_srcfile 'src/libcaptive/ke/exports.captivesym','API functions' ]}.
It could be separated to several subsystems such as the
@{[ a_href '#cache_manager','Cache Manager' ]},
Memory Manager, Object Manager, Runtime Library, I/O Manager
due to @{[ a_href '#log_file_full','NTFS log file full' ]}.
Now we need to transparently
- @{[ a_href 'http://cvs.jankratochvil.net/viewcvs/*checkout*/priv/captive/src/libcaptive/sandbox/sandbox.idl?rev=HEAD',
- 'connect' ]}
+ @{[ captive_srcfile 'src/libcaptive/sandbox/sandbox.idl','connect' ]}
the device interface of <span class="type">GIOChannel</span> type through
@{[ a_href '#sandbox','CORBA/ORBit' ]} to the sandboxed slave.
the W32 filesystem driver</a>.</p>
<p>@{[ a_href '#sandbox','CORBA/ORBit' ]} hits us again – we need to
- @{[ a_href 'http://cvs.jankratochvil.net/viewcvs/*checkout*/priv/captive/src/libcaptive/sandbox/sandbox.idl?rev=HEAD',
- 'translate' ]}
+ @{[ 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.</p>
messages/warnings/errors out of the sandbox to the user.</p>
+ <a name="sandbox"><h2>Sandboxing of W32 filesystem</h2></a>
+
+ <p>The emulated W32 environment running the original W32 filesystem driver
+ is separated from the rest of UNIX OS. It achieves the following goals:</p>
+
+ <ul>
+ <li><b>Restartable</b>: W32 driver can be restartde in clean state if it crashed</li>
+ <li><b>Secure</b>: Malicious W32 code cannot affect the security of UNIX OS</li>
+ <li><b>Stable</b>: Buggy W32 cannot crash any part of UNIX OS</li>
+ </ul>
+
+ <p>Sandboxing is provided with the following attributes:</p>
+
+ <ul>
+ <li>standalone UNIX process with separate memory space</li>
+ <li>chroot(2) in empty directory to prevent any UNIX OS filesystem access</li>
+ <li>setuid(2) to own user/group to prevent interaction with UNIX processes</li>
+ <li>setrlimit(2) to limit system resources available for W32 environment</li>
+ <li>the only connection with the UNIX OS by CORBA/ORBit RPC</li>
+ </ul>
+
+ <p>This security is almost the same as provided by
+ emulated virtual machines such as
+ @{[ a_href 'http://www.vmware.com/solutions/security.html','VMware' ]}.</p>
+
+ @{[ doc_img 'dia/inheritance','Sandboxing Scheme' ]}
+
+ <p>Project can be also used in non-sandboxed mode by
+ <span class="command">--no-sandbox</span> option as it is easier to debug
+ without CORBA/ORBit RPC. In this case the
+ <span class="type">DirectorySlave</span>/<span class="type">FileSlave</span>
+ options are used directly instead of their
+ <span class="type">DirectoryParent</span>/<span class="type">FileParent</span>
+ peers.</p>
+
+
<h1>Choice of the Emulation Methods</h1>
<p>The intent of the project was to get reliable read-write access to
<h1>Implementation Details</h1>
+ <a name="cache_manager"><h2>NT Cache Manager</h2></a>
+
+ <p>Although there exist some 3rd party documents about
+ <span class="productname">NT Cache Manager</span> W32 subsystem such as
+ <span class="productname">@{[ a_href 'http://www.osr.com/ntinsider/1996/cacheman.htm',
+ 'The NT Cache Manager Description' ]}</span> or
+ <span class="productname">@{[ a_href 'http://www.winntmag.com/Articles/Print.cfm?ArticleID=3864',
+ 'Learn About NT'."'".'s File-system Cache' ]}</span>
+ they are definitely insufficient for compatible
+ <span class="productname">NT Cache Manager</span> reimplementation.</p>
+
+ <p><span class="productname">NT Cache Manager</span> is about mapping
+ filesystem objects such as regular file data, filesystem bitmap or
+ journalling zone (log file). It is also being used by the filesystem for
+ mapping of virtual volume files representing the whole underlying
+ filesystem device.</p>
+
+ <p>The original W32 <span class="productname">NT Cache Manager</span>
+ is much more complicated as it must coordinate its effort with
+ other W32 subsystems like mapping of executable files
+ (<span class="type">ImageSectionObject</span>), insufficient system
+ resources from <span class="productname">NT Memory Manager</span>
+ or general effort to perform caching features for system performance.</p>
+ <span class="productname">NT Cache Manager</span> of this project has much
+ simpler goal - it just needs to provide compatible
+ <span class="productname">NT Cache Manager</span> functionality while
+ the other goals of its W32 counterpart are left to be successfuly handled
+ by UNIX OS in much more efficient way.</p>
+
+ @{[ doc_img 'dia/cache-manager',
+ '<span class="productname">NT Cache Manager</span> Architecture' ]}
+
+ <p>Cache Manager objects are always bound to
+ <span class="type">FCB</span> (File Control Block).
+ <span class="type">FileObject</span> (or its associated
+ <span class="type">HANDLE</span>) serve only as reference
+ to <span class="type">FCB</span> and there can be multiple
+ <span class="type">FileObject</span>/<span class="type">HANDLE</span>
+ items for one <span class="type">FCB</span>. It is a bit misleading
+ you must use <span class="type">FileObject</span> pointer while calling
+ most of the Cache Manager functions.</p>
+
+ <p>Before using any other Cache Manager functions you must first call
+ <span class="function">CcInitializeCacheMap()</span>. You must give the
+ maximum mapped object offset. Each mapped object byte must have at most one
+ mapped memory location - no shared pages are allowed. Also any subsequent
+ mapping request is expected to be mapped into continuous memory region.
+ It implies you must reserve the memory region for possible future mapping
+ during the initial <span class="function">CcInitializeCacheMap()</span>
+ moment sized according to the given maximum mapped object offset.
+ This is the approach currently implemented by this project although it
+ cannot be used for 3rd party <span class="fname">ext2fsd.sys</span>
+ driver as it initialized Cache Manager by the whole media device size
+ and it surprisingly succeeds for original
+ <span class="productname">Microsoft Windows</span>
+ <span class="productname">Cache Manager</span>.
+ I expect the space reservation should be postponed to the first mapping
+ request and expect no multiple mappings will be done in the case
+ of memory-exceeding <span class="function">CcInitializeCacheMap()</span>
+ reservation request. <span class="function">CcSetFileSizes()</span>
+ changing the reserved memory area size may assume no existing Map
+ or Pin mappings exist.</p>
+
+ <p><span class="type">PCACHE_MANAGER_CALLBACKS</type> argument can be
+ safely ignored:</p>
+
+ <dl>
+ <dt><span class="function">AcquireForReadAhead()</span>/<span class="function">ReleaseFromReadAhead()</span></dt>
+ <dd>
+ <p>As any readahead functionality is optional these entries are
+ never used by Cache Manager implementation of this project.</p>
+ </dd>
+
+ <dt><span class="function">AcquireForLazyWrite()</span>/<span class="function">ReleaseFromLazyWrite()</span></dt>
+ <dd>
+ <p>Even the write-behind functionality is optional for Cache Manager.
+ It is being done in asynchronous way in the original
+ <span class="productname">Microsoft Windows</span>
+ <span class="productname">Cache Manager</span>.
+ implementation and it is ignored by Cache Manager implementation of
+ this project.</p>
+
+ <p>Cache Manager does not need to write any data if not explicitely
+ requested by the driver. It is even expected to silently drop any
+ pending dirty data blocks during filesystem shutdown.
+ Forced dirty block write by function
+ <span class="function">CcFlushCache()</span> should be written without
+ any wrapping surrounding
+ <span class="function">AcquireForLazyWrite()</span>/<span class="function">ReleaseFromLazyWrite()</span>
+ pair.</p>
+ </dd>
+ </dl>
+
+ <p><span class="function">CcUninitializeCacheMap()</span> is just
+ a suggestion for Cache Manager that driver will no longer reference
+ given <span class="type">SharedCacheMap</span>. The uninitialization
+ can be postponed to any later moment in original
+ <span class="productname">Microsoft Windows</span>
+ <span class="productname">Cache Manager</span>
+ as it may be locked by existing
+ <span class="type">ImageSectionObject</span>
+ of some file being executed etc.
+ <a name="sharedcachemap_leak">It is fatal to destroy
+ <span class="type">SharedCacheMap</span></a>
+ in the moment you see no other
+ references to it as the driver will access it for some moment
+ even after <span class="function">CcUninitializeCacheMap()</span>.
+ I am not sure if it is a bug of the driver or whether there are some rules
+ how long after <span class="function">CcUninitializeCacheMap()</span>
+ completion given <span class="type">SharedCacheMap</span> still exists.
+ Fortunately it is safe to never destroy
+ <span class="type">SharedCacheMap</span> and leave it leaked - everything
+ gets clean in the
+ @{[ a_href '#sandbox','sandboxed environment' ]} soon anyway.</p>
+
+ <p>There exist Map and Pin type objects for each
+ <span class="type">SharedCacheMap</span> although they look very similiar.
+ Only these objects give you access to any memory data
+ — <span class="type">SharedCacheMap</span> only reserved the space
+ to ensure continuous mapping of the forthcoming mappings but it did not map
+ any data into it.</p>
+
+ <p>Mapping of 'new' Map or Pin will create the new object only in the case
+ no such mapping exists now. Otherwise you will just get the reference to
+ the existing object with increased usecount.</p>
+
+ <dl>
+ <dt>Map</dt>
+ <dd>
+ <p>Map mapping is always at most one for each
+ <span class="type">SharedCacheMap</span>. Base offset/length of such
+ mapping have no meaning as there can be only single Map.</p>
+
+ <p>Apparently Map size can be arbitrary long according
+ to its <span class="type">SharedCacheMap</span> reserved space.</p>
+
+ <p>You cannot modify the memory mapped by Map in any way.
+ As it is the same memory area (address) as the pages used by Pin
+ objects you always access the last modified version by possible
+ Pin of the same page.</p>
+ </dd>
+
+ <dt>Pin</dt>
+ <dd>
+ <p>Pin mapping always represents just one physical page
+ (<span class="constant">PAGE_SIZE</span> &nspan; 4096 for i386).
+ Its base offset/length can be safely extended to be aligned to the
+ requested page.</p>
+
+ <p>Pin can have associated pair of oldest and newest
+ <span class="type>LSN</span> (Linear Sequence Number). It can be
+ set by <span class="function">CcSetDirtyPinnedData()</span>
+ and Cache Manager always tracks the lowest and highest
+ reported <span class="type>LSN</span> for each page.
+ <span class="type>LSN</span> is assumed to be
+ <span class="constant">0</span> if not set.</p>
+
+ <p>Any existing Pin mapping will be reused for further mappings
+ as long as it is not ThreadOwned. In the moment you use
+ <span class="function">CcSetBcbOwnerPointer()</span> you will detach
+ the associated Pin pages from its
+ <span class="type">SharedCacheMap</span>.
+ Although they will further act as valid Pin mappings they will be no
+ longer reused during new Pin mapping of the same page.
+ 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
+ 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
+ mappings of the same page exist.</p>
+ </dd>
+ </dl>
+
+ <p>Only the pages not yet present in the memory must be read from the disk.
+ You must not read any pages you do not need to as the driver does not
+ expect it and it would corrupt its data buffers.</p>
+
+ <p>Cache Manager of this project will destroy Pin or Map mappings after
+ their last unreferencing (in opposite of
+ @{[ a_href 'sharedcachemap_leak','leaked <span class="type">SharedCacheMap</span>' ]}).
+ Despite it any dirty pages may still be held as the pages
+ (including their <span class="type>LSN</span>s) are cached associated
+ with <span class="type">SharedCacheMap</span>. It may be also possible
+ original <span class="productname">Microsoft Windows</span>
+ <span class="productname">Cache Manager</span>
+ postpones Pin mapping destroy to later time but it does not matter.</p>
+
+
+ <h3>TraceFS NT Cache Manager Tracer</h3>
+
+ <p>@{[ a_href '#cache_manager','Cache Manager behaviour' ]} would be hard
+ to analyze just by @{[ a_href '#reverse','reverse engineering' ]} as it
+ is pretty complicated code cooperating with many other W32 kernel
+ subsystems. It was chosen as easier way to trace it instead and validate
+ all the Cache Manager assumptions by Cache Manager simulator.</p>
+
+ @{[ doc_img 'dia/TraceFS','TraceFS Hooking' ]}
+
+ <p>You must prepare your driver to be hooked
+ (<span class="fname">ntfs.sys</span> in this case):</p>
+
+ <blockquote class="command">
+ <p>@{[ captive_srcfile './src/TraceFS/hookfs.pl' ]} ntfs.sys ./src/TraceFS/TraceFS-W32/TraceFS.sys >hooked/ntfs.sys</p>
+ </blockquote>
+
+ <p>This <span class="fname">hooked/ntfs.sys</span> file must be replaced
+ in the <span class="fname">%System32%\\drivers</span> directory.
+ Beware as
+ <span class="productname">Microsoft Windows</span>
+ has many backups of these system files such as
+ <span class="fname">%System32%\\dllcache</span> — delete them
+ all!</p>
+
+ <p>You also need to install
+ <span class="fname">./src/TraceFS/TraceFS-W32/TraceFS.sys</span>
+ into <span class="fname">%System32%\\drivers</span> directory
+ and import <span class="fname">TraceFS/TraceFS-W32/TraceFS.reg</span>
+ registry file to initialize the debug driver during system boot.</p>
+
+ <p>You can now pray a bit and snap the resulting Cache Manager tracing
+ from <span class="productname">WinDbg</span> by
+ @{[ a_href '#WinDbg','W32 remote kernel debugging' ]}:</p>
+
+ @{[ doc_img 'ntdebug-windbg-boot','Successfuly connected <span class="productname">WinDbg</span>' ]}
+
+ <p>The resulting trace file should be processed by
+ @{[ captive_srcfile './src/TraceFS/checktrace.pl' ]} Perl Cache Manager
+ implementation to validate its assumptions about Cache Manager behaviour.
+ Any seen incompatibilies will be reported — your target is to reach
+ as few error messages as possible.</p>
+
+
+ <h4>TraceFS for general API tracing</h4>
+
+ <p>Although TraceFS was up to now used only for tracing of
+ <span class="productname">NT Cache Manager</span> it can be easily
+ used ever for any other NT kernel API tracing. You need to provide
+ appropriate function wrappers in the main source file
+ @{[ captive_srcfile './src/TraceFS/TraceFS-W32/TraceFS.c' ]}
+ and you must also export them in
+ @{[ captive_srcfile './src/TraceFS/TraceFS-W32/TraceFS.def' ]}.
+ @{[ captive_srcfile './src/TraceFS/hookfs.pl' ]} has no hardcoded
+ function names – it will hook exactly the exported entries.</p>
+
+ <p>Framework for thread synchronizations and debug tracing is provided to
+ prevent mangling of messages while running by multiple threads at once.
+ Testing was done just on uniprocessor machine, SMP kernel may need some
+ fixes.</p>
+
+
<a name="functype"><h2>API Function Implementation Choices</h2></a>
<p>For each function exported by W32
below:</p>
<table border="1" align="center">
- <tr><th>Function type </th><th>Items</th><th>Portion</th></tr>
+ <tr><th>Function type </th><th>Items</th><th>Portion</th></tr>
<tr><td>@{[ a_href '#functype_pass','pass' ]} </td><td> 81</td><td> 26%</td></tr>
<tr><td>@{[ a_href '#functype_wrap','wrap' ]} </td><td> 2</td><td> 0%</td></tr>
<tr><td>@{[ a_href '#functype_native_reactos','native-ReactOS' ]}</td><td> 113</td><td> 36%</td></tr>
<p>All the exporting magic is handled by custom script
<span class="fname">captivesym</span> processing the definition file
- <span class="fname">@{[ a_href
- 'http://cvs.jankratochvil.net/viewcvs/*checkout*/priv/captive/src/libcaptive/ke/exports.captivesym?rev=HEAD',
- 'src/libcaptive/ke/exports.captivesym' ]}</span>
+ <span class="fname">@{[ captive_srcfile 'src/libcaptive/ke/exports.captivesym' ]}</span>
to produce the intermediate relaying code
<span class="fname">src/libcaptive/ke/exports.c</span>. For details of the
<span class="fname">captivesym</span>-specific source file syntax please
actively maintained it reaches a lower level of
<span class="productname">NTFS</span> compatibility.</p>
- <h2>The only real competition: Closed-source read/write @{[ '$299' ]} equivalent</h2>
+ <h2>@{[ a_href 'http://www.vmware.com/download/workstation.html','VMware Workstation' ]}</h2>
- <p>@{[ a_href 'http://www.vmware.com/download/workstation.html',
- 'VMware Workstation' ]}</p>
+ <p>The only real competition: Closed-source read/write @{[ '$299' ]} equivalent.</p>
<p>Original Microsoft Windows operating system can be run inside a virtual
machine running under GNU/Linux and share the read-write NTFS disk by using
git://git.jankratochvil.net / www.jankratochvil.net.git / blobdiff