1. Rob craig

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

new topic     » topic index » view message » categorize

2. Re: Rob craig

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/

new topic     » goto parent     » topic index » view message » categorize

3. Re: Rob craig

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: Rob craig

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]

new topic     » goto parent     » topic index » view message » categorize

5. Re: Rob craig

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"

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu