Re: copy protection - was: Re: Is it time for playing games on WINE?

[Steven Edwards]

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

[KJK::Hyperion]

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)

[Jan Kratochvil]

Hi,

On Tue, 11 Nov 2003 03:05:55 +0100, KJK::Hyperion wrote:
>   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. 
This was just a joke, sorry for the confusion.

...
> >  >>-
> > 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 
Although ReactOS implements SEH it is compatible only with ReactOS code
while is binary incompatible with SEH as being used by 'ntfs.sys'.
Unfortunately Vizzini still did not merge the patches.


Regards,
Lace

-- 
Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/