Dual-mode programs... yes!  There were some DOS extenders that could execute Win32 console programs without transforming them to DOS programs, like WDOSX did.  I mean same EXE executed as Win32 console under Win32, and as DOS extended app under DOS, Win3, etc.  For example PharLap DOSXNT (MSVC 1.52 used it), or Borland's 32RTM (Borland C++ 4.x).  And on the free software side, RSXNT, which unfortunately gave exception 0D under DOSEmu 0.66 (last time I tried).  The only disadvantage is needing an external extender file, and an external DLL (RSXNT only).

Why didn't DOS exes handle long file names?  There's a DOS API for this, at least from Win9x (DJGPP creates DOS-extended programs that use long filenames under Win9x, and, with a special program that they also have in the distribution, even under WinNT family OSes)...  Must be a RTL issue, probably.

Laurentiu


"Walter" <walter@digitalmars.com> wrote in message news:adjgf1$261m$1@digitaldaemon.com...
>
> "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:adj61s$1r98$1@digitaldaemon.com...
> > Not necessarily: to quote from WDOSX, you can have a single small
program,
> > with no external DLL dependencies, that can run on more than 90% from
all
> > machines (DOS, Win 3.1x, Win9x, WinNT4 and later, OS/2, Linux or FreeBSD with DOSEmu).  If it's about console mode programs, that only do
standard
> > i/o, and thus don't depend on different DPMI limitations for accessing hardware, it's ideal.  It beats Java in any case!  :)
>
> What I used to do was create dual mode programs, i.e. making a Win32
program
> and have the "stub executable" be the DOS version. The DOS versions didn't work well under Win32 because they couldn't handle long filenames, had problems with DOS filetimes vs Win32 filetimes, etc.
>
>

Long filenames aren't a dos feature (although they are a win9x feature), and didn't work on NT, etc. There wasn't really any cost to a dual mode program. The exe file was twice as large, but that didn't affect load or run time, since only half of it ever got loaded.

(I also ran into a lot of trouble doing things like setting the environment variable with a win32 executable and spawning a dos executable which couldn't read it, and vice versa. Going all dual mode made all these problems just go away.)

"Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adkivc$70r$1@digitaldaemon.com...
> Dual-mode programs... yes!  There were some DOS extenders that could
execute
> Win32 console programs without transforming them to DOS programs, like
WDOSX
> did.  I mean same EXE executed as Win32 console under Win32, and as DOS extended app under DOS, Win3, etc.  For example PharLap DOSXNT (MSVC 1.52 used it), or Borland's 32RTM (Borland C++ 4.x).  And on the free software side, RSXNT, which unfortunately gave exception 0D under DOSEmu 0.66 (last time I tried).  The only disadvantage is needing an external extender
file,
> and an external DLL (RSXNT only).
>
> Why didn't DOS exes handle long file names?  There's a DOS API for this,
at
> least from Win9x (DJGPP creates DOS-extended programs that use long filenames under Win9x, and, with a special program that they also have in the distribution, even under WinNT family OSes)...  Must be a RTL issue, probably.
>
> Laurentiu
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:adjgf1$261m$1@digitaldaemon.com...
> >
> > "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:adj61s$1r98$1@digitaldaemon.com...
> > > Not necessarily: to quote from WDOSX, you can have a single small
> program,
> > > with no external DLL dependencies, that can run on more than 90% from
> all
> > > machines (DOS, Win 3.1x, Win9x, WinNT4 and later, OS/2, Linux or
FreeBSD
> > > with DOSEmu).  If it's about console mode programs, that only do
> standard
> > > i/o, and thus don't depend on different DPMI limitations for accessing hardware, it's ideal.  It beats Java in any case!  :)
> >
> > What I used to do was create dual mode programs, i.e. making a Win32
> program
> > and have the "stub executable" be the DOS version. The DOS versions
didn't
> > work well under Win32 because they couldn't handle long filenames, had problems with DOS filetimes vs Win32 filetimes, etc.
> >
> >
>
>

Hmmm... aren't you limited to 64k, for the DOS stub of the PE image?

Laurentiu

"Walter" <walter@digitalmars.com> wrote in message news:admft6$22v7$1@digitaldaemon.com...
> Long filenames aren't a dos feature (although they are a win9x feature),
and
> didn't work on NT, etc. There wasn't really any cost to a dual mode
program.
> The exe file was twice as large, but that didn't affect load or run time, since only half of it ever got loaded.
>
> (I also ran into a lot of trouble doing things like setting the
environment
> variable with a win32 executable and spawning a dos executable which couldn't read it, and vice versa. Going all dual mode made all these problems just go away.)
>
> "Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adkivc$70r$1@digitaldaemon.com...
> > Dual-mode programs... yes!  There were some DOS extenders that could
> execute
> > Win32 console programs without transforming them to DOS programs, like
> WDOSX
> > did.  I mean same EXE executed as Win32 console under Win32, and as DOS extended app under DOS, Win3, etc.  For example PharLap DOSXNT (MSVC
1.52
> > used it), or Borland's 32RTM (Borland C++ 4.x).  And on the free
software
> > side, RSXNT, which unfortunately gave exception 0D under DOSEmu 0.66
(last
> > time I tried).  The only disadvantage is needing an external extender
> file,
> > and an external DLL (RSXNT only).
> >
> > Why didn't DOS exes handle long file names?  There's a DOS API for this,
> at
> > least from Win9x (DJGPP creates DOS-extended programs that use long filenames under Win9x, and, with a special program that they also have
in
> > the distribution, even under WinNT family OSes)...  Must be a RTL issue, probably.
> >
> > Laurentiu
> >
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:adjgf1$261m$1@digitaldaemon.com...
> > >
> > > "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:adj61s$1r98$1@digitaldaemon.com...
> > > > Not necessarily: to quote from WDOSX, you can have a single small
> > program,
> > > > with no external DLL dependencies, that can run on more than 90%
from
> > all
> > > > machines (DOS, Win 3.1x, Win9x, WinNT4 and later, OS/2, Linux or
> FreeBSD
> > > > with DOSEmu).  If it's about console mode programs, that only do
> > standard
> > > > i/o, and thus don't depend on different DPMI limitations for
accessing
> > > > hardware, it's ideal.  It beats Java in any case!  :)
> > >
> > > What I used to do was create dual mode programs, i.e. making a Win32
> > program
> > > and have the "stub executable" be the DOS version. The DOS versions
> didn't
> > > work well under Win32 because they couldn't handle long filenames, had problems with DOS filetimes vs Win32 filetimes, etc.
> > >
> > >
> >
> >
>
>

    Yes, this is a restriction of the PE format.

"Laurentiu Pancescu" <user@nowhere.near> escribió en el mensaje news:adn4e7$2o6c$1@digitaldaemon.com...
> Hmmm... aren't you limited to 64k, for the DOS stub of the PE image?
>
> Laurentiu
>
> "Walter" <walter@digitalmars.com> wrote in message news:admft6$22v7$1@digitaldaemon.com...
> > Long filenames aren't a dos feature (although they are a win9x feature),
> and
> > didn't work on NT, etc. There wasn't really any cost to a dual mode
> program.
> > The exe file was twice as large, but that didn't affect load or run
time,
> > since only half of it ever got loaded.
> >
> > (I also ran into a lot of trouble doing things like setting the
> environment
> > variable with a win32 executable and spawning a dos executable which couldn't read it, and vice versa. Going all dual mode made all these problems just go away.)
> >
> > "Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adkivc$70r$1@digitaldaemon.com...
> > > Dual-mode programs... yes!  There were some DOS extenders that could
> > execute
> > > Win32 console programs without transforming them to DOS programs, like
> > WDOSX
> > > did.  I mean same EXE executed as Win32 console under Win32, and as
DOS
> > > extended app under DOS, Win3, etc.  For example PharLap DOSXNT (MSVC
> 1.52
> > > used it), or Borland's 32RTM (Borland C++ 4.x).  And on the free
> software
> > > side, RSXNT, which unfortunately gave exception 0D under DOSEmu 0.66
> (last
> > > time I tried).  The only disadvantage is needing an external extender
> > file,
> > > and an external DLL (RSXNT only).
> > >
> > > Why didn't DOS exes handle long file names?  There's a DOS API for
this,
> > at
> > > least from Win9x (DJGPP creates DOS-extended programs that use long filenames under Win9x, and, with a special program that they also have
> in
> > > the distribution, even under WinNT family OSes)...  Must be a RTL
issue,
> > > probably.
> > >
> > > Laurentiu
> > >
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:adjgf1$261m$1@digitaldaemon.com...
> > > >
> > > > "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:adj61s$1r98$1@digitaldaemon.com...
> > > > > Not necessarily: to quote from WDOSX, you can have a single small
> > > program,
> > > > > with no external DLL dependencies, that can run on more than 90%
> from
> > > all
> > > > > machines (DOS, Win 3.1x, Win9x, WinNT4 and later, OS/2, Linux or
> > FreeBSD
> > > > > with DOSEmu).  If it's about console mode programs, that only do
> > > standard
> > > > > i/o, and thus don't depend on different DPMI limitations for
> accessing
> > > > > hardware, it's ideal.  It beats Java in any case!  :)
> > > >
> > > > What I used to do was create dual mode programs, i.e. making a Win32
> > > program
> > > > and have the "stub executable" be the DOS version. The DOS versions
> > didn't
> > > > work well under Win32 because they couldn't handle long filenames,
had
> > > > problems with DOS filetimes vs Win32 filetimes, etc.
> > > >
> > > >
> > >
> > >
> >
> >
>
>

"Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adn4e7$2o6c$1@digitaldaemon.com...
> Hmmm... aren't you limited to 64k, for the DOS stub of the PE image?
>
> Laurentiu

No.

How is this, "no"???  I understood you use the PE stub (that small stuff that usually displays "This program must be run under Win32"), which is limited to 64kbytes in size, according to PE spec.  What did I miss here? Could you please be a little more explicit?  You really confused me with your "no"... <g>

Laurentiu
"Walter" <walter@digitalmars.com> wrote in message
news:adoeh7$14o0$1@digitaldaemon.com...
>
> "Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adn4e7$2o6c$1@digitaldaemon.com...
> > Hmmm... aren't you limited to 64k, for the DOS stub of the PE image?
> >
> > Laurentiu
>
> No.
>
>

The offset to the new exe part of the file is a 32 bit value. -Walter

"Laurentiu Pancescu" <user@domain.invalid> wrote in message news:adsa9t$2fa1$1@digitaldaemon.com...
> How is this, "no"???  I understood you use the PE stub (that small stuff that usually displays "This program must be run under Win32"), which is limited to 64kbytes in size, according to PE spec.  What did I miss here? Could you please be a little more explicit?  You really confused me with your "no"... <g>
>
> Laurentiu
> "Walter" <walter@digitalmars.com> wrote in message
> news:adoeh7$14o0$1@digitaldaemon.com...
> >
> > "Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adn4e7$2o6c$1@digitaldaemon.com...
> > > Hmmm... aren't you limited to 64k, for the DOS stub of the PE image?
> > >
> > > Laurentiu
> >
> > No.
> >
> >
>
>