DOS ain't dead

I received Visual Studio 1.52 from an Ebay order a
couple of days ago. I also got Visual Studio 1.0 on
3.5" floppy disks.

Anyway, here is an executable from 1.52:

D:\scratch\zzz>hexdump \msvc15\bin\cl.exe | more
000000 4D5A8000 33000E00 08004102 FFFF6106 MZ..3.....A...a.
000010 00200000 18212000 40000000 00000000 . ...! .@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80660000 .............f..
000040 3C000000 40000000 44000000 48000000 <...@...D...H...
000050 4C000000 0400ED04 ED0D2000 6A0DED04 L......... .j...
000060 6E0DED04 18000506 26212000 FF212000 n.......&! ..! .
000070 0000E804 E30DED04 00000000 00000000 ................
000080 436F7079 72696768 74202843 29203139 Copyright (C) 19
000090 38362D31 39393120 50686172 204C6170 86-1991 Phar Lap
0000A0 20536F66 74776172 652C2049 6E632E00 Software, Inc..
0000B0 00004335 53325332 504D0000 0000DC4F ..C5S2S2PM.....O
0000C0 0000DE51 0000EA51 0000F651 00007652 ...Q...Q...Q..vR
0000D0 00000000 00000000 00000000 00000000 ................
0000E0 00000000 00000000 00000000 00000000 ................
0000F0 00000000 00000000 00001C2E 4101DC7C ............A..|
000100 A8B55860 D138D2BC 161CA36C 348395DD ..X`.8.....l4...
000110 0778A1B9 AC4705EE 7D7D3BA7 18E40150 .x...G..}};....P
000120 598A5396 5ABA6B64 7901C7E6 512A2288 Y.S.Z.kdy...Q*".
000130 BE4079F7 DC92061D 08A94728 DD53F784 .@y.......G(.S..


I was surprised to find that this ran under Windows 10.

I thought that Windows 10 had no 16-bit support and
only ran PE executables. But I don't see any PE
signature.

According to this:

https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#16-bit_versions

Visual C++ 1.0 came with Phar Lap 286.

No mention of whether 1.52 switched to Phar Lap 386.

Also it is unclear to me whether my CDROM is 1.52
or 1.52c. I don't know how to tell the difference.


Also, it has huge memory model support:

D:\scratch\zzz>type foo.c
char *foo(char *x, long y)
{
return (x + y);
}

D:\scratch\zzz>cl /AH /Fa /c /Gs foo.c
Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

foo.c

D:\scratch\zzz>type foo.asm
; File foo.c
; Line 2
; x = 0006
; y = 000a
_foo:
push bp
mov bp,sp
sub sp,OFFSET L00106
push si
push di
; Line 3
mov ax,WORD PTR 10[bp]
mov dx,WORD PTR 12[bp]
mov cx,WORD PTR 6[bp]
mov bx,WORD PTR 8[bp]
add ax,cx
adc dx,OFFSET 0
mov cx,OFFSET __AHSHIFT
shl dx,cx
add dx,bx
jmp L00105
; Line 4
; Line 4
L00105:
pop di
pop si
mov sp,bp
pop bp
ret OFFSET 0

D:\scratch\zzz>


Microsoft C++ 5.1 which I also recently received on floppy
disks has huge pointer support, but not huge memory model.

ie I have to use the "huge" keyword everywhere.

So this is good.

But unfortunately the method of doing huge pointers
effectively hardcodes a 4-bit shift into executables.

Unlike Watcom, that simply calls an external routine
and you are free to put in a more complicated pointer
manipulation algorithm suitable for an appropriate
PM16 OS.

Also, I don't know how to assemble that assembler.

D:\scratch\zzz>ml foo.asm
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000. All rights reserved.

Assembling: foo.asm
foo.asm(5) : error A2034: must be in segment block
foo.asm(6) : error A2034: must be in segment block
foo.asm(7) : error A2034: must be in segment block
foo.asm(8) : error A2034: must be in segment block
foo.asm(9) : error A2034: must be in segment block
foo.asm(10) : error A2034: must be in segment block
foo.asm(12) : error A2034: must be in segment block
foo.asm(13) : error A2034: must be in segment block
foo.asm(14) : error A2034: must be in segment block
foo.asm(15) : error A2034: must be in segment block
foo.asm(16) : error A2034: must be in segment block
foo.asm(17) : error A2034: must be in segment block
foo.asm(18) : error A2034: must be in segment block
foo.asm(19) : error A2034: must be in segment block
foo.asm(20) : error A2034: must be in segment block
foo.asm(21) : error A2034: must be in segment block
foo.asm(24) : error A2034: must be in segment block
foo.asm(25) : error A2034: must be in segment block
foo.asm(26) : error A2034: must be in segment block
foo.asm(27) : error A2034: must be in segment block
foo.asm(28) : error A2034: must be in segment block
foo.asm(29) : error A2034: must be in segment block
foo.asm(29) : error A2088: END directive required at end of file

D:\scratch\zzz>

Any idea what I've scored?

My hope was that I could use this to build the
io.sys (16/32-bit) of PDOS/386, and the entire
PDOS/86. I was surprised that masm doesn't
appear to come with Visual Studio 1.52.
Although checking the physical CD I don't see
any mention of "professional", so maybe that
is why.

Thanks. Paul.


> D:\scratch\zzz>hexdump \msvc15\bin\cl.exe | more
> 000000  4D5A8000 33000E00 08004102 FFFF6106  MZ..3.....A...a.
> 000010  00200000 18212000 40000000 00000000  . ...! .@.......
> 000020  00000000 00000000 00000000 00000000  ................
> 000030  00000000 00000000 00000000 80660000  .............f..

The PE signature is at 0x6680.

> I thought that Windows 10 had no 16-bit support and
> only ran PE executables.

Win 10 (32-bit) used to have NTVDM. But Win 11 is x64 (or ARM64) only.

> Also it is unclear to me whether my CDROM is 1.52
> or 1.52c. I don't know how to tell the difference.

Dunno, check "_MSC_VER" and/or file dates and times.

> Also, I don't know how to assemble that assembler.
>
> D:\scratch\zzz>ml foo.asm
> Microsoft (R) Macro Assembler Version 6.15.8803
> Copyright (C) Microsoft Corp 1981-2000. All rights reserved.

Try "/Zm".

> I was surprised that masm doesn't
> appear to come with Visual Studio 1.52.
> Although checking the physical CD I don't see
> any mention of "professional", so maybe that
> is why.

You can always use Japheth's JWasm.

> > Also, I don't know how to assemble that assembler.
> >
> > D:\scratch\zzz>ml foo.asm
> > Microsoft (R) Macro Assembler Version 6.15.8803
> > Copyright (C) Microsoft Corp 1981-2000. All rights reserved.
>
> Try "/Zm".

D:\scratch\zzz>ml /Zm foo.asm
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000. All rights reserved.

Assembling: foo.asm
foo.asm(5) : error A2034: must be in segment block
foo.asm(6) : error A2034: must be in segment block
foo.asm(7) : error A2034: must be in segment block
foo.asm(8) : error A2034: must be in segment block
foo.asm(9) : error A2034: must be in segment block
foo.asm(10) : error A2034: must be in segment block
foo.asm(12) : error A2034: must be in segment block
foo.asm(13) : error A2034: must be in segment block
foo.asm(14) : error A2034: must be in segment block
foo.asm(15) : error A2034: must be in segment block
foo.asm(16) : error A2034: must be in segment block
foo.asm(17) : error A2034: must be in segment block
foo.asm(18) : error A2034: must be in segment block
foo.asm(19) : error A2034: must be in segment block
foo.asm(20) : error A2034: must be in segment block
foo.asm(21) : error A2034: must be in segment block
foo.asm(24) : error A2034: must be in segment block
foo.asm(25) : error A2034: must be in segment block
foo.asm(26) : error A2034: must be in segment block
foo.asm(27) : error A2034: must be in segment block
foo.asm(28) : error A2034: must be in segment block
foo.asm(29) : error A2034: must be in segment block
foo.asm(29) : error A2088: END directive required at end of file

D:\scratch\zzz>

>
> > D:\scratch\zzz>hexdump \msvc15\bin\cl.exe | more
> > 000000  4D5A8000 33000E00 08004102 FFFF6106  MZ..3.....A...a.
> > 000010  00200000 18212000 40000000 00000000  . ...! .@.......
> > 000020  00000000 00000000 00000000 00000000  ................
> > 000030  00000000 00000000 00000000 80660000  .............f..
>
> The PE signature is at 0x6680.

Wow, thanks.

D:\scratch\zzz>hexdump \msvc15\bin\cl.exe 0x6670 50
006670 00000000 00000000 00000000 00000000 ................
006680 50450000 4C010700 13DBB32C 00000000 PE..L......,....
006690 00000000 E0008E81 0B010217 00A40000 ................
0066A0 0058 .X

> Visual C++ 1.0 came with Phar Lap 286.

It's just a "pharlap lite" version, limited to 2 MB, IIRC - hardly useful for anything.

> No mention of whether 1.52 switched to Phar Lap 386.

No.

> But unfortunately the method of doing huge pointers
> effectively hardcodes a 4-bit shift into executables.

VC 1.52 uses "external" constants _AHINCR and _AHSHIFT, that work for both real-mode and protected-mode ( assuming that the protected-mode OS uses "selector tiling" for blocks > 64 kB ).

> Also, I don't know how to assemble that assembler.

The -Fa option generates assembly code, but without "red tape" cmds, so the generated code has to be adjusted before feeding the assembler with it.

---
MS-DOS forever!

> > But unfortunately the method of doing huge pointers
> > effectively hardcodes a 4-bit shift into executables.
>
> VC 1.52 uses "external" constants _AHINCR and _AHSHIFT, that work for both
> real-mode and protected-mode ( assuming that the protected-mode OS uses
> "selector tiling" for blocks > 64 kB ).

Thanks for that information. I was surprised to
see that it works in protected mode.

The generated code I showed above didn't use AHINCR
and didn't look like it would work in PM16.

A search found this somewhat unrelated:

http://www.delphigroups.info/2/ae/107069.html

{ AHincr is 8 in Standard and Enhanced mode, $1000 in real mode.
AHshift is 3 in Standard and Enhanced mode, 12 in real mode (2^AHshift=AHincr) }


It will take some time for me to wrap my head around
this to find out whether I can get huge memory model
DOS executables compiled with Visual Studio 1.52, but
linked with a (modified) PDPCLIB to run under a future
PDOS/286 with selectors appropriately lined up.

And hopefully on PM16 on a 386 those executables would
be able to access much more than 16 MiB of memory.

BFN. Paul.

In the full pharlap, they have their own assembler

I suspect you'd need that.

> > Also, I don't know how to assemble that assembler.
>
> The -Fa option generates assembly code, but without "red tape" cmds, so the
> generated code has to be adjusted before feeding the assembler with it.

Switching on optimization, e.g. just -O will do,
produces assembler that can be given directly
to masm.

> Microsoft C++ 5.1 which I also recently received on floppy
> disks has huge pointer support, but not huge memory model.
>
> ie I have to use the "huge" keyword everywhere.

I don't remember what compiler options I was using
when doing that previous test - or maybe I was
drunk as a skunk - but I repeated the test as part
of my vlog on pdos.org (I bought a Book 8088 with
an NEC V20 (so I can do 8080 (8-bit) with some effort)
running msdos 6.22) and was shocked to see an
unexpected result - huge memory model works!!!

I have repeated the test under Win95, but I was not
able to redirect the stderr, so can't capture the
version number (5.1) and Bochs wouldn't do a
character screenshot either, so you'll have to trust
me that I didn't manage to stuff up the number 5.1.
Anyway - it works!

Here's the rest of what I ran:

D:\scratch\xxx>type doit.bat
del foo.asm >>output.txt
type foo.c >>output.txt
type foo.asm >>output.txt
cl /c /AH /Fa /Gs foo.c >>output.txt
type foo.asm >>output.txt

char *foo(char *a)
{
return (a + 5);
}
foo.c
; Static Name Aliases
;
TITLE foo.c
NAME foo

.8087
FOO_TEXT SEGMENT WORD PUBLIC 'CODE'
FOO_TEXT ENDS
_DATA SEGMENT WORD PUBLIC 'DATA'
_DATA ENDS
CONST SEGMENT WORD PUBLIC 'CONST'
CONST ENDS
_BSS SEGMENT WORD PUBLIC 'BSS'
_BSS ENDS
DGROUP GROUP CONST, _BSS, _DATA
ASSUME CS: FOO_TEXT, DS: DGROUP, SS: DGROUP
EXTRN __acrtused:ABS
EXTRN __AHSHIFT:FAR
FOO_TEXT SEGMENT
ASSUME CS: FOO_TEXT
; Line 2
PUBLIC _foo
_foo PROC FAR
push bp
mov bp,sp
; a = 6
; Line 3
mov ax,5
cwd
add ax,WORD PTR [bp+6] ;a
adc dx,0
mov cx,OFFSET __AHSHIFT
shl dx,cl
add dx,WORD PTR [bp+8]
pop bp
ret
nop

_foo ENDP
FOO_TEXT ENDS
END


Doing cl /help shows:

C COMPILER OPTIONS

-MEMORY MODEL-
/AS small model (default) /AC compact model
/AM medium model /AL large model
/AH huge model
-OPTIMIZATION-
/O enable optimization (same as /Ot) /Oa ignore aliasing
/Od disable optimizations /Oi enable intrinsic functions
/Ol enable loop optimizations /On disable "unsafe" optimizations
/Op enable precision optimizations /Or disable in_line return
/Os optimize for space /Ot optimize for speed (default)
/Ox max. optimization (/Oailt /Gs)
-CODE GENERATION-
/G0 8086 instructions (default) /G1 186 instructions
/G2 286 instructions /Gm put strings in constant segment
/Gc Pascal style function calls /Gs no stack checking
/Gt[number] data size threshold
-OUTPUT FILES-
/Fa[assembly listing file] /Fb[bound executable file]
/Fc[mixed source/object listing file] /Fe<executable file>
/Fl[object listing file] /Fm[map file]
/Fo<object file> /Fs[source listing file]
(press <return> to continue)
-PREPROCESSOR-
/C don't strip comments /D<name>[=text] define macro
/E preprocess to stdout /EP same as /E but no #line
/I<name> add #include path /P preprocess to file
/U<name> remove predefined macro /u remove all predefined macros
/X ignore "standard places"
-LANGUAGE-
/Za disable extensions /Zd line number information
/Ze enable extensions (default) /Zg generate declarations
/Zi symbolic debugging information /Zl remove default library info
/Zp[n] pack structs on n-byte boundary /Zs syntax check only
-FLOATING POINT-
/FPa calls with altmath /FPc calls with emulator
/FPc87 calls with 8087 library /FPi inline with emulator (default)
/FPi87 inline with 8087
-SOURCE LISTING-
/Sl<columns> set line width /Sp<lines> set page length
/St<string> set title string /Ss<string> set subtitle string
-MISCELLANEOUS-
/c compile only, no link /H<number> external name length
/J default char type is unsigned /Tc<file> compile file without .c
/V<string> set version string /W<number> warning level
(press <return> to continue)
-LINKING-
/F<hex_number> stack size (hex. bytes) /Lc link compatibility mode executable
/Lr link compatibility mode executable /Lp link protect mode executable
/link [linker_options_and_libraries]


but the version number must have gone to stderr
there too.

BFN. Paul.

> I have repeated the test under Win95, but I was not
> able to redirect the stderr, so can't capture the
> version number (5.1) and Bochs wouldn't do a
> character screenshot either

4DOS (freeware) or DJGPP djdev205.zip redir.exe should be able to redirect stderr on Win95 for you. There are other tools for that, too, like Raymond Moon's STDERRF.

I recall that Rod Pemberton converted a small TSR to NASM that redirected all stderr to stdout. Look at John Santic's website for the original or comp.os.msdos.programmer for the NASM version.

I still use my own tiny assembly screendump ("scrndump") util, but it's very wimpy. You should be able to figure out how to dump B800:0000 to file pretty easily. There's also Loren Blaney (XPL0)'s SNARF for graphical screenshot.

FYI, an online Norton Guide for MS C 5.1 is here.