DOS ain't dead

So, we had a brief discussion before about a.out format for MSDOS object code.

It was deemed to be impossible to use a.out because some information couldn't be represented in a.out, and OMF or whatever was required.

This was demonstrated to be incorrect - at least to a degree - when as86 and ld86 (from Robert Pengelley) were able to take disassembled code from wcl (Watcom C) and then reassemble it as a.out.


There were some restrictions. You couldn't use the "seg" keyword. Addresses needed to be complete. With no way to change the Watcom output, some changes to the C code needed to be done to force the "right" code to be generated.

I might look at a modification to Watcom to get around this one day.

Now I happened to be talking to the pdld author, and he told me that 16-bit a.out format was supported for both object code and resultant executable.

That got me wondering whether I could have a version of 16-bit PDOS (MSDOS mini-clone) to use a.out format instead of MZ. What would that even look like? What's the concept?

First thing I tried was to build it. There were a couple of unrelated issues, but finally it was crunch time.

It was missing support for DGROUP, so that I could do:

mov dx,DGROUP

And also I needed edata and end.

I was always under the impression that these were magical things that needed some MSDOS/8086-specific code to be added to make work.

But the pdld author came back with:

I do not know what DGROUP variables "DGROUP", "DGROUP__edata" and "DGROUP__end" are.


I was going to respond to that innocent question with an explanation of the segmentation model and how that needed specialized code.

But what threw me the most was the names of the unresolved references.

DGROUP__edata

That's an ordinary-looking label. I was expecting some complicated MSDOS-specific thing.

My assembler code had:

extrn _edata:byte

So I was wondering where such a long name came from.

It turns out that as86 has generated that for whatever reason.

Possibly in an effort to coordinate with ld86.

I was involved in that process, answering various questions and making suggestions, but I was not the author, so I never looked into the internals to properly know how it worked. It could have been a suggestion I made - possibly as an example of how to work around an immediate problem - I can't remember (although note that the entire history is in email - I don't have interactive chat nor voice chat nor in-person contact with the people I work with on this code). At the time, it was dubious whether a.out was a technical possibility, given the segmented nature of the 8086 and the fact that (the simple) a.out format was written for non-segmented environments.

And the pdld author also asked why not just create a dummy file with those variables defined?

I thought that was a naive suggestion, but in the process of thinking how to explain why that was impossible - I just needed the segment portion for DGROUP, it dawned on me - what would happen if I had an ordinary label called DGROUP - as silly as that sounds? I checked the map file, and pdld had created the ordinary .text, .data, .bss.

If I did arrange things so that an ordinary label called DGROUP was the first bit of data - what would happen? Ok, so an ordinary label would be accessed with what - lds/les?

And, that won't work because ... actually, it will work - if I do an les bx, I can simply ignore the bx that will always be 0 and that I never really wanted!

(I may have the instruction wrong - I have lea in my mind also)

And what about when I switch to PM16? Since I have a.out, not NE, what will happen?

Well - the relocations know where everything is already. When the loader loads that, it can put the data wherever it wants, ie appropriately aligned on a 64k boundary, and that will work too.

Ok, but without NE I won't be able to support DLLs - sure, but who needs DLLs? PDOS-generic passes an address that contains a structure full of callback functions, so just use them, and keep it simple. So simple that a.out can handle it.

And even the BSS that I am currently clearing in my MSDOS executables - I don't need to do that at all. Just get the OS to do that - regardless of RM16 or PM16. I'm already using a.out anyway, so ... why bother the application with that? If I did want the a.out to clear its own BSS, could it still be done? I think I can get a label guaranteed to be at the start of DGROUP/data. The end of DGROUP data is probably more difficult. The end of BSS is probably difficult too. So the jury is out on that still. But maybe the jury can remain out on that and I switch to supporting a.out format instead.

a.out support could potentially be added to MSDOS 4.0 too.

Any thoughts on what the situation is?