Hello Jan!
--- Jan Kratochvil <lace(a)jankratochvil.net> wrote:
Hi,
On Mon, 10 Nov 2003 20:19:45 +0100, Rapha�l Junqueira wrote:
...
> BTW, I have got as far with loading
secdrv.sys as crashing on
unimplemented
> IoCreateDevice. I believe the Io* functions
will be the biggest
problems.
It is no problem loading it and initializing it by Captive NTFS for
GNU/Linux:
http://www.jankratochvil.net/project/captive/
./captive-cmdline --load-module=/tmp/ntoskrnl.exe
--filesystem=/tmp/secdrv.sys --debug-messages /dev/null
(some trivia extensions done before a moment are currently only in
CVS:
http://cvs.jankratochvil.net/viewcvs/*checkout*/captive/README?rev=HEAD
section 'CVS Bleeding Edge'
)
'secdrv.sys' creates devices:
"\Device\AscKmd" (symlinked to "\DosDevices\AscKmd")
"\Device\Secdrv" (symlinked to "\DosDevices\Secdrv")
It returns STATUS_SUCCESS afterwards. The log can be seen at
http://www.jankratochvil.net/priv/secdrv/secdrv-init-onlysecdrv.log
I used secdrv.sys
http://www.jankratochvil.net/priv/secdrv/secdrv.sys
md5: bb6fbebebbd14429021f2851a60d8546
downloaded by Google from
http://www.kids-station.com/game/Patrician2/secdrv.sys
Further run fails for Captive as 'secdrv.sys' is somehow broken
driver as it
does not provide any way to mount a filesystem. :-?
Currently the example above requires 'ntoskrnl.exe' of NT-5.1 (XP).
Tried Service Pack 1 Free Build and Service Pack 1 Checked Build.
It would not be needed for such simple driver as 'secdrv.sys' but
Captive
currently requires it for its 'ntfs.sys' emulation, reasons below:
http://www.jankratochvil.net/project/captive/doc/Details.html.pl#emulmeth_fs
The next step is to combine Captive with Wine to be able to run the
W32
userland application with 'secdrv.sys'. Captive ported only the W32
kernel part
of ReactOS to the GNU/Linux environment, no W32 userland code is
present there.
Hmm. We really shouldnt need to make much changes to WINE to use
Captive I would think. Once Captive+SevDrv and WINE are running you
should have full access to the CDROM drive.
Well, i
don't think implementing simple (stupid?) Io* functions
will be
diffcult.
(A)Synchronous/(Non)Alertable IRPs (I/O Request Packet) can be tricky
although
it is generally solved by ReactOS/Captive and it is questionable how
much it is
perused by 'secdrv.sys' IRP handling code.
We are still having trouble loading SecDrv.sys on native ROS.
For me, the
problem is what secdrv want to do with this functions
(maybe a
voodoo test for safely check if the subsystem
have a correct
behavior):
...
- - RtlUnwind
This is a part of undocumented SEH (Structured Exception Handling)
implemented
by ReactOS while fixed by Captive and partially combined with native
'ntoskrnl.exe'. I still have some suspections on the correctness of
the current
implementation but it works fine for 'ntfs.sys'.
We have a new SEH implementation that is not merged yet. The
implementation we have is patent friendly as it implement SEH totaly
differntly by using macros kind of like WINE.
Its looking good!
Thanks
Steven
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree