Discussion:
BP 7.0 has seconds of delay under WinXP
(too old to reply)
Ruud
2009-12-23 12:01:17 UTC
Permalink
Hallo allemaal,


I have a weird problem: when working with BP 7.0 in a DOS box in
Windows XP on my laptop (Dell Latitude D510), I sometimes have to wait
seconds before what ever I type appears on my screen. This includes
cursor movements. I don't experience any od these problems on any of
other (slower) computers/laptops. Any idea?

Many thanks for any info, suggestion or help!


Groetjes, Ruud Baltissen
Marco van de Voort
2009-12-23 13:02:21 UTC
Permalink
Post by Ruud
I have a weird problem: when working with BP 7.0 in a DOS box in
Windows XP on my laptop (Dell Latitude D510), I sometimes have to wait
seconds before what ever I type appears on my screen. This includes
cursor movements. I don't experience any od these problems on any of
other (slower) computers/laptops. Any idea?
Many thanks for any info, suggestion or help!
Try to backup and then kill the PIF file.
Ruud
2009-12-30 09:51:04 UTC
Permalink
Hallo Marco,
Post by Marco van de Voort
Try to backup and then kill the PIF file.
You mean the PIF files as used with Win 3.11 ??? None found. I'm using
a minimum system anyway; leave anything away and TP won't start up at
all.

So because of these delay problems, I decided to try FPC again after a
long time (two years?). I used it before but I two problems with it:
- too bulky EXE-files; for example 200 KB vs. 30 KB for one of my
programs
- the IDE interface wasn't stable IMHO
I downloaded 2.2.4 and it works like a charm. It seems that for the
most of my projects it is "Good bye, TP!". But tinkering around with
8088 machines means that TP, even version 3.0, still is needed from
time to time.


Groetjes, Ruud Baltissen
Marco van de Voort
2009-12-30 11:15:37 UTC
Permalink
Post by Ruud
Post by Marco van de Voort
Try to backup and then kill the PIF file.
You mean the PIF files as used with Win 3.11 ??? None found. I'm using
a minimum system anyway; leave anything away and TP won't start up at
all.
Afaik win95+ also use them to store properties of programs.
Post by Ruud
So because of these delay problems, I decided to try FPC again after a
- too bulky EXE-files; for example 200 KB vs. 30 KB for one of my
programs
Won't ever change. 32-bit code is simply bulkier, and the RTL is portable,
not handwritten 16-bit assembler.

Do you still use floppies daily?
Post by Ruud
- the IDE interface wasn't stable IMHO I downloaded 2.2.4 and it works
like a charm. It seems that for the most of my projects it is "Good bye,
TP!". But tinkering around with 8088 machines means that TP, even version
3.0, still is needed from time to time.
In 2.2.4 via 2.2.2 the IDE is roughly on the same level as in the 1.0.x
series.

2.4.0 (real soon now) will hopefully further improve the help (an optional
chm download that is quicker to decompress and smaller on disk), and I hope
that 2.4.2 in summer/next fall will improve the debugger support. (moving to
gdb7)
Rugxulo
2009-12-31 19:24:08 UTC
Permalink
Hi,
Post by Marco van de Voort
Post by Ruud
So because of these delay problems, I decided to try FPC again after a
- too bulky EXE-files; for example 200 KB vs. 30 KB for one of my
programs
Won't ever change. 32-bit code is simply bulkier, and the RTL is portable,
not handwritten 16-bit assembler.
8086 instructions are max. 6 bytes each. 386 are max. 15 bytes each. I
don't really know of any compiler that really really prefers small
size over speed (definitely not GCC, even with -Os). If you want small
size, you probably have to use assembly. BTW, I'll be honest, I don't
know how much of FPC relies on DJGPP, but the latter is heavily about
POSIX, LFNs, compatibility, etc. TP7 has none of that. If you don't
need it, don't use it.

P.S. http://upx.sf.net :-))
Post by Marco van de Voort
Do you still use floppies daily?
Yes, definitely. Oh, you meant him? ^_^
Post by Marco van de Voort
Post by Ruud
But tinkering around with 8088 machines means that TP, even version
3.0, still is needed from time to time.
Does TP3 really have any advantage over 5.5?? Maybe faster compiles??

BTW, you are officially a hardcore retro dude if you still use
8086/8088. Search for Jim Leonard's or Mike Chamber's software. :-)
Marco van de Voort
2010-01-01 10:41:38 UTC
Permalink
Post by Rugxulo
know how much of FPC relies on DJGPP,
Extender (go32.exe) and linker. (ld.exe). Some additional tools (like
make) are needed to build FPC, but not to use it.
Post by Rugxulo
but the latter is heavily about POSIX, LFNs, compatibility, etc. TP7 has
none of that. If you don't need it, don't use it.
No POSIX on non Unix platforms. LFN, Delphi compat surely.
Post by Rugxulo
P.S. http://upx.sf.net :-))
Small binaries are not an objective of mine.
Post by Rugxulo
Post by Marco van de Voort
Do you still use floppies daily?
Yes, definitely. Oh, you meant him? ^_^
I killed off XP last november, so I'm finally floppy-free. (Vista+ don't
need floppies, XP and earlier do for some tasks)
Post by Rugxulo
Post by Marco van de Voort
Post by Ruud
But tinkering around with 8088 machines means that TP, even version
3.0, still is needed from time to time.
Does TP3 really have any advantage over 5.5?? Maybe faster compiles??
If you care about code and RTL size? Sure I think. It has the smaller COM
memory models that afaik later TPs don't have?

In that the question similar to "Does TP 5.5 really have any
advantage over FPC?" :-)
Rugxulo
2010-01-01 12:18:57 UTC
Permalink
Hi, Happy New Year!! :-)
Post by Marco van de Voort
Post by Rugxulo
know how much of FPC relies on DJGPP,
Extender (go32.exe) and linker. (ld.exe). Some additional tools (like
make) are needed to build FPC, but not to use it.
So it won't run without go32.exe?? I'm honestly not sure whether that
app does anything at all in DJGPP v2. Well, at least, you don't need
it at all unless you want to co-mingle v1 and v2 apps (and then you'd
still need the old go32). It even calls CWSDPMI, so it's not even a
replacement for that! But it does report memory stats for you (not
useful under some OSes, though, heh).

Long story short: I need to install FPC to test it a bit. :-)
Post by Marco van de Voort
Post by Rugxulo
but the latter is heavily about POSIX, LFNs, compatibility, etc. TP7 has
none of that. If you don't need it, don't use it.
No POSIX on non Unix platforms. LFN, Delphi compat surely.
With DJGPP it's different, they needed to be able to support GNU
tools.
Post by Marco van de Voort
Post by Rugxulo
P.S.http://upx.sf.net    :-))
Small binaries are not an objective of mine.
I know. Let me find the link ...

http://wiki.freepascal.org/Size_Matters

BTW, UPX'd stuff has no penalty in DOS. But for some reason under
Windows UPX'd stuff (e.g. DJGPP apps) run much slower than would be
expected (dirty pages??). So yeah, not recommended there if you care
about speed.
Post by Marco van de Voort
I killed off XP last november, so I'm finally floppy-free. (Vista+ don't
need floppies, XP and earlier do for some tasks)
USB floppy drive ftw!! (on Vista too)
Post by Marco van de Voort
Post by Rugxulo
Does TP3 really have any advantage over 5.5?? Maybe faster compiles??
If you care about code and RTL size? Sure I think. It has the smaller COM
memory models that afaik later TPs don't have?
I worry if it's buggier due to being older. And I don't think anybody
in particular prefers .COMs over .EXEs since there is no inherent
advantage.
Post by Marco van de Voort
In that the question similar to "Does TP 5.5 really have any
advantage over FPC?" :-)
Doubtful. Even I don't have any 286s around here (yet?? heh). So
unless you absolutely enjoy 16-bit programming or know somebody who
needs such compatibility, I wouldn't bother. Then again, is FPC fairly
fast to compile stuff? I would assume it would matter more for old (<
586) machines. How big is the default install? (I really need to test
install it, heh.) Only for such cases (or by chance if something
didn't compile with FPC) would TP55 still be a good thing. Well, and
it fits compressed on a floppy too, IIRC. ;-)
Marco van de Voort
2010-01-01 15:49:19 UTC
Permalink
Post by Rugxulo
Post by Marco van de Voort
Post by Rugxulo
know how much of FPC relies on DJGPP,
Extender (go32.exe) and linker. (ld.exe). Some additional tools (like
make) are needed to build FPC, but not to use it.
So it won't run without go32.exe??
Afaik no, but I haven't tested that in a decade. If I used dos I simply used
the install with a bunch of files in it. IIRC CWSDPMI is only required if
you have no DPMI provider.
Post by Rugxulo
Long story short: I need to install FPC to test it a bit. :-)
Well, take the fresh dos release of today :-)
Post by Rugxulo
Post by Marco van de Voort
No POSIX on non Unix platforms. LFN, Delphi compat surely.
With DJGPP it's different, they needed to be able to support GNU
tools.
Yes, they are not wholly portable, only on top of a POSIX subsystem.
Post by Rugxulo
BTW, UPX'd stuff has no penalty in DOS.
I assume under DOS it is a CPU vs disk-I/O tradeoff. But indeed UPX
frustrating the mapping of binaries that normal OSes have doesn't apply to
dos.
Post by Rugxulo
Post by Marco van de Voort
I killed off XP last november, so I'm finally floppy-free. (Vista+ don't
need floppies, XP and earlier do for some tasks)
USB floppy drive ftw!! (on Vista too)
In recent years I only used floppies for bios updates or loading drivers
during setup of OS installs.

Since Vista, the NT side of things finally also can postload drivers from
mass storage devices.
Post by Rugxulo
Post by Marco van de Voort
If you care about code and RTL size? Sure I think. It has the smaller COM
memory models that afaik later TPs don't have?
I worry if it's buggier due to being older. And I don't think anybody
in particular prefers .COMs over .EXEs since there is no inherent
advantage.
They execute faster, and are tighter? Do you need any more reasons? :-)
Post by Rugxulo
Post by Marco van de Voort
In that the question similar to "Does TP 5.5 really have any
advantage over FPC?" :-)
Doubtful. Even I don't have any 286s around here (yet?? heh).
I don't even have anything x86 under a XP2000+ anymore. Actually those two
XP2000+'s are the only pure x86 systems that I have, all the others are
32/64-bit.

I do have slow machines (resp 110 and 40 MHz), but they are non-x86.
Post by Rugxulo
Then again, is FPC fairly
fast to compile stuff?
Compared to what? TP ? No. GCC? Yes.
Post by Rugxulo
I would assume it would matter more for old (< 586)
machines. How big is the default install? (I really need to test install
it, heh.)
Close to 100 MB or so, but the default is full. There are ways to slim them
down (for dos there are individual packages). 10-25MB is probably possible,
and would be roughly equivalent to TP + cmdline Delphi.4
Post by Rugxulo
Only for such cases (or by chance if something didn't compile with FPC)
would TP55 still be a good thing. Well, and it fits compressed on a floppy
too, IIRC. ;-)
I'm a BP7 licensee, so even then I would not use TP55. But except for the
Turbo Vision helpfile and manual, I haven't used it since 2003, and before
only for minor testing.

But I had already migrated all my sources from BP to Topspeed Modula2 (on
Dos) before I even started with FPC. So I don't reallly have BP legacy code
anymore.

The only interesting part for playing is Turbo Vision (I have a soft spot
not so much for Dos, but for fullscreen TUI programming), and I have that in
FPC for 98%.
Rugxulo
2010-01-01 17:01:52 UTC
Permalink
Hi,
Post by Marco van de Voort
Post by Rugxulo
So it won't run without go32.exe??
Afaik no, but I haven't tested that in a decade. If I used dos I simply used
the install with a bunch of files in it.
As mentioned, even GO32-V2.EXE needs CWSDPMI, so it's not a substitute
(although old old v1's GO32 predated CWSDPMI and hence didn't need
it). In v2 DPMI is always required unlike v1 where it could optionally
use other stuff (XMS, VCPI). Mixing v1 and v2 apps is rare since most
got updated or are redundant. (FYI, the Desqview/X toolkit used DJGPP
v1.)
Post by Marco van de Voort
IIRC CWSDPMI is only required if you have no DPMI provider.
Well, the only DOS I know that includes a DPMI provider by default is
Novell DOS / DR-DOS 7 (e.g. my DR-DOS 7.03, which was last updated ten
years ago, woot). And that didn't support virtual memory. I don't know
exactly, but I think it fixed a lot of bugs and became a 32-bit DPMI
host in 7.02 or 7.03 or such, hence multitasking now finally works
with DJGPP apps (although limited to 64 MB a task, max). But that
requires their quirky DR EMM386 to always be loaded. I think the DJGPP
FAQ says that in OpenDOS 7.01 etc. (which wasn't that open, BTW) you
allegedly had to disable the buggy built-in DPMI and let DJGPP apps
use CWSDPMI instead.

QEMM386 might've come with QDPMI (which did somewhat support virtual
memory), but I think that was somewhat buggy too and limited in total
RAM available for use (e.g. I'm told that QEMM 9.01 can only use 256
MB max).
Post by Marco van de Voort
Post by Rugxulo
Long story short: I need to install FPC to test it a bit.    :-)
Well, take the fresh dos release of today  :-)
I noticed! :-)
Post by Marco van de Voort
Post by Rugxulo
BTW, UPX'd stuff has no penalty in DOS.
I assume under DOS it is a CPU vs disk-I/O tradeoff. But indeed UPX
frustrating the mapping of binaries that normal OSes have doesn't apply to
dos.
I'm told that DJGPPv2 apps load entirely into memory anyways via the
stub (except for debug info). I guess the DPMI provider could do
something with unused pages, but I don't think most do (even CWSDPMI).
Not sure what DPMIONE does, for instance. UPX is probably more
reliable than DoubleSpace or Stacker, IMHO, but I've never really
tried those (too timid), so I can't say for sure. However, high
cluster size (*shakes fist at 16k for > 512 MB FATs*) is annoying, so
anything to stem the waste ...!
Post by Marco van de Voort
In recent years I only used floppies for bios updates or loading drivers
during setup of OS installs.
Since Vista, the NT side of things finally also can postload drivers from
mass storage devices.
Right, I think that's what XP had to do, use floppies for drivers. And
yes, my P4 / XP updated its BIOS via DOS (I used FreeDOS). But my
Vista laptop has some native Win32 app to do so from within Windows
(weeeeeeiiiirrrrrrdddd!!!).
Post by Marco van de Voort
Post by Rugxulo
Post by Marco van de Voort
If you care about code and RTL size? Sure I think. It has the smaller COM
memory models that afaik later TPs don't have?
I worry if it's buggier due to being older. And I don't think anybody
in particular prefers .COMs over .EXEs since there is no inherent
advantage.
They execute faster, and are tighter? Do you need any more reasons? :-)
I guarantee that various modern machines vary in their speed of old
code, esp. 16-bit. And it definitely won't run faster than FPC in
DOSEMU x86-64!!! (That reminds me, I never did truly benchmark that
386 DJGPP compile of GCC 2.95.3 on my AMD64 vs. P4 ... I swear it runs
much faster on the AMD.)
Post by Marco van de Voort
Post by Rugxulo
Post by Marco van de Voort
In that the question similar to "Does TP 5.5 really have any
advantage over FPC?" :-)
Doubtful. Even I don't have any 286s around here (yet?? heh).
I don't even have anything x86 under a XP2000+ anymore. Actually those two
XP2000+'s are the only pure x86 systems that I have, all the others are
32/64-bit.
I do have slow machines (resp 110 and 40 MHz), but they are non-x86.
(joking) Don't test me, man, or I'll benchmark compile speeds on my
486. Let's compare TP55 vs. FPC! ;-)
Post by Marco van de Voort
Post by Rugxulo
Then again, is FPC fairly
fast to compile stuff?
Compared to what? TP ? No. GCC? Yes.
GCC, even old versions, is unbearable on a 486. Same with UPX. It's
actually much faster to copy to floppy, go to faster machine, do it
there, drink some coffee, then copy it back. (I'm told Turbo / Borland
C is quite slow on an 8086 also, heh.)
Post by Marco van de Voort
Post by Rugxulo
How big is the default install?
Close to 100 MB or so, but the default is full. There are ways to slim them
down (for dos there are individual packages). 10-25MB is probably possible,
and would be roughly equivalent to TP + cmdline Delphi.4
Eek. Okay, so it's still not nearly as bad as GNU Emacs 23.1
(full). ;-)

I know a lot of people whining about size annoys you, but in my case
it's necessary (and fun / interesting, heh) because of old hardware
and similar limitations (boot floppies). But I'm a rare (weird) case.
Post by Marco van de Voort
Post by Rugxulo
Only for such cases (or by chance if something didn't compile with FPC)
I'm a BP7 licensee, so even then I would not use TP55.
Well, 5.5 is the latest freeware version, so that's all most of us
have available.
Post by Marco van de Voort
The only interesting part for playing is Turbo Vision (I have a soft spot
not so much for Dos, but for fullscreen TUI programming), and I have that in
FPC for 98%.
Also used by RHIDE, as you probably know. BTW, that's one major
complaint from DOS / DJGPP users: that XP (and moreso Vista, 7)
crippled or broke RHIDE, which they preferred for its nice interface.
I never really used it, so it's no huge huge loss to me. Still, it was
a useful app. But without a maintainer and without decent OS support,
you're stuck. (If only virtualization and emulation wasn't so slow and
buggy and could share host OS files easily, then we could all be
happy.)
Marco van de Voort
2010-01-02 14:43:15 UTC
Permalink
Post by Rugxulo
Post by Marco van de Voort
Post by Rugxulo
So it won't run without go32.exe??
Afaik no, but I haven't tested that in a decade. If I used dos I simply used
the install with a bunch of files in it.
As mentioned, even GO32-V2.EXE needs CWSDPMI, so it's not a substitute
(although old old v1's GO32 predated CWSDPMI and hence didn't need
it). In v2 DPMI is always required unlike v1 where it could optionally
use other stuff (XMS, VCPI). Mixing v1 and v2 apps is rare since most
got updated or are redundant. (FYI, the Desqview/X toolkit used DJGPP
v1.)
FPC uses v2, apparantly I'm mistaking/outdated since go32.exe is no longer
in SVN
Post by Rugxulo
QEMM386 might've come with QDPMI (which did somewhat support virtual
memory), but I think that was somewhat buggy too and limited in total
RAM available for use (e.g. I'm told that QEMM 9.01 can only use 256
MB max).
When I still used Dos, I used qemm, and had 64MB iirc. No problems with
fpc/go32v2.
Post by Rugxulo
Post by Marco van de Voort
I assume under DOS it is a CPU vs disk-I/O tradeoff. But indeed UPX
frustrating the mapping of binaries that normal OSes have doesn't apply to
dos.
I'm told that DJGPPv2 apps load entirely into memory anyways via the
stub (except for debug info). I guess the DPMI provider could do
something with unused pages, but I don't think most do (even CWSDPMI).
Not sure what DPMIONE does, for instance.
Sure, but since they are not memory mapped, they have to be loaded first,
and only then paged out. And that doesn't matter for UPX, if the pages in
mem were compressed before or not.
Post by Rugxulo
UPX is probably more reliable than DoubleSpace or Stacker,
Well, I never had a antivirus balking at stacker. In dos times, I kept the
sources that were for reference only on a small stacker drive.
Post by Rugxulo
IMHO, but I've never really tried those (too timid), so I can't say for
sure. However, high cluster size (*shakes fist at 16k for > 512 MB FATs*)
is annoying, so anything to stem the waste ...!
I kept one 1GB partition FAT16, and the rest FAT32 for a long time, till
*nix FAT32 support was mature enough.
Post by Rugxulo
Post by Marco van de Voort
Since Vista, the NT side of things finally also can postload drivers from
mass storage devices.
Right, I think that's what XP had to do, use floppies for drivers. And
yes, my P4 / XP updated its BIOS via DOS (I used FreeDOS). But my
Vista laptop has some native Win32 app to do so from within Windows
(weeeeeeiiiirrrrrrdddd!!!).
There are a lot of different schemes. Even with one manufacterer (we use a
lot of MSI boards at work), it varies with each generation and target
market. Even reactos is slowly moving into this space.
Post by Rugxulo
Post by Marco van de Voort
They execute faster, and are tighter? Do you need any more reasons? :-)
I guarantee that various modern machines vary in their speed of old
code, esp. 16-bit. And it definitely won't run faster than FPC in
DOSEMU x86-64!!! (That reminds me, I never did truly benchmark that
386 DJGPP compile of GCC 2.95.3 on my AMD64 vs. P4 ... I swear it runs
much faster on the AMD.)
On fast computers, I never saw TP code outperform the same code in 32-bit if
the code was non-trivial.
Post by Rugxulo
Post by Marco van de Voort
I do have slow machines (resp 110 and 40 MHz), but they are non-x86.
(joking) Don't test me, man, or I'll benchmark compile speeds on my
486.
You only say that because you know I threw out my 386SX25 last year :-)
Post by Rugxulo
Post by Marco van de Voort
Post by Rugxulo
Then again, is FPC fairly fast to compile stuff?
Compared to what? TP ? No. GCC? Yes.
GCC, even old versions, is unbearable on a 486. Same with UPX. It's
actually much faster to copy to floppy, go to faster machine, do it
there, drink some coffee, then copy it back. (I'm told Turbo / Borland
C is quite slow on an 8086 also, heh.)
I'd guess that FPC speed is roughly GCC minus two specific GCC problems:
- the C disease to reparse headers again and again
- IIRC FPC/go32v2 has AS built in, so no need to call a separate assembler.

However I don't know how big this latter difference is. When FPC got the
internal assembler, the speed up was gigantic, but the "older" FPC model
might not match the GCC model (specially if GCC pipes the assembler to AS),
because afaik FPC wrote it to disk.
Post by Rugxulo
I know a lot of people whining about size annoys you, but in my case
it's necessary (and fun / interesting, heh) because of old hardware
and similar limitations (boot floppies). But I'm a rare (weird) case.
I never understood this. Size was always only a side objective, even when I
was on Dos with a 260MB HD. It was always primarily about getting things
done. After the gigabyta era, that pretty much went away, since most of
these factor were in the same magnitude as disk slack, and were no real
factor anymore. (the mp3 collections were bigger problems)

I even assisted people with 4k and 64k demo compos at a certain point, but
these never said it was "necessary", and never posted about their
self-inflicted limitations in newsgroups as if it were a general, universal
rule, something that has always greatly annoyed me in the residual TP
circles.
Post by Rugxulo
Post by Marco van de Voort
Post by Rugxulo
Only for such cases (or by chance if something didn't compile with FPC)
I'm a BP7 licensee, so even then I would not use TP55.
Well, 5.5 is the latest freeware version, so that's all most of us
have available.
Wasn't it TP7 french?
Post by Rugxulo
Post by Marco van de Voort
The only interesting part for playing is Turbo Vision (I have a soft spot
not so much for Dos, but for fullscreen TUI programming), and I have that in
FPC for 98%.
Also used by RHIDE, as you probably know.
Yes, but I never used that one, since IIRC it is a library that is GPL, not
LGPL. There is a BSD equivalent (by sb with an Italian sounding name)
though. The original version released by Borland is afaik not easily found
anymore.

The Pascal version was never released from copyright, so when Borland
started to crack down on 3rd party use of it, FPC switched to a version is a
backport of the freed C++ version to Pascal. This was afaik done by somebody
who wanted to make a graphical clone. (which meant backporting it to FPC
meant revisioning the whole coordinate system again, not trivial)
Post by Rugxulo
BTW, that's one major complaint from DOS / DJGPP users: that XP (and
moreso Vista, 7) crippled or broke RHIDE, which they preferred for its
nice interface.
One can also turn it the otherway around and blame RHIDE (or its users) for
never updating it to support windows.

Though afaik currently the dos IDE also works on XP, and even Vista.
Post by Rugxulo
I never really used it, so it's no huge huge loss to me. Still, it was a
useful app. But without a maintainer and without decent OS support, you're
stuck. (If only virtualization and emulation wasn't so slow and buggy and
could share host OS files easily, then we could all be happy.)
I always avoided such dead ends, and moved to the next one that had at least
some life in it, and started working. Or moved on if I didn't care enough to
do that.

Life is to precious to massively invest time to keep tools running
apparantly nobody cares around anymore. Specially when that is time that
isn't invested in the tool.
Rugxulo
2010-01-02 18:07:25 UTC
Permalink
Hi,
Post by Marco van de Voort
FPC uses v2, apparantly I'm mistaking/outdated since go32.exe is no longer
in SVN
From the looks of it, FPC 1.0.10 used to perhaps support v1 also
(source/rtl/go32v1 and source/rtl/go32v2). I think I've read that
DJGPP decided it was too much trouble to support both DPMI and e.g.
VCPI or whatever, so they didn't bother in v2. DPMI was usually the
best way to use lots of RAM on OS/2 and Windows "back in the day."
However, nowadays it's fairly moot as NTVDM isn't regarded as having
much of a future (even on 32-bit).

P.S. I could be wrong, but it seems go32v1 apps run fine on Vista but
not on XP (you can use RSX, though). This is probably the only
improvement I know of, offhand. ;-)
Post by Marco van de Voort
When I still used Dos, I used qemm, and had 64MB iirc. No problems with
fpc/go32v2.
But did you use QDPMI or not? I think CWSDPMI is still considered
better.
Post by Marco van de Voort
Sure, but since they are not memory mapped, they have to be loaded first,
and only then paged out. And that doesn't matter for UPX, if the pages in
mem were compressed before or not.
Well, there are other DOS extenders that were demand loaded (e.g.
MOSS, I think), but those were rare. And even that was mostly written
to support a commercial game on 486s, so you kinda had to have
something (as the main .EXE had data combined with it for a 17 MB
whopper).
Post by Marco van de Voort
Post by Rugxulo
UPX is probably more reliable than DoubleSpace or Stacker,
Well, I never had a antivirus balking at stacker. In dos times, I kept the
sources that were for reference only on a small stacker drive.
I think various things would have issues, but I never bothered finding
out. The compression ratio is probably subpar anyways (although I
never converted all my .ZIPs to .7z either, so ...). Also not good for
dual booting.
Post by Marco van de Voort
Post by Rugxulo
IMHO, but I've never really tried those (too timid), so I can't say for
sure. However, high cluster size (*shakes fist at 16k for > 512 MB FATs*)
is annoying, so anything to stem the waste ...!
I kept one 1GB partition FAT16, and the rest FAT32 for a long time, till
*nix FAT32 support was mature enough.  
MS patents on FAT32 still exist, which is annoying. Last I heard,
Linux moved to a "read-only" hack, then made it where it would only
save the LFN part, not SFN, to avoid problems. Kinda silly in this day
and age, but oh well.

BTW, what I mainly meant was that several DOSes (e.g. official DR-DOS)
never had FAT32 support (and mine never came with any beta TSRs
either), so you're kinda stuck. In short, never ever use FAT16 with >
512 MB. I should've split mine up into several FAT16 partitions so
that it would be 8k clusters instead of 16k (horrible for lots of
small files).
Post by Marco van de Voort
Post by Rugxulo
I guarantee that various modern machines vary in their speed of old
code, esp. 16-bit. And it definitely won't run faster than FPC in
DOSEMU x86-64!!!
On fast computers, I never saw TP code outperform the same code in 32-bit if
the code was non-trivial.
Well, x86-64 has no 16-bit, so DOSEMU has to emulate it. It's
noticeably slow for that, but 32-bit (e.g. DJGPP) is "native speed".
But you're right, even on 486s, 32-bit code is faster because that was
the design intention. So there usually is no comparison. Doesn't mean
there aren't corner cases, but for the most part it does run pretty
fast. DJGPP has never been considered slow.
Post by Marco van de Voort
Post by Rugxulo
(joking) Don't test me, man, or I'll benchmark compile speeds on my
486.
You only say that because you know I threw out my 386SX25 last year :-)
My 486 still runs (barely), so if you have any reasonable benchmarks,
I'll try them for ya.
Post by Marco van de Voort
- the C disease to reparse headers again and again
- IIRC FPC/go32v2 has AS built in, so no need to call a separate assembler.
Precompiled headers are pretty much unsupported in DOS, last I heard.
Post by Marco van de Voort
However I don't know how big this latter difference is. When FPC got the
internal assembler, the speed up was gigantic, but the "older" FPC model
might not match the GCC model (specially if GCC pipes the assembler to AS),
because afaik FPC wrote it to disk.
DJGPP's GCC doesn't support -pipe (although EMX under OS/2 does,
IIRC). However, using a RAM disk probably helps. That's what I use
when compiling (and cache).

As you probably know, OpenWatcom has a built-in assembler, and it
directly outputs to .OBJ, so usually it's much faster than GCC (e.g.
Windows). Then again, one particular C++ app I hacked a bit compiles
at almost the same speed on my P166 (DR-DOS) when using OW 1.8 or G++
3.4.4. (Even using DOS/32A vs. DOS/4GW was slower.) So it highly
depends. (Of course, I've heard that the Win32 version of OpenWatcom
uses .DLLs and is thus much faster due to less reloading.)
Post by Marco van de Voort
I never understood this. Size was always only a side objective, even when I
was on Dos with a 260MB HD. It was always primarily about getting things
done. After the gigabyta era, that pretty much went away
A lot of times it doesn't matter much, that's true. And as mentioned,
smallest != fastest anymore. But there are still limits on certain
things: bandwidth, attachment size, download speed, cpu cache,
available memory (DPMI, VCPI, XMS), USB drive capacity, cluster size,
etc.

It's mainly when you *know* that things could be smaller but aren't. I
mean, why the heck does Vista / 7 need 16 GB when XP only needs like 1
or 2 GB?? Where did all that space go? I know it's been said that it
can shrink to 7 GB (gee, wow), but that's still strange to me. So a
DOS app that runs in DOS or Vista or OS/2 is (IMHO) superior to a
Vista-only app, esp. because a Vista install is so huge and expensive
(vs. FreeDOS, at least). Well, eCS ain't cheap either.
Post by Marco van de Voort
I even assisted people with 4k and 64k demo compos at a certain point, but
these never said it was "necessary", and never posted about their
self-inflicted limitations in newsgroups as if it were a general, universal
rule, something that has always greatly annoyed me in the residual TP
circles.
Unless they are assembly programmers, the whiners aren't going to have
much of a guess at why things are larger. You can indeed use high-
level optimizations for size, but a lot of that won't make as much of
a difference unless you get down to the bare metal. Even then it's
extremely tough. Long story short: 16-bit code is always smaller, and
compilers are only oriented towards speed. And 16-bit DPMI (16 MB
limit ftw!) was never utilized much, esp. since you can't co-mingle
with 32-bit DPMI without DPMI 1.0 (which Windows never supported, even
OS/2 only goes halfway to pseudo "0.95", I think).
Post by Marco van de Voort
Post by Rugxulo
Well, 5.5 is the latest freeware version, so that's all most of us
have available.
Wasn't it TP7 french?
I don't know. At the very least, I never investigated that too
closely. Besides, no parlais francais. ;-)
Post by Marco van de Voort
Post by Rugxulo
BTW, that's one major complaint from DOS / DJGPP users: that XP (and
moreso Vista, 7) crippled or broke RHIDE, which they preferred for its
nice interface.
One can also turn it the otherway around and blame RHIDE (or its users) for
never updating it to support windows.
DPMI *is* for Windows (and OS/2). So much work has gone into revising
DJGPP, working around bugs, being LFN-aware, etc. But there's only so
much they can do. I really don't want to blame MS, but it really is
indirectly their fault. I know they probably didn't intend that, but
that's the way it is.

Porting RHIDE to Windows doesn't help DOS, and DJGPP is only a DOS
compiler. While in theory you can have dual DOS / Win apps (or DOS /
OS2), nobody ever does. And most linkers can't handle binding those
together anyways. (Besides, RHIDE needs GCC 3.x, I think. So that
would need fixing too.) For instance, RSXNT/DJ is long since abandoned
(ten years).
Post by Marco van de Voort
Though afaik currently the dos IDE also works on XP, and even Vista.
No, not on Vista, there is no full-screen unless you find / install
old XP drivers, which disables Aero. Apparently even disabling
"desktop composition" disables Aero (I think??), which is how I'm
setup now. Otherwise at every UAC popup (ugh), the screen would go
black for five seconds before becoming responsive. I got tired of
that, found the cause, but now I can't use Flip3D, and Chess Titans
ain't 3D (sniff, heh, like I care). Could be a driver issue on my end,
but there's not much I can do about that.

FP.EXE (IDE) works in DOSBox, but that's about it.
Post by Marco van de Voort
I always avoided such dead ends, and moved to the next one that had at least
some life in it, and started working. Or moved on if I didn't care enough to
do that.
Life is to precious to massively invest time to keep tools running
apparantly nobody cares around anymore. Specially when that is time that
isn't invested in the tool.
It just seems easier to me to have one working binary instead of ten.
There's no good reason for breaking old compatibility when it just
complicates things further. Sadly, we're all at the mercy of our
hardware and available drivers. So even the OS isn't fully to blame
(sometimes). But I don't really think C#/.NET or Java is the answer
either. Maybe virtualization is, but it's still got a ways to go.
Rugxulo
2010-01-02 21:28:31 UTC
Permalink
Hi again,
Post by Rugxulo
Post by Marco van de Voort
On fast computers, I never saw TP code outperform the same code in 32-bit if
the code was non-trivial.
A 386 and a 486 are different animals, e.g. LODSB isn't much (if any)
penalty on the former but heavily slower on the latter. Granted, I've
never truly optimized for those processors, so I can't say for sure,
but in other words, what was fast then ain't as fast now. (Even GCC
2.8.x supposedly brought about 20% improvements due to Pentium
pairing, which I'm sure TP was never aware of.) And I know you know
that PentiumPros were heavily slow for 16-bit code (worse than
original Pentiums, even).
Post by Rugxulo
Post by Marco van de Voort
I never understood this. Size was always only a side objective, even when I
was on Dos with a 260MB HD. It was always primarily about getting things
done. After the gigabyta era, that pretty much went away
It's mainly when you *know* that things could be smaller but aren't.
Post by Marco van de Voort
I even assisted people with 4k and 64k demo compos at a certain point, but
these never said it was "necessary",
Unless they are assembly programmers, the whiners aren't going to have
much of a guess at why things are larger.
Well, for instance, \demo\graph\fpctris.pp seems to be almost twice as
big with 2.4.0 vs. 1.0.10 (maybe I built it wrong??). I know it's
meant to be portable, and it IS 32-bit, pmode, high-level, so most of
that is explainable. However, keep in mind that I've seen a 360-byte
graphical tetris program (in asm, of course). ;-)
Post by Rugxulo
Post by Marco van de Voort
Though afaik currently the dos IDE also works on XP, and even Vista.
No, not on Vista, there is no full-screen unless you find / install
old XP drivers, which disables Aero. Apparently even disabling
"desktop composition" disables Aero (I think??), which is how I'm
setup now. Otherwise at every UAC popup (ugh), the screen would go
black for five seconds before becoming responsive. I got tired of
that, found the cause, but now I can't use Flip3D, and Chess Titans
ain't 3D (sniff, heh, like I care). Could be a driver issue on my end,
but there's not much I can do about that.
Oops, Chess Titans is indeed still 3D (although doesn't really look it
to my eyes) vs. 2D mode. But none of the other goodies (Flip3D, window
translucency) work without desktop composition. (And yes, the five
second delay is still there, before *and* after UAC pops up, so IF it
is the driver, it's still slow as heck. But I'll admit my gfx card is
fairly cheap / low-end (nVIDIA GeForce Go 6100, 1280x800, 32-bit
display mode, only 64 MB VRAM though), and it's the main factor in my
"Windows Experience" being only 2.4, heh, although the Aero part
scores 3.2, oddly, and the rest is in mid-4s.)
Post by Rugxulo
FP.EXE (IDE) works in DOSBox, but that's about it.
BTW, I mean the 486 emulator from www.dosbox.com here. I've just
retested it, still won't run in normal NTVDM (it must be calling some
VESA interrupt or such, which flags Windows, ugh.) I haven't
personally used Win7 either, but I'm fairly certain it has the same
limitation. :-(
Marco van de Voort
2010-01-03 15:01:04 UTC
Permalink
Post by Rugxulo
Post by Marco van de Voort
FPC uses v2, apparantly I'm mistaking/outdated since go32.exe is no longer
in SVN
From the looks of it, FPC 1.0.10 used to perhaps support v1 also
(source/rtl/go32v1 and source/rtl/go32v2).
FPC did support go32v1, but I never saw it run. When I joined in 1997/8 iirc
it was already v2. People have played with a bunch more extenders too
(pmode, watcom), but none really stuck.
Post by Rugxulo
However, nowadays it's fairly moot as NTVDM isn't regarded as having
much of a future (even on 32-bit).
Well, it hasn been like that since w2000 didn't notably improve. And then we
are talking about 2000/2001 timeframe, and it hasn't stopped many.

This why we never supported Dos on NT based systems. We did commit decent
fixes though, which why it now at least runs on XP halfdecently.
Post by Rugxulo
P.S. I could be wrong, but it seems go32v1 apps run fine on Vista but
not on XP (you can use RSX, though). This is probably the only
improvement I know of, offhand. ;-)
I've never run v1.
Post by Rugxulo
Post by Marco van de Voort
When I still used Dos, I used qemm, and had 64MB iirc. No problems with
fpc/go32v2.
But did you use QDPMI or not? I think CWSDPMI is still considered
better.
Yes.

CWSDPMI, maybe, but Qemm never gave me much trouble after v5, and one
configuration worked relatively well. 4dos-hyperdisk-qemm and quite a bit
of DV/X was my config at the time.

In practice I only had one other bootoption, one with only himem and 4dos.
Since nearly all programs that actually used memory could use higher memory
and were at least 286 extended, optimizing for maximum conventional memory
beyond having 600kb free was not terribly interesting.
Post by Rugxulo
Post by Marco van de Voort
Sure, but since they are not memory mapped, they have to be loaded first,
and only then paged out. And that doesn't matter for UPX, if the pages in
mem were compressed before or not.
Well, there are other DOS extenders that were demand loaded (e.g.
MOSS, I think), but those were rare. And even that was mostly written
to support a commercial game on 486s, so you kinda had to have
something (as the main .EXE had data combined with it for a 17 MB
whopper).
I can imagine a separate dos extender being like a pager. But afaik Dos
itself always loads the binary whole? OTOH, that could be avoided by having
a PE like format (where dos also only loads the stub).

But to be honest, I don't really know in detail how this works in dos.
Post by Rugxulo
Post by Marco van de Voort
Post by Rugxulo
UPX is probably more reliable than DoubleSpace or Stacker,
Well, I never had a antivirus balking at stacker. In dos times, I kept the
sources that were for reference only on a small stacker drive.
I think various things would have issues, but I never bothered finding
out. The compression ratio is probably subpar anyways
Of course. But there are reasons, roughly the same reasons why I only used
solid archives for longterm archival purposes.
Post by Rugxulo
(although I never converted all my .ZIPs to .7z either, so ...). Also not
good for dual booting.
I converted them all to .Q at some point. It was the rage back then.
Post by Rugxulo
Post by Marco van de Voort
I kept one 1GB partition FAT16, and the rest FAT32 for a long time, till
*nix FAT32 support was mature enough.  
MS patents on FAT32 still exist, which is annoying.
So I'll create my partition with my licensed XP/Vista. Big deal :-)
Post by Rugxulo
Last I heard, Linux moved to a "read-only" hack, then made it where it
would only save the LFN part, not SFN, to avoid problems. Kinda silly in
this day and age, but oh well.
Afaik that is mostly debian and followers, not as much Linux as a whole. But
it is a problem indeed. And history seems to be repeating with the now
proposed fatex/fatplus. A different solution is using SUSE, or anything else
by Novell.

IOW the fat patents are more against the Sony/Philips/photocamera
manufacterers then against linux.

We can only hope that somepoint in the future the MS IP portfolio costs more
than it brings, and they cancel a while later. The usual Debian
holier-than-thou attitude will probably mean that FAT32 will be
postinstalled for a whole time longer.
Post by Rugxulo
BTW, what I mainly meant was that several DOSes (e.g. official DR-DOS)
never had FAT32 support (and mine never came with any beta TSRs
either), so you're kinda stuck. In short, never ever use FAT16 with >
512 MB. I should've split mine up into several FAT16 partitions so
that it would be 8k clusters instead of 16k (horrible for lots of
small files).
I don't think I have used a non MSDOS7 version after say '98. And those were
even the exception (gaming and tests mostly), usually it was under w9x.

When I used w2000 more and more at work, I started to replace more and more
tools with win32 versions, and a few years later (2002 or so) chucked w9x
all together. It helped that the license was my employer's though, since w2k
was expensive at the time.
Post by Rugxulo
Post by Marco van de Voort
On fast computers, I never saw TP code outperform the same code in 32-bit if
the code was non-trivial.
Well, x86-64 has no 16-bit, so DOSEMU has to emulate it.
(or chuck 16-bit. Not terribly painful. My maindesktop is 64-bit nowdays.
OTOH while I'm writing this, I'm programming a 8K, 40MIPS microprocessor in
GCC)
Post by Rugxulo
But you're right, even on 486s, 32-bit code is faster because that was the
design intention. So there usually is no comparison. Doesn't mean there
aren't corner cases, but for the most part it does run pretty fast. DJGPP
has never been considered slow.
All 486's that ran 32-bit code were secondary machines that typically ran
Linux or BSD. I only had Dos on my Cyrix P166+ main desktop.
Post by Rugxulo
Post by Marco van de Voort
You only say that because you know I threw out my 386SX25 last year :-)
My 486 still runs (barely), so if you have any reasonable benchmarks,
I'll try them for ya.
The only interest I would have (if I suddenly got unlimited time) is to test
the FPU emulation situation. But it could be that 2.4.0 now is PPRO (cmov)
default.
Post by Rugxulo
Post by Marco van de Voort
- the C disease to reparse headers again and again
- IIRC FPC/go32v2 has AS built in, so no need to call a separate assembler.
Precompiled headers are pretty much unsupported in DOS, last I heard.
TC++ probably does fine.

As far as DJGPP/GCC goes, does gcc support them at all? ccached can cache
I/O time of finding/loading headers, but that is not the same as precompiled
headers afaik.
Post by Rugxulo
DJGPP's GCC doesn't support -pipe (although EMX under OS/2 does,
IIRC)
OS/2 does have decent pipes in principle, like cousin NT.
Post by Rugxulo
As you probably know, OpenWatcom has a built-in assembler, and it
directly outputs to .OBJ, so usually it's much faster than GCC (e.g.
Windows).
So does FPC. On Windows it even has the linker built-in. Still, FPC is
slower than most older systems (GCC excepted). The focus has been more
maintainability.
Post by Rugxulo
Then again, one particular C++ app I hacked a bit compiles at almost the
same speed on my P166 (DR-DOS) when using OW 1.8 or G++ 3.4.4. (Even using
DOS/32A vs. DOS/4GW was slower.) So it highly depends. (Of course, I've
heard that the Win32 version of OpenWatcom uses .DLLs and is thus much
faster due to less reloading.)
Yes. First is internal asm, 2nd not restarting for every compilation unit,
3rd is precompiled headers or (better) unit system.
Post by Rugxulo
It's mainly when you *know* that things could be smaller but aren't
That still doesn't promote it from a secondary or even tertiary problem to a
primary one. Specially not with 2TB disks routinely sold. (though my
"fast" disk is only 300GB)

Everybody knows these things, and that (and why) newer versions
are bigger. Only a few percentage acts on it (and I often doubt their
reasons why)
Post by Rugxulo
Post by Marco van de Voort
I even assisted people with 4k and 64k demo compos at a certain point, but
these never said it was "necessary", and never posted about their
self-inflicted limitations in newsgroups as if it were a general, universal
rule, something that has always greatly annoyed me in the residual TP
circles.
Unless they are assembly programmers, the whiners aren't going to have
much of a guess at why things are larger.
4k was asm, 64k was TP though with mostly asm inline and custom cut down
RTL.
Post by Rugxulo
Even then it's extremely tough. Long story short: 16-bit code is always
smaller, and compilers are only oriented towards speed.
Or, more importantly, towards current tradeoffs, not the ones from 1995.
Post by Rugxulo
Post by Marco van de Voort
Post by Rugxulo
Well, 5.5 is the latest freeware version, so that's all most of us
have available.
Wasn't it TP7 french?
I don't know. At the very least, I never investigated that too
closely. Besides, no parlais francais. ;-)
Speaking no, reading a bit. But even if you don't, you can dowith just
hitting the places where you know the menuentries are from memory. But maybe
it is no longer available due to the borland->embarcadero change.
Post by Rugxulo
Post by Marco van de Voort
One can also turn it the otherway around and blame RHIDE (or its users) for
never updating it to support windows.
DPMI *is* for Windows (and OS/2).
For dos *migrational purposes* to windows and OS/2 yes. But that is
something else than for Windows and OS/2. Migration period is over.
Post by Rugxulo
So much work has gone into revising DJGPP, working around bugs, being
LFN-aware, etc. But there's only so much they can do. I really don't want
to blame MS, but it really is indirectly their fault. I know they probably
didn't intend that, but that's the way it is.
I'm not really a free-market bigot, but even MS does direct itself a bit in
the direction where customers are going. And (specially new) users adopted
win 3.x (which IMHO was not good enough to touch with a bargepole) en
masse. Corporate and home-. Then it was already clear that Dos was doomed,
moreover when Word started to rapidly replace WP.

Even after one year win95, already the bulk of the users didn't know dos.

The trouble with DJGPP is that their project's identity is unconditionally
bound to Dos.
Post by Rugxulo
Porting RHIDE to Windows doesn't help DOS, and DJGPP is only a DOS
compiler.
That's the real problem. If you choose to remain on a small island, there is
a fair chance you'll be left alone. Specially if the island is crumbling bit
by bit.
Post by Rugxulo
Post by Marco van de Voort
Though afaik currently the dos IDE also works on XP, and even Vista.
No, not on Vista, there is no full-screen unless you find / install
old XP drivers, which disables Aero.
Indeed, it refuses. Any idea what causes this? IOW which interrupt or
whatever triggers this? (djggp_setctrlC) or so?
Post by Rugxulo
Post by Marco van de Voort
Life is to precious to massively invest time to keep tools running
apparantly nobody cares around anymore. Specially when that is time that
isn't invested in the tool.
It just seems easier to me to have one working binary instead of ten.
True. But why does it have to be on the most difficult target?
Post by Rugxulo
(sometimes). But I don't really think C#/.NET or Java is the answer
either. Maybe virtualization is, but it's still got a ways to go.
I think virtualization can lengthen the final axe a bit, but is no solution
either. Java is essnetially a virtualized environment.
Rugxulo
2010-01-03 20:00:55 UTC
Permalink
Hi,
Post by Marco van de Voort
FPC did support go32v1, but I never saw it run. When I joined in 1997/8 iirc
it was already v2.
v2 is from 1996, so that's why. It's much more stable and compatible
although technically DJGPP v2 has no separate extender anymore, that
part is built into the lib. It only needs and can only use DPMI (which
is a "standard"). Of course, v2 apps are bigger due to this, but then
again, go32.exe is fairly bulky too (78k), but UPX only handles v2, so
it's a fair tradeoff.
Post by Marco van de Voort
People have played with a bunch more extenders too
(pmode, watcom), but none really stuck.
Yeah, I should try those w/ FPC, but it seems WDOSX doesn't work in
the DOS version, so I guess it must rely on Win32 RTL.
Post by Marco van de Voort
Post by Rugxulo
However, nowadays it's fairly moot as NTVDM isn't regarded as having
much of a future (even on 32-bit).
Well, it hasn been like that since w2000 didn't notably improve. And then we
are talking about 2000/2001 timeframe, and it hasn't stopped many.
2000 was improved over NT 4 with LFN functions, and XP was improved
over 2000 with SB emulation. And XP was most recent for a long time
(2001-2007) and was quite reliable. Vista isn't really too too bad w/
the DPMI registry hack, but the lack of full-screen a few other bugs
kinda hurt.
Post by Marco van de Voort
This why we never supported Dos on NT based systems. We did commit decent
fixes though, which why it now at least runs on XP halfdecently.
XP is so widespread, it makes sense to support it, if possible. That
was part of the appeal of DOS software, it ran everywhere. But
nowadays that's getting rarer and rarer (lots less Win9x or pure DOS
installs). Of course, install base alone isn't a good reason to write
software for a specific OS, but it doesn't hurt.
Post by Marco van de Voort
I've never run v1.
I don't think you're missing much. Even I don't use many (or any?) v1
apps, off the top of my head.
Post by Marco van de Voort
In practice I only had one other bootoption, one with only himem and 4dos.
Since nearly all programs that actually used memory could use higher memory
and were at least 286 extended, optimizing for maximum conventional memory
beyond having 600kb free was not terribly interesting.
Some DOSes (e.g. DR-DOS) were better at saving low RAM than others.
And by "286 extended", I guess you mean XMS, as 16-bit pmode is fairly
rare (well, maybe more nowadays). But even XMS wasn't commonly used
with every app (lots of wimpy text editors out there).

As you know, OS/2 1.x wasn't as appealing for breaking the 640k
barrier because DOS extenders already did it. ;-)
Post by Marco van de Voort
Post by Rugxulo
Well, there are other DOS extenders that were demand loaded (e.g.
MOSS, I think), but those were rare.
I can imagine a separate dos extender being like a pager. But afaik Dos
itself always loads the binary whole? OTOH, that could be avoided by having
a PE like format (where dos also only loads the stub).
MOSS was ELF-based, and it definitely didn't need 17 MB of RAM because
it claimed to run on a lowly 486 w/ 8 MB. I guess DOS ignores the
overlay part (a.out) and only loads the extender proper (moss.exe),
which handles the dirty work.
Post by Marco van de Voort
But to be honest, I don't really know in detail how this works in dos.
And I do?? I think only the authors of said tools would really know!
(It's complicated!)
Post by Marco van de Voort
Of course. But there are reasons, roughly the same reasons why I only used
solid archives for longterm archival purposes.
Semi-solid (or with recovery info) is best although in reality I never
bother (probably should, though).
Post by Marco van de Voort
Post by Rugxulo
(although I never converted all my .ZIPs to .7z either, so ...). Also not
good for dual booting.
I converted them all to .Q at some point. It was the rage back then.
Quantum? Too slow, there are much faster options (esp. these days).
Post by Marco van de Voort
Post by Rugxulo
MS patents on FAT32 still exist, which is annoying.
So I'll create my partition with my licensed XP/Vista. Big deal :-)
Except they only let you create FAT32 w/ 32 GB max size (yet another
"father knows best" limit). Not that I can imagine wanting more than
that for pure DOS, but still .... And it's not the FAT32 itself that
is patented, just certain additions (e.g. VFAT LFN hack).
Post by Marco van de Voort
I don't think I have used a non MSDOS7 version after say '98. And those were
even the exception (gaming and tests mostly), usually it was under w9x.
Well, DR-DOS kinda gave up the ghost (at least in development), so it
stagnated. Win9x only ran atop MS-DOS anyways (without some private
hack that DR never released). And DR / Caldera / Lineo changed hands
too many times. And Linux is more popular. Strange that DOS (and
related software) is considered so dead and useless and yet held onto
so tightly at the same time.
Post by Marco van de Voort
When I used w2000 more and more at work, I started to replace more and more
tools with win32 versions, and a few years later (2002 or so) chucked w9x
all together. It helped that the license was my employer's though, since w2k
was expensive at the time.
Win2k was never for home users, hence why XP is more popular. 2k / XP
aren't bad, but it heavily annoys me when apps won't run anywhere else
(e.g. Win98SE) and/or require specific versions of MSVCRT. I don't see
how that's better than being ultra-compatible. Why would anybody want
to be less compatible?? But they do!
Post by Marco van de Voort
Post by Rugxulo
Post by Marco van de Voort
On fast computers, I never saw TP code outperform the same code in 32-bit if
the code was non-trivial.
Well, x86-64 has no 16-bit, so DOSEMU has to emulate it.
(or chuck 16-bit. Not terribly painful. My maindesktop is 64-bit nowdays.
OTOH while I'm writing this, I'm programming a 8K, 40MIPS microprocessor in
GCC)
16-bit isn't evil or useless, but yeah, almost nobody prefers it. It's
not that it's too horrible to convert, but then again, in such a
closed environment (Windows), it really is asking a lot to make people
dump all their old software. Sure, some of it is extremely crusty and
should be retired, but there are more than a few gems in there worth
preserving. Just being 32-bit (or 64-bit) doesn't make software better
(or good, even).
Post by Marco van de Voort
As far as DJGPP/GCC goes, does gcc support them at all? ccached can cache
I/O time of finding/loading headers, but that is not the same as precompiled
headers afaik.
No support for precompiled headers, last I heard. No -pipe, no
threading, etc. It pretty much just relies on RAM drive for temps and
software cache.
Post by Marco van de Voort
Post by Rugxulo
It's mainly when you *know* that things could be smaller but aren't
That still doesn't promote it from a secondary or even tertiary problem to a
primary one. Specially not with 2TB disks routinely sold. (though my
"fast" disk is only 300GB)
I don't think 2 TB is quite standard yet. That's very high end. I
don't see ads with new computers with anywhere near that much.
Besides, isn't the MBR limited to like 1.5 TB or such?? (I forget....)
Post by Marco van de Voort
Everybody knows these things, and that (and why) newer versions
are bigger. Only a few percentage acts on it (and I often doubt their
reasons why)
Obviously FPC could definitely use lots more testers, contributors,
etc. I'm just afraid I don't have much to offer.
Post by Marco van de Voort
Post by Rugxulo
Post by Marco van de Voort
One can also turn it the otherway around and blame RHIDE (or its users) for
never updating it to support windows.
DPMI *is* for Windows (and OS/2).
For dos *migrational purposes* to windows and OS/2 yes. But that is
something else than for Windows and OS/2. Migration period is over.
It wasn't migrational (at least, in theory), it was meant for a way
for all the various extenders to "get along" with each other and esp.
with multitasking environments.
Post by Marco van de Voort
The trouble with DJGPP is ...
read more »
Oy! To be continued ....
Rugxulo
2010-01-03 20:39:29 UTC
Permalink
Hi again,
Post by Marco van de Voort
I'm not really a free-market bigot, but even MS does direct itself a bit in
the direction where customers are going. And (specially new) users adopted
win 3.x (which IMHO was not good enough to touch with a bargepole) en
masse. Corporate and home-. Then it was already clear that Dos was doomed,
moreover when Word started to rapidly replace WP.
I think you're mistaken. Win 3.0 came out in 1990, and that's where
DPMI actually debuted. In 386 enhanced mode you could finally
multitask several DOS 32-bit pmode apps. That was not possible with OS/
2 (until 2.0 in 1992) because (allegedly) IBM was stuck on supporting
286s (which isn't really that bad a thing). So MS and IBM parted ways.
If you think DOS was doomed, you forgot that Win3.x ran atop DOS (even
DR-DOS), and even Win9x ran atop MS-DOS 7. So DOS was far from dead,
just hidden because MS prefers GUIs as the way of the future (probably
inspired by the original Mac). Sure, NT has no DOS because it's fully
32-bit, written from scratch, very portable (initially). They probably
would've switched to it exclusively much earlier if hardware could
keep up with the higher software requirements. Until Win95, you could
really only write 32-bit apps in DOS (well, unless you count Win32s,
or did that only come out later? No, it stood for WinNT "s"ubset,
right?)
Post by Marco van de Voort
Even after one year win95, already the bulk of the users didn't know dos.
I disagree. The main cliche to mention here would be Quake (late 1996)
using DJGPPv2 (2.00beta3, GCC 2.7.2). Or any DJGPP tools themselves,
even, which kept being updated.

It doesn't mean DOS didn't have deficiencies (esp. drivers), but you
can't say "Linux / FreeBSD is teh rox0rz" without admitting that
FreeDOS could legitimately be extended in similar fashion too. "Oh,
but then it wouldn't be DOS." And yet Linux 0.001 still counts as
Linux?!? What about everything prior to 2.2? 2.4? x86-64? Is it still
Linux?? Apparently so.
Post by Marco van de Voort
The trouble with DJGPP is that their project's identity is unconditionally bound to Dos.
That's unavoidable, esp. since that's all DJGPP ever was for: DOS.

Originally DJGPPv1 used a.out, but then (1992?) they switched to COFF.
"Best available format at the time" is what I've heard. And Linux
didn't switch to ELF until 1996 or so. WinNT variants all use PE/COFF,
so in theory it should be possible to make dual .EXEs. (EMX [VCPI]
used a.out, RSX was the DPMI rewrite of EMX by someone else, and RSX
could also run DJGPPv1 apps.) Japheth mentions how to make PEs for HX
with DJGPP. CWS himself ran an aborted experiment in 1995 to make
dual .EXEs (but a Texas flood washed away his efforts). RSXNT/DJ
succeeds but is old and abandoned. The only other example I can think
of in a similar vein is Josh Vanderhoof's (?) cross ELF tools (e.g.
xlink.com or xlink.exe can run same ELF under DOS, Windows, etc). Oh,
and Daniel Borca's fork of DJGPP 2.04 to ELF (GCC 4.0.1, BinUtils
2.16) still uses the DJGPP DOS C library (for COFF or ELF) but
optionally (ELF only) can create its own .so files or use .so files
from Linux.
Post by Marco van de Voort
Post by Rugxulo
Porting RHIDE to Windows doesn't help DOS, and DJGPP is only a DOS
compiler.
That's the real problem. If you choose to remain on a small island, there is
a fair chance you'll be left alone. Specially if the island is crumbling bit
by bit.
MS either won't or (more likely) can't fix NTVDM. RHIDE no longer
works (whereas it worked fine for ten years or so). So now the only
option in your eyes is to drop DOS, DJGPP, etc. and move exclusively
to Win32? And build RHIDE exclusively for Win32? If someone crashes
into your car, do you go immediately buy a new one (and make sure it's
completely different: truck, perhaps?)?
Post by Marco van de Voort
Post by Rugxulo
Post by Marco van de Voort
Though afaik currently the dos IDE also works on XP, and even Vista.
No, not on Vista, there is no full-screen unless you find / install
old XP drivers, which disables Aero.
Indeed, it refuses. Any idea what causes this? IOW which interrupt or
whatever triggers this?  (djggp_setctrlC) or so?
No idea, probably int 10h somewhere (even VESA BIOS id check would do
it, ugh).
Post by Marco van de Voort
Post by Rugxulo
It just seems easier to me to have one working binary instead of ten.
True. But why does it have to be on the most difficult target?
What do you suggest instead???
Marco van de Voort
2010-01-03 21:56:47 UTC
Permalink
Post by Rugxulo
286s (which isn't really that bad a thing). So MS and IBM parted ways.
If you think DOS was doomed, you forgot that Win3.x ran atop DOS (even
DR-DOS), and even Win9x ran atop MS-DOS 7.
Which meant absolutely nothing from most users perspective. Is like a Mac
with Forth based bootstrap not making every Mac users Forth experts. (or
even know what it is)

And yes, DPMI was originally created to make >640kb use over a range of OSes
possible. But mostly for their dos compatibility modes.
Post by Rugxulo
Until Win95, you could really only write 32-bit apps in DOS (well, unless
you count Win32s, or did that only come out later?
No idea.
Post by Rugxulo
Post by Marco van de Voort
Even after one year win95, already the bulk of the users didn't know dos.
I disagree. The main cliche to mention here would be Quake (late 1996)
using DJGPPv2 (2.00beta3, GCC 2.7.2). Or any DJGPP tools themselves,
even, which kept being updated.
Quickly followed by quake '95. That says enough.
Post by Rugxulo
It doesn't mean DOS didn't have deficiencies (esp. drivers), but you
can't say "Linux / FreeBSD is teh rox0rz" without admitting that
(I can't even decrypt that, leet speak is beyond me)
Post by Rugxulo
FreeDOS could legitimately be extended in similar fashion too. "Oh,
but then it wouldn't be DOS."
The point is nobody cared.
Post by Rugxulo
And yet Linux 0.001 still counts as Linux?!? What about everything prior
to 2.2? 2.4? x86-64? Is it still Linux?? Apparently so.
You got a point there. It also has been one of the weaknesses of Linux, the
absense of long runnable binaries.
Post by Rugxulo
Post by Marco van de Voort
That's the real problem. If you choose to remain on a small island, there is
a fair chance you'll be left alone. Specially if the island is crumbling bit
by bit.
MS either won't or (more likely) can't fix NTVDM. RHIDE no longer
works (whereas it worked fine for ten years or so). So now the only
option in your eyes is to drop DOS, DJGPP, etc. and move exclusively
to Win32?
Stronger. I think that should have been done in 2000-2005 somewhere.

IOW I think it is too late now, after the large gap. Even if sb really
invests a lot of time, most of the users that one could have kept
(educatioal, or only for the fun of it) moved one.

Same happened with FPC textmode IDE more or less. Naot DOS, but related to
the same group.
Post by Rugxulo
And build RHIDE exclusively for Win32? If someone crashes into your car,
do you go immediately buy a new one (and make sure it's completely
different: truck, perhaps?)?
If the old car type was somehow doomed, yes of course! Not because I would
want change, just for practical reasons.
Post by Rugxulo
Post by Marco van de Voort
True. But why does it have to be on the most difficult target?
What do you suggest instead???
Stop flogging the dead horse. Choose anything practical, and somewhat where
your investments NOW are not lost.
Rugxulo
2010-01-04 19:41:38 UTC
Permalink
Hi,
Post by Marco van de Voort
Post by Rugxulo
286s (which isn't really that bad a thing). So MS and IBM parted ways.
If you think DOS was doomed, you forgot that Win3.x ran atop DOS (even
DR-DOS), and even Win9x ran atop MS-DOS 7.
Which meant absolutely nothing from most users perspective.
Sure it does, esp. (and only) if you want to run DOS programs! And
that's considered a valuable feature except by very young kids and old
snobs.
Post by Marco van de Voort
And yes, DPMI was originally created to make >640kb use over a range of OSes
possible. But mostly for their dos compatibility modes.
Thank 386's V86 mode for that. That was a big improvement over the
286. Too bad AMD64 pretty much makes the same mistake.
Post by Marco van de Voort
Post by Rugxulo
Post by Marco van de Voort
Even after one year win95, already the bulk of the users didn't know dos.
I disagree. The main cliche to mention here would be Quake (late 1996)
Quickly followed by quake '95. That says enough.
Only because Carmack didn't think Quake 2 for DOS was worth it *to him
personally*, esp. for networking and gfx drivers (esp. hardware
acceleration). It could've been done, though.

Hexen2 is based upon Quake 1 but oddly enough never had a DOS (or
Linux or *BSD) port. But the engine was open sourced, so some guys
have "ported it back" to DJGPP etc: Hammer of Thyrion. Except for no
music (yet), it works well !
Post by Marco van de Voort
Post by Rugxulo
FreeDOS could legitimately be extended in similar fashion too. "Oh,
but then it wouldn't be DOS."
The point is nobody cared.
Obviously somebody cared or we wouldn't have WINE, DOSBox, FreeDOS,
DOSEMU, DJGPPv2, OpenWatcom, HX, etc.
Post by Marco van de Voort
Post by Rugxulo
And yet Linux 0.001 still counts as Linux?!? What about everything prior
to 2.2? 2.4? x86-64? Is it still Linux?? Apparently so.
You got a point there. It also has been one of the weaknesses of Linux, the
absense of long runnable binaries.
It doesn't have to be that way, though.
Post by Marco van de Voort
Post by Rugxulo
MS either won't or (more likely) can't fix NTVDM. RHIDE no longer
works (whereas it worked fine for ten years or so). So now the only
option in your eyes is to drop DOS, DJGPP, etc. and move exclusively
to Win32?
Stronger. I think that should have been done in 2000-2005 somewhere.
Why, what happened then? The main "problems" were the fact that you
couldn't natively resize the blasted NTFS "hog the whole drive" on XP
systems as well as NTVDM bugs (whereas it worked fine before). That's
not a good reason to drop DOS support, that's just the easiest and
laziest option. So all that means is people are lazy.

Everybody accepted XP, and it was successful. Too bad Vista broke some
stuff and was slower and heavier. Now XP is almost obsolete, but good
luck telling people to drop that. In other words, when people find
something that works, they stick to it. In other words, if even XP is
obsoleted, what good is any software?
Post by Marco van de Voort
IOW I think it is too late now, after the large gap. Even if sb really
invests a lot of time, most of the users that one could have kept
(educatioal, or only for the fun of it) moved one.
People move on all the time, it's their short attention span. Doesn't
reflect on any technical merit. PAE would probably be better utilized
these days (better compatibility) than 64-bit, but MS doesn't allow
that "due to driver bugs".
Post by Marco van de Voort
Post by Rugxulo
Post by Marco van de Voort
True. But why does it have to be on the most difficult target?
What do you suggest instead???
Stop flogging the dead horse. Choose anything practical, and somewhat where
your investments NOW are not lost.
I expected you to say FreeBSD 64-bit here. Instead you chose a very
vague and pessimistic statement. Sorry, but these days all investments
in software are almost a total loss when people don't legitimately
work towards keeping things compatible, esp. when a lot of it is more
arrogance or sloppiness instead of true technical deficiencies. (And I
am not implying MS here.)
Dan McGrath
2010-01-05 19:47:14 UTC
Permalink
Post by Rugxulo
use other stuff (XMS, VCPI). Mixing v1 and v2 apps is rare since most
got updated or are redundant. (FYI, the Desqview/X toolkit used DJGPP
There is no such word as "rare".

- Dan
--
Daniel G. McGrath
Binghamton, New York
e-mail: dmcg6174[AT]gmail[DOT]com
Robert Riebisch
2009-12-30 14:16:27 UTC
Permalink
Post by Ruud
I have a weird problem: when working with BP 7.0 in a DOS box in
Windows XP on my laptop (Dell Latitude D510), I sometimes have to wait
seconds before what ever I type appears on my screen. This includes
cursor movements. I don't experience any od these problems on any of
other (slower) computers/laptops. Any idea?
Are you talking about the BP IDE?
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
hartnegg
2009-12-31 12:48:12 UTC
Permalink
Post by Ruud
when working with BP 7.0 in a DOS box in
Windows XP on my laptop (Dell Latitude D510), I sometimes have to wait
seconds before what ever I type appears on my screen. This includes
cursor movements.
Try in cmd.exe instead of command.com
Reactions to keyboard input are much quicker there.
Also try loading dosidle in that dos window.

regards,
Klaus
Loading...