DOS ain't dead

kerravon

Sydney, Free World South,
06.04.2025, 21:30

CM16 (Developers)

Is anyone familiar with CM16 in x64 long mode?

Again - with the loose definition of "MSDOS" - ie C wrappers on the interrupts - I can avoid doing an actual interrupt in my "MSDOS apps". I use PosOpenFile etc. Or replace Microsoft's open() with a PosOpenFile.

And PosOpenFile can do a callback instead of an interrupt. It could even do the INT 21H interrupt if it detects that this is an 8086 running genuine MSDOS.

And I'm primarily interested in getting huge mode apps to work.

I have two existing threads where I have asked about what is required:

https://forum.osdev.org/viewtopic.php?t=57706

https://forum.vcfed.org/index.php?threads/80386-d-bit.1244659/

But people here may have more insights.

Note that I'm not familiar with long mode myself, but I have been given code to transition to CM32:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/shimcm32.asm

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/bios.c

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/makebios.shm

Thanks. Paul.

Japheth

Germany (South),
07.04.2025, 15:48

@ kerravon

CM16

Post reply

> Is anyone familiar with CM16 in x64 long mode?

if with CM16 you mean "16-bit protected-mode" in Compatibility Mode, then yes.
The Dos64-Stub program frequently switches between this mode and 64-bit long mode.

---
MS-DOS forever!

kerravon

Sydney, Free World South,
09.04.2025, 10:05

@ Japheth

CM16

Post reply

> > Is anyone familiar with CM16 in x64 long mode?
>
> if with CM16 you mean "16-bit protected-mode" in Compatibility Mode, then
> yes.
> The
> Dos64-Stub
> program frequently switches between this mode and 64-bit long mode.

Thanks. I had some misunderstandings about both PM16
and CM16 but both have now been cleared up (ie CM16
isn't really a thing).

So yes, I do in fact just mean "compatibility mode"
and I "just" need to set all the selectors to 16-bit
and I should be able to run certain 16-bit programs.

I will likely do OS/2 1.0 programs first as NE
executables.

Then I can probably look at NE executables that run
under both Euro MSDOS 4.0 (which is now freely
available from Microsoft but I can't remember if I
got it to work) and PDOS/86 (x64 CM version).

I am mainly interested in huge memory model, so
one way or another I need to modify the MZ format
to include AHINCR/AHSHIFT adjustments in order to
support Microsoft-compiled executables. So I may
abandon standard MSDOS.

It might be good if Freedos could support NE
format though.

BFN. Paul.

kerravon Sydney, Free World South, 27.04.2025, 17:24 @ kerravon	CM16 Post reply
	I got it to work, as a demo. http://pdos.org/newdos.zip And this is executing a large memory model MZ executable. Not NE. That works on standard MSDOS 2.0 etc. I haven't implemented relocations properly yet, so it only works for some things. I just wanted some feedback that it worked at all.

kerravon

Sydney, Free World South,
27.04.2025, 18:36

@ kerravon

CM16

Post reply

> I haven't implemented relocations properly yet, so it only works for some
> things. I just wanted some feedback that it worked at all.

Apologies for the ambiguous English.

I wanted feedback from the software that reality matched theory - so I bypassed work/kludged things to get to the end goal.

I don't need anyone to run a test to prove (ie provide feedback) that it works - I've already done that myself.

Feedback from humans is fine too though!

kerravon

Sydney, Free World South,
27.04.2025, 19:57

@ kerravon

CM16

Post reply

Also note that:

1978 - 8086 released
1981 - IBM PC XT shipped
1982 - 80286 shipped
1983 - MSDOS 2.0 released

this is a computer science question - how to deal with segmented addresses - and some university professor could have theoretically sat down circa 1982 and said "oh - we have multiple meanings of a segment/selector - better sort out an executable format and/or programming technique for portability/future-proofing your executables".

Microsoft didn't force the issue until:

1987 - Microsoft C 5.0 with huge memory model support released

at which point some rearguard action could have been done (which is what I am trying to do now - almost 40 years later).

kerravon

Sydney, Free World South,
27.04.2025, 20:15

@ kerravon

CM16

Post reply

There are other things I need now too.

Like an extended MSDOS API function to call to allocate memory where I can specify two things:

1. I'm willing to receive a block of memory that isn't aligned on a segment (ie I will be given an offset too), so long as the block of memory is completely addressable by the segment/selector that I was given. Large and compact apps could request this.

2. As above, but one step further - happy for the memory to span a segment/selector boundary. Huge memory model could request this.

This would give the OS more flexibility in providing memory to apps.

If the C runtime library gets a CF/whatever to say that the extended API doesn't exist, then it falls back to the standard memory allocation routines (ie provided even in MSDOS 2.0) and will get an implied offset of 0.

kerravon

Sydney, Free World South,
28.04.2025, 15:40

@ kerravon

CM16

Post reply

I was thinking about RM16.

Is it possible to bank out everything - the BIOS ROM etc - to get access to the underlying memory?

Because I can run with interrupts disabled, and the OS in low memory, so that when I'm ready for screen output I bank the video back in, and the BIOS back in, and call it.

If I set AHINCR to 0FFF and only run huge memory model programs (and export the OS C library too so that not every app needs to provide that), I could have memory tiled similar to how CM16 is working, but with segments like this:

0000
0FFF
1FFE
2FFD
3FFC
4FFB
5FFA
6FF9
7FF8
8FF7
9FF6
AFF5
BFF4
CFF3
DFF2
EFF1
FFF0

and that way I could access almost all of the memory, including the upper 64k, without having to write non-portable code for the memory management.

Otherwise I would need exception code and exception apps for that top 64k.

Although that won't help with AHSHIFT code. But I can use Watcom instead so that I am not constrained by these things.