In reply to: Eric Auer <[email protected]> >>> ... 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 > ftp://ftp.isu.edu.tw/Hardware/ADAPTEC/adaptec/aspi_dos.ps > > 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. -- Czerno ------------------------------------------------------------------------------ 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! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Freedos-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-user
