How to: create DLL file for Windows 10 64-Bit Pro

[marcov]

I don't believe, that I can programming real MS-DOS applications anymore.
Because - dosbox.exe can tweak the memory to over 16 MB.

That's for 32-bit dos extender apps (like FPC's go32v2).    16-bit dos is a different matter. Conventional memory is 640kb, but the CPU can address 1MB (+another area slightly smaller than 64k via the A20 line)

My last 386 16 MHz PC that could be drop down to 8 MHz by pressing the Turbo-Key had only 2 MB of RAM.
Could not be know, how Windows 3.1 was running on ... :-)

My 386SX 20MHZ with 2MB from 1991 came with msdos 5.0 and Windows 3.0. Windows 3.1 came only later  Note those could usually be expanded to 8MB (with 1 MB 30 pins simms)

[Mr.Madguy]

That's for 32-bit dos extender apps (like FPC's go32v2).    16-bit dos is a different matter. Conventional memory is 640kb, but the CPU can address 1MB (+another area slightly smaller than 64k via the A20 line)

DOS has very limited ability to use memory above 1Mb. It can use ~64Kb of HMA via A20. It can map up to 128Kb to D000 via EMS (aka UMB). As I know, initially back in XT era EMS was something like video memory, i.e. added via expansion card. But after AT it's emulated and therefore requires v86, that is available since 386. These two are usually used by DOS itself in order to free conventional memory for older applications, that don't support HMA or UMB. And it can use up to ~15Mb of XMS (via 16bit DMA, I guess, more on 386, where it's also emulated via v86), that works more like fast swap file, i.e. isn't usable directly.

[marcov]

That's for 32-bit dos extender apps (like FPC's go32v2).    16-bit dos is a different matter. Conventional memory is 640kb, but the CPU can address 1MB (+another area slightly smaller than 64k via the A20 line)

DOS has very limited ability to use memory above 1Mb. It can use ~64Kb of HMA via A20. It can map up to 128Kb to D000 via EMS (aka UMB).

Afaik the EMS pageframe was commonly 64kb, or even 32kb. (I used Qemm mostly at the time)

As I know, initially back in XT era EMS was something like video memory, i.e. added via expansion card. But after AT it's emulated and therefore requires v86, that is available since 386.

Euh.... But AT is 286 ? And v86 is something else. Anyway I did a write up a while ago for dos ain't dead:

I quite often see confusion between extended/expanded memory on one side, and XMS and EMS on the other.

I sometimes use the term AT, which is a more standardise motherboard architecture for a 286. There are really _weird_ ones that aren't, but those are rare.
----------

Basically "extended memory" is what we now consider memory. So simms or dimms plugged into the motherboard, directly accessible/addressable memory to the CPU. It is the same memory as the first 1 MB, but simply the part that is isn't accessible directly in 16-bit CPU modes. (*)

Expanded memory is basically _any_ memory, anywhere (typically a plugin card in some slot), , made available over a driver. In XT times this was a way to expand memory beyond 1MB while the CPU and mobo couldn't handle it.

But even while the 286+ (or better AT, so 286 on a suitable AT mobo, some very early 286's excluded) could address more (than 1MB+64kb), it couldn't in 16-bit mode.

To make these kinds of physical memory (extended mobo, or off it) accessible to then still dominant 16-bit apps, APIs were defined.

The oldest API (which is "EMS") for access to expanded memory, basically instruments the driver to move the data from the external memory to the 16-bit page frame and vice versa. (the page frame is typically an area of 64KB in the 640-1MB area that is accessible to the processor in 16-bit modes, QEMM defaults to C000-CFFF IIRC). The API doesn't expose too many details.

XMS is a similar API that allows Extended memory to be copied between the Dos 1MB(optionally +64KB, A20) and the memory above that area. It is a bit more transparent and 1:1, since extended memory as directly CPU wired memory has to be transparent anyway.

Now the confusion starts, since Expanded memory can be anywhere, it can also be in Extended Memory.

So extended memory can be used for EMS too, and usually except for XTs and some weird systems, this has been the norm since the AT/286 era. Stronger even, since the 386 features a MMU, for 16-bit applications EMS can be very efficient, since the copying to and from the page frame can be done by zero copy memory mapping rather than copying.

Finally, the API DPMI is usually used with dos-extenders that puts the processor in protected mode (only briefly returning for real mode interrupts), so the application can access extended memory (286: 16MB 386:4GB) directly. For 386 systems, the startup code allocates all available memory via XMS, and then the application accesses it as "direct" memory till it terminates.

The only 286 PM programs that I made (Borland/Turbo Pascal 7) afaik got heap memory on the fly by doing heap calls when allocated. I.e. it didn't allocate anything up front, but 286 PM program allocated it piecemeal.

The reason for this difference is that the 386 with its MMU can map all available memory, but only really allocate it (from the free XMS memory pool) when the CPU accesses it, and simulate it by swapping to disk if the XMS pool is empty.

(*) Something similar happened again when 32-bit got too tight, and they expanded the memory bus to 36-bit and defined an API (PAE) to allow special 32-bit apps like Exchange and SQL Server to handle more than 4GB. The OS usually was fully 36-bit (using a segmentation model), but the apps were accessing an API to escape the 32-bit constraints.

[Mr.Madguy]

Euh.... But AT is 286 ? And v86 is something else. Anyway I did a write up a while ago for dos ain't dead:

I mean, AT didn't have hardware EMS, so EMS was reintroduced on 386s only. That's why I say "after AT". But I can be wrong. At least two my 286s didn't have EMS. May be I needed some expansion card to add it. And on 386 it was actually emulated via v86. I.e. EMM386 switches processor to 32bit protected mode, DOS works in v86, EMS is emulated via paging mechanism and XMS is emulated via direct memory copying.

P.S. And it's possible, that UMB and EMS - are two different things. DOS memory is extremely confusing. Engineers needed lots of imagination to think up all those names for different memory systems.

[marcov]

Euh.... But AT is 286 ? And v86 is something else. Anyway I did a write up a while ago for dos ain't dead:

I mean, AT didn't have hardware EMS, so EMS was reintroduced on 386s only.

Afaik there was, if you loaded an ems.sys driver, and (sometimes) configured the bios: https://dosdays.co.uk/topics/ht12_xms_ems.php

But I have no owner experience of 286's, just saw them at friends. I started with the 386SX (after Commodore computers)

P.S. And it's possible, that UMB and EMS - are two different things. DOS memory is extremely confusing. Engineers needed lots of imagination to think up all those names for different memory systems.

Basically 640-1024kb is I/O address space. It might be more or less filled with memory I/O ranges of cards.

The rest can be used for UMB's, which is usable memory (to dos) in that region, not covered by card memory I/O blocks. One of the uses for that area is the EMS pageframe.

[paule32]

I saw 286 with NOVEL
Thus with token ring network interface cards with terminators, and end-up resistors.
It was the time, where Zack Mac Crackn or Larry Lofer came out.
But never ending the connections of networks based on MS-DOS.
The only thing was a IBX Connection (from Novel) - there you have no IP-Numbers, but Computer names
It was the time of Shnippels - the QBasic worms game.
And later Gorilla.