At 02.11 11/11/2003, Steven Edwards wrote:
>Further run fails for Captive as
'secdrv.sys' is somehow broken driver as
>it does not provide any way to mount a filesystem. :-?
secdrv isn't a filesystem, nor a volume driver. Filesystems and volume
drivers, in Windows NT, are special, and secdrv is neither. It's a trivial
driver that just processes CREATE, CLOSE and DEVICE_CONTROL requests -
Captive is kind of overkill, as it's mostly an implementation of the cache
manager. Secdrv could be easily integrated in the Wine driver architecture
with minimal glue code (e.g. to convert the DeviceIoControl() parameters to
an IRP + I/O stack location)
>(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.
secdrv.sys is mostly a twisted maze of function calls and decoding
routines. As a driver it's completely unremarkable: all it does is reading
the DEVICE_CONTROL parameters from the current I/O stack location and
completing the IRP with IoCompleteRequest. It's clearly a mere matter of a
hundred lines of code to emulate the environment it needs
We are still having trouble loading SecDrv.sys on
native ROS.
hardcode the major version to 4, the minor version to 0 and the build
number to 1381, and it will run. Trust me on this one
>>- 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'.
RtlUnwind is documented (altough its use isn't recommended), and
implemented by ReactOS
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.
it's patent-unencumbered as it doesn't allocate exception registrations on
the stack (actually, the code me and Filip keep bouncing on the lists does
use the stack, but only because we need to try it on Windows. Using the
heap or pools rather than the stack is a matter of redefining two macros)