DOS ain't dead

I'm pretty sure that Microsoft C for MSDOS was called cl.exe, the same as Visual Studio today.

At the time that kernel32.dll was created, presumably circa 1994, did cl.exe target both Win32 and MSDOS, or were they separate compilers?

If the former, was a switch used? If a switch was used, what was the default, and is that switch still accepted today (2021)?

Asking for a friend.

Thanks. Paul.

> I'm pretty sure that Microsoft C for MSDOS was called cl.exe, the same as
> Visual Studio today.
>
> At the time that kernel32.dll was created, presumably circa 1994, did
> cl.exe target both Win32 and MSDOS, or were they separate compilers?
>
> If the former, was a switch used? If a switch was used, what was the
> default, and is that switch still accepted today (2021)?

Don't know, but ....

MS C 5.1 switches
MS C 6.0 switches
http://bytepointer.com/msvc/index.htm

Oh, also OpenWatcom has a "cl" wrapper .EXE to emulate the switches of the MS util. (Similarly, they have "owcc" for POSIX cc.)

> I'm pretty sure that Microsoft C for MSDOS was called cl.exe, the same as
> Visual Studio today.
>
> At the time that kernel32.dll was created, presumably circa 1994, did
> cl.exe target both Win32 and MSDOS, or were they separate compilers?

I've never seen a combined 16/32-bit C compiler from Microsoft. I think they were always separate. But the command line switches that were transferable from one memory model to the other were mostly the same. The earliest 32-bit one that I could find easily is Visual C++ 1.0 for NT from winworldpc.

> http://bytepointer.com/msvc/index.htm

Thanks. This has what I want, I think.

I think I want Visual C++ 1.5 Professional - 16-bit
which seems to have cl.exe as an MSDOS executable -
last version. This will give me the most sophisticated
compiler able to run on MSDOS.

And then I want Visual C++ 1.52c (16-bit) where
cl.exe is a PE32 executable, but producing
16-bit MSDOS executables. This should give
essentially unlimited opportunity for code
optimization when building MSDOS applications.

Does this look correct?

Am I able to buy these things from Microsoft or
will they refuse to sell them to me at any price?

Thanks. Paul.

> Does this look correct?
yes.


> Am I able to buy these things from Microsoft or
> will they refuse to sell them to me at any price?

just go to microsoft product pages and see what you can buy.
MSVC 1.52 most likely will not be available at any price.

however, try this new GOOGLE thing. it might be available for download at many places

> I think I want Visual C++ 1.5 Professional - 16-bit
> which seems to have cl.exe as an MSDOS executable -
> last version. This will give me the most sophisticated
> compiler able to run on MSDOS.
>
> Does this look correct?

1.52c works on DOS as well.

> Am I able to buy these things from Microsoft or
> will they refuse to sell them to me at any price?

winworldpc devtool library!

> > I think I want Visual C++ 1.5 Professional - 16-bit
> > which seems to have cl.exe as an MSDOS executable -
> > last version. This will give me the most sophisticated
> > compiler able to run on MSDOS.
> >
> > Does this look correct?
>
> 1.52c works on DOS as well.

http://bytepointer.com/msvc/index.htm

Visual C++ 1.51 - 16-bit

CL.EXE was a 32-bit PE applicaion


Are you saying that by 1.52C they had reverted
CL.EXE back to being a 16-bit MSDOS application?

Or did they ship two versions of CL.EXE?

Thanks. Paul.

Why not just use OpenWatcom instead?

"Visual C++ 4.x bundled this 16-bit version. [Visual C++ 1.52x (16-bit)]"

eBay listings

[I have an unacceptable word, but don't know what
it is, so this post is being split]

> Why not just use OpenWatcom instead?

OpenWatcom comes with a huge license that may or
may not allow commercial use, depending on who
hires the most lawyers and the whim of some
judge and/or jury who probably spend most of
the trial playing "snake" on their mobile phones.

Microsoft's products are well-known to be designed
for commercial use, and the license, although I
probably won't understand it, probably doesn't
make veiled attempts at extorting source code.

I am in a position to replace Microsoft's C runtime
library with my own (PDPCLIB), so I can distribute
executables that nobody can make claims against.

Since I am an OS vendor (PDOS/386) and I wish to
support 3 decades worth of computer manufacture
worldwide, rather than attempting to render them ...

... obsolete as Microsoft does in order to get m*ney ...

... which means my OS ecosystem starts in real mode,
which means I need to be able to produce real mode
executables.

I don't have any good options to produce real mode
executables, because everything except subc is
copyrighted. I'm thinking of paying someone to
update subc to produce huge memory model executables
which is what I am really after for a clean design.
Smaller C produces huge memory model executables
but uses 80386 instructions, which is fine for
PDOS/386 so I will probably go with this.

PDOS/86 would require 8086 instructions in case I
encounter any 8086 computer. Turbo C++'s huge
memory model is broken so I can't use that. I've
run out of rope on that one, but Visual C++ will
likely save the day there.

> "Visual C++ 4.x bundled this 16-bit version. [Visual C++ 1.52x (16-bit)]"
> (Ebay link)

Thanks a lot for that pointer! I now have a
combined birthday and father's day present
on the way. Let's see what I can do with it!

BFN. Paul.


[so it was m*ney/mon*y that wasn't allowed]

[one paragraph wasn't written properly because
it contained two references to m*oney which
confused me, so here is the replacement
paragraph]

Since I am an OS vendor (PDOS/386) and I wish to
support 3 decades worth of computer manufacture
worldwide, rather than attempting to render them
obsolete as Microsoft does in order to get m*oney
from new computer sales (since they don't make
m*oney from free upgrades), I wish to use the BIOS,
which means my OS ecosystem starts in real mode,
which means I need to be able to produce real mode
executables.

> > 1.52c works on DOS as well.
>
> http://bytepointer.com/msvc/index.htm
>
> Visual C++ 1.51 - 16-bit
>
> CL.EXE was a 32-bit PE applicaion
>
>
> Are you saying that by 1.52C they had reverted
> CL.EXE back to being a 16-bit MSDOS application?
>
> Or did they ship two versions of CL.EXE?

No, it came with a DOS extender that could run it (Phar Lap GOTNT).

> > > 1.52c works on DOS as well.
> >
> > http://bytepointer.com/msvc/index.htm
> >
> > Visual C++ 1.51 - 16-bit
> >
> > CL.EXE was a 32-bit PE applicaion
> >
> >
> > Are you saying that by 1.52C they had reverted
> > CL.EXE back to being a 16-bit MSDOS application?
> >
> > Or did they ship two versions of CL.EXE?
>
> No, it came with a DOS extender that could run it (Phar Lap GOTNT).

Ok, thanks. That's no good to me. I can run HX
as the DOS extender and run the Win32 executable.

I'm after the last version that ran on a pure
8086 CPU. What sort of trade-offs were made
trying to get CL.EXE to run on an 8086? Maybe
I actually want an earlier version of CL.EXE
before they started adding a whole lot of
features, so that I can compile bigger programs.

I only need their compiler, not their runtime
libraries.

BFN. Paul.

> Since I am an OS vendor (PDOS/386)

If you not need platform-independent code, try Sphinx C--.
This is in middle between C and Assembler.

Imho, high-level programming languages is not best choice for real-mode system programming. Imho, one of example for this bad choice is freecom. Microsoft never do good optimized software, but freecom eat more memory then command.com.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> Since I am an OS vendor (PDOS/386)

just wondering: in my limited knowledge of English 'vendor' implies selling, and implies m*oney changing hands.

how do you plan to sell a public domain operating system? Doesn't 'public domain' imply 'free to use in whatever fashion'?

> > Since I am an OS vendor (PDOS/386)
>
> just wondering: in my limited knowledge of English 'vendor' implies
> selling, and implies m*oney changing hands.

Yes, that is correct. M*oney normally changes
hands. But unless you want to create a new
word in the English language that means
vending-without-m*oney-changing-hands-sometimes-maybe,
then I'll just stick to "vendor".

> how do you plan to sell a public domain operating system?

The Sqlite vendor manages to receive m*oney from
people who are paranoid about getting a free lunch.

I bought a huge piano for $10 once for the same
reason. The seller was happy to give it away, but
I wanted to see m*oney involved.

> Doesn't
> 'public domain' imply 'free to use in whatever fashion'?

Yep, you can do whatever you want with it.
It's as free as air/the sun.

BFN. Paul.

> > Since I am an OS vendor (PDOS/386)
>
> If you not need platform-independent code, try Sphinx C--.
> This is in middle between C and Assembler.
>
> Imho, high-level programming languages is not best choice for real-mode
> system programming. Imho, one of example for this bad choice is freecom.
> Microsoft never do good optimized software, but freecom eat more memory
> then command.com.

I am happy to use other languages, including
Pascal, Fortran etc, but first I would like to
have a complete solution that only relies on
C90-compliant code plus MASM-compatible assembler.

BFN. Paul.

> > "Visual C++ 4.x bundled this 16-bit version. [Visual C++ 1.52x
> (16-bit)]"
> > (Ebay link)
>
> Thanks a lot for that pointer! I now have a
> combined birthday and father's day present
> on the way. Let's see what I can do with it!

This CDROM has arrived and today I tried it.

The default installation only installed the
Win32 version of cl.exe, so I can't produce
huge memory model programs.

In addition, I carefully read the license
agreement for the version of ml.exe (MASM)
that I normally use, and it requires me to
have Visual Studio 6.0 with SP5 installed
before I'm allowed to use that, so I didn't
install that either.

So I don't even have 32-bit MASM available on
my new computer yet. Not sure what assembler
people were supposed to use back in the
Visual Studio 4.0 days.

I went looking for the separate 16-bit C compiler
so that I could see if Microsoft C produces decent
assembler for pointer manipulation, but the only
thing I could find is a complete installation of
Win32s which can only be done legally if you already
own Windows 16-bit, which I don't.

So I think I need to give up on Microsoft C and
stick with Watcom C until such time as I manage
to find someone willing to update SubC (which is
public domain) to have a huge memory model target.

Unless someone else has a better suggestion on how
to rationalize and secure PDOS?

Thanks. Paul.