CM>RBIL> on DOS versions which do not support the FAT32 calls, this function CM>RBIL> returns CF clear/AL=00h (which is the DOS v1+ method for reporting CM>RBIL> unimplemented functions) CM> CM> You have to be careful about this criterion. My observations indicate CM> that CM> DOS versions that do not support interrupt 21h function 73h indeed return CM> with an MS-DOS v1 style error, but that does _not_ mean CF clear and AL CM> zero. It means AL zero and CF unchanged.
JM> I set CF to 0 before I started, and I got 0 when I ended. windows xp. JM> xp totally blew the function call. No, you did. Please re-read the quote above to understand why Windows XP's NTVDM, to indicate an error, left CF at what you set before (in this case, zero). ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
