1. Rob craig
- Posted by Bernie Ryan <bwryan at PCOM.NET> Mar 08, 1999
- 438 views
Rob: In M_INTERRUPT which simulate real mode interrupt are you using. DPMI 0.9+ int31 300 or causeway int31 FF01 ? Causeway from what I can tell ( looking at ralph brown interrupt list ) must assume that you are using only one kind of DOS. DPMI 0.9+ performs differently when using 16 bit DOS verses 32 bit DOS If you use DPMI 0.9+ Interrupt and perform according to which DOS type you are using ( 16 bit or 32 bit ) this may fix my problem. Maybe if you are using causeway interrupt that this may be causing other unkown problems in compatability. Thanks Bernie
2. Re: Rob craig
- Posted by Robert Craig <rds at ATTCANADA.NET> Mar 08, 1999
- 423 views
To Bernie Ryan: Here's a fix for DOSWRAP.E that lets your testme.ex run correctly in a DOS window, *and* when the system is restarted as plain DOS 7. Just change the line in DOSWRAP.E in DosOpen() that reads: if DosVersion < 7 then to: if DosVersion < 7 or atom(getenv("windir")) then The extra "windir" part lets the code detect that although it's running in DOS 7, it is not running under Windows, therefore long filenames aren't supported. (Maybe someone knows an easy, 100% fool-proof, way of detecting this.) I'll change Jacques' code on the Archive page. There are a couple of other places where he checks DosVersion. Originally, doswrap.e did not support long filenames, so this bug didn't exist. In June 1997 Jacques started supporting long filenames, but he forgot this problem with plain DOS 7. Regards, Rob Craig Rapid Deployment Software http://members.aol.com/FilesEu/
3. Re: Rob craig
- Posted by Bernie Ryan <bwryan at PCOM.NET> Mar 08, 1999
- 413 views
Thanks I will change it and try it. Just a reminder when changing the archive file be sure that the seek problem correction is added. Thanks again Bernie
4. Re: Rob craig
- Posted by Daniel Berstein <daber at PAIR.COM> Mar 09, 1999
- 409 views
At 04:56 PM 08-03-1999 , you wrote: >Here's a fix for DOSWRAP.E that lets your testme.ex >run correctly in a DOS window, >*and* when the system is restarted as plain DOS 7. > >Just change the line in DOSWRAP.E in >DosOpen() that reads: > > if DosVersion < 7 then > >to: > > if DosVersion < 7 or atom(getenv("windir")) then Perhaps my DOS.E file also requiered this path. Regards, Daniel Berstein [daber at pair.com]
5. Re: Rob craig
- Posted by "Carl R. White" <C.R.White at SCM.BRAD.AC.UK> Mar 09, 1999
- 424 views
On Mon, 8 Mar 1999, Robert Craig wrote: ] Just change the line in DOSWRAP.E in ] DosOpen() that reads: ] ] if DosVersion < 7 then ] to: ] if DosVersion < 7 or atom(getenv("windir")) then ] ] The extra "windir" part lets the code detect that although it's ] running in DOS 7, it is not running under Windows, ] therefore long filenames aren't supported. ] (Maybe someone knows an easy, 100% fool-proof, ] way of detecting this.) Just guessing on the fly again: constant LFNx = "$_$$longfilenametest.abcd" function LFNactive() sequence d integer fh fh = open(LFNx, "w") puts(fh, "test\n") close(fh) d = dir(LFNx[1..4]&"*.*") system("del "&LFNx[1..4]&"*.*",2) return (length(LFN) = length(d[D_NAME])) end function Incidentally, since Win9x has access to the parts of the disk where LFNs are stored, surely someone could write a TSR (not Windows :) ) that could access them? Or is there some kind of Micro$oft conspiracy that detects and stops this (like the deliberate detection of Windows 3.xx under DOS 7.xx and not letting it run under *any* circumstances)? -- Carl R White -- Final Year Computer Science at the University of Bradford E-mail........: cyrek- at -bigfoot.com -- Remove hyphens. Ta :) URL...........: http://www.bigfoot.com/~cyrek/ Uncrackable...: "19.6A.23.38.52.73.45 25.31.1C 3C.53.44.39.58"