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)



Reply via email to