VOGONS


Reply 20 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

I have some older systems but they're drydocked, no hard drives or os installed in them. The executables (compiled with pentium optimizations) do run in win 95 and are there: http://personal.inet.fi/muoti/eimuoti/tmp/w32_test.zip. The vc ones run as a silent background process for the 20 seconds, so you may need to pipe their console output to e.g. a file to be viewed. If there's an assertion failure, the read-only toggle may have been set for one or more of the files included and should be unset.

Reply 21 of 38, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie
vvbee wrote:

The executables (compiled with pentium optimizations) do run in win 95

While I bring up my Pentium MMX, I did give them a try on a 486. I expected none of them to run, but some did. Here are the results.

Machine: 486 DX2 / 66Mhz, 20Mb RAM, 256Kb cache - Windows 95

dmc - 307 frames
bc5 - 299 frames

gcc - N/A - missing MSVCRT.DLL
ow - N/A - crashed (in KERNEL32.DLL)
vc6 - N/A - no output, program exits relatively fast
vc7 - N/A - no output, program exits relatively fast

I'll post the P MMX results when I have them.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 22 of 38, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

And the P MMX results as promised:

Machine: Pentium MMX 266Mhz, 32Mb RAM - Windows 98

gcc - 3357
vc6 - 2812
dmc - 2654
bc5 - 2394
vc7 - 1732
ow - N/A - crash

Am I missing something about the Visual Studio executables? They behave the same on my both machines.

EDIT: Updated with Visual Studio numbers.

Last edited by vladstamate on 2018-02-14, 00:12. Edited 1 time in total.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 23 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

I'm guessing the vc compiler needs a toggle somewhere to make a true console program, and I didn't set that toggle. Those exes need to be run something like hw_vc6_p > t.txt, and after 20 seconds the complete output will be in t.txt.

I tested the files on a fairly fresh win 95 (c) installation earlier and they all ran (except ow), so I guess some program may already have deposited the required ms dll.

Even at this stage it seems a fair guess that in win32, gcc will be the fastest, generally followed by dmc although possibly by vc6 in some cases. Whether ow would have better optimization for the 486 in win32 than it does for the pentium is one question.

Reply 24 of 38, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

I've updated my Pentium post with VC numbers and it seems to support your opinion (although in my case VC6 beat DMC).

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 25 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

Cool. Looking at vc6 in relation to the nonoptimizing vc7, it may be that vc6 (or some of its optimizations) is more suited for the pentium than for the k6.

I updated the file with exes compiled with 486 optimizations (_4.exe) if you want to test those, http://personal.inet.fi/muoti/eimuoti/tmp/w32_test.zip. I also fixed the vc exes so that they output to console properly, and I got a working ow executable by manually setting the stack size on compile. Don't know why it wants that, but it seems happy now. I also bundled the msvcrt.dll that I've used with this version of gcc. Copyright (c) microsoft, of course.

Reply 26 of 38, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
vvbee wrote:

I'm guessing the vc compiler needs a toggle somewhere to make a true console program, and I didn't set that toggle.

I'm not entirely sure about vc6 and vc7, but at least on 2008 (aka vc9) and later this is controlled by a linker flag, so

cl file.c /link /subsystem:console
cl file.c /link /subsystem:windows

But "console" is the default, so it shouldn't be a problem if /subsystem:windows is not explicitly specified…

Reply 27 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

Yep, it was the same for those earlier versions, though what ultimately prevented it from working here was that a forgotten piece of code migrated from another project along with some other code was explicitly setting that option to a non-console version if compiled with vc. Not so useful here.

Reply 28 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

Some days ago I found that ow runs better in win32 with 486 than with pentium optimizations on post-pentium hardware, like 40% better. Still kinda mediocre performance but a clear issue as well. I think none of the other compilers did this, but I forget if I ran the benchmarks in just wine on my modern box. The results likely depend on type of hardware.

Reply 29 of 38, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

well, did you try OW with just 4gw or did you try wdosx or pmodew? dos4gw is really slow as far as extenders go. unless you used 16bit wcc/wcl/wpp instead of 32bit wcl386/wcc386/wpp386...

I used watcom 10+11 extensivly back in theday, it was heaps better than djgpp then, but obviously gcc has progressed a lot, and watcom stagnated for decades..

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 30 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

No extenders in the earlier dos tests, otherwise native win32 in these recent ones. I used the native linux port of wcl386.

Reply 31 of 38, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

For Windows 98 and Me (but not 95) there is yet another possibility: those systems support .NET Framework up to version 2.0, and even the newest Visual Studio can still generate .NET 2.0 (but not 1.x) executables. This allows one to write programs in C#, VB.NET and potentially other languages and run them on Win98 (Visual Studio 2017 itself requires Windows 7).

Reply 33 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

I benched some older c compilers and some newer ones for comparison. The older ones were pacific c 7.51, microsoft c 5.10, and turbo c 2.01. Newer ones were visual c++ 1.50, digital mars, and open watcom 1.9. All compiled a c program for dos, a software rasterizer spinning an object on screen. Running on a k6-2 300 mhz.

owc = 105 fps
vc = 102
dmc = 95
tc = 78
mc = 77
pc = 65

Reply 34 of 38, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Delphi 2, by accident, can also compile -more or less- Win32s compatible binaries w/ relocation tables.
Funnily, you can even include manifest files as used by Windows NT 6.0 onwards.

The result is a binary that is able to run on Windows 3.1 onwards, needs no runtimes and looks "GDI+ style"
(uses Windows Common Controls) on Vista and onwards. The only problem I've encountered so far, is the icon beeing missing.

If you want to give Delphi (Object Pascal) a try, I'd start with Delphi 2 first.
Later Versions can be got as book ware (Delphi for Kids included Delphi 3 Pro and Delphi 7 Personal).
They are also able to import their siblings' older project files.

There's also Turbo Delphi, which was released for hobbyists a few years ago.
And Lazarus, which can compile programs for Mac OS X, too.

Anway, I'm not sure if Delphi is still considered to be "alive".

Edit: Silly, me! 😅 Manifest resource files and Common Controls were used in NT 5.1 aka XP already.
Visually, they became more apparent beginning with NT6/Vista. Without them, programs look really dated there.

Azarien wrote:

For Windows 98 and Me (but not 95) there is yet another possibility: those systems support .NET Framework up to
version 2.0, and even the newest Visual Studio can still generate .NET 2.0 (but not 1.x) executables. This allows one to write programs
in C#, VB.NET and potentially other languages and run them on Win98 (Visual Studio 2017 itself requires Windows 7).

VB.NET 2005/2008 are able to translate Visual Basic Classic (VB6) programs to VB.NET syntax.

The runtime of the latter, msvbvm60.dll is included from Win98SE onwards, incl. Win X.
Technically, someone could write code in VB Classic and run that binary on anything from Win95 onwards.
Or even from Windows 3.0 onwards, if the VB project was created in VB1 first, then converted by VB4 32-Bit
and finally compiled by VB6.

I'm not sure whether or not I should recommend that, though.
Besides the classic C vs Basic debate, VB6 is much like XP.
It had been officially killed about a thousend times and still lives on.

Ironically, the new upcoming "Win10 on ARM" is said to include a Win32 emulator
with a 386-ish instructions set (maybe MMX, too).

Who knows how long it will really last. 😐

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 35 of 38, by vvbee

User metadata
Rank Oldbie
Rank
Oldbie

I benched the c compilers more. Same setup as last time but now running on my 3.3 ghz haswell xeon and a pentium 90 laptop, the siemens pcd-5nd. Both in plain dos.

xeon
ow = 364
vc = 318
dmc = 299
tc = 279
pc = 274
mc = 244

p/90
ow = 26
vc = 26
dmc = 24
mc = 22
tc = 19
pc = 17

The laptop is suspiciously slow but whatever, reported as running full speed anyway. I like the vibe of the pacific c compiler but it performs subpar, also slow to compile if I recall. The visual c++ 1.5 compiler is pretty good. I don't think it would be far from the vc 6's, possibly faster on some older cpus. Not that you have a choice for dos.

Reply 36 of 38, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
Jo22 wrote:

Anway, I'm not sure if Delphi is still considered to be "alive".

It is still alive, or at least it was last time I checked. But new versions don't even support targeting XP, at least officially.

Ironically, the new upcoming "Win10 on ARM" is said to include a Win32 emulator with a 386-ish instructions set (maybe MMX, too).

386 MMX? 😀 indeed, with emulator you can have a Frankenstein CPU with "interesting" subset of features..

Reply 38 of 38, by shamino

User metadata
Rank l33t
Rank
l33t

In DOS, I used to enjoy Borland C++ 3.0, although I never really did much "++", I prefer procedural C code.
I liked using Borland's IDE with it's syntax highlighting and built in help, but then I started to get interested in assembly. Borland 3.0 allows inline assembly, but the problem is it only recognizes and allows 16-bit code. If I'm doing assembly, I want to do 32-bit. So then I started using a 32-bit capable version of MASM and linking. I found that clunky, confusing, and much less enjoyable.

In a perfect world, I'd love a DOS compiler with a good IDE that supports inline 32-bit assembly, complete with MMX, K3D and KNI instructions. I don't care much if the C compiler utilizes those, but I want the freedom to use them myself in inline asm.
I think this can be done (maybe not 3DNow) with MS Visual C++ 6.0 under Windows, which I have, but if I ever got back into this stuff then I'd rather program DOS in DOS, not Windows.