In reply to: Eric Auer <>

>>> ... in vague terms, that most stringent "anti
>>> reverse engineering" laws allow for independent fixes
>>> and enhancements to IP protected code, but IANAL.
> You can manipulate software to fix interoperability bugs afair.

My understanding too.

>> usually the cleanest way of writing another implementation of some
>> piece of software is to use "cleanroom reverse-engineering": * 1st
>> team studies/disassembles/debugs and documents the program into a 
>> specification. * 2nd team creates a piece of software out of this
>> specification
> A much more clean idea: Just read the specs and star> programming
> based on those. No reverse engineering, no voodoo to keep nonfree
> code out of your driver, because you will simply not touch any :-p
> This (book chapter?) document of only 16 pages describes a list of
> IOCTLs for ASPI support. Open SCSIMGR$, ioctl read using int 21
> function 4402, cx=4, dsdx=pointer to your 4 byte buffer, bx=handle
> and receive a far pointer to ASPI. 

Thanks for the reference URL. Actually this API is also well summarized 
in Ralf Brown's list (at int 21/4402) which is what I used while  
disassembling/studying the driver, DI1000DD.


Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
Freedos-user mailing list

Reply via email to