Grzyb wrote on 2024-05-21, 21:47:

Jo22 wrote on 2024-05-21, 21:17:

There were DOS compatible, i386-based multi-user operating systems like real/32 or PC-MOS/386.
They weren't using much 32-Bit code yet, but that wasn't needed at the time.

[..] 32-bit was needed, and BADLY. [..]

32-Bit was being welcomed, but in the 80s, the primary objective was to get rid of 640KB barrier and code size limits for applications.
Support for EMS and Protected-Mode (any) allowed for this.

OS/2 1.x could handle about 512MB of RAM, if memory serves.
LIM EMS did support 32MB of RAM and variable page sizes (the old 4x 16KB remaining somewhat popular, though).

32-Bit code was being popular on Unix workstations at the time (late 80s), however, I suppose.

On PC though, the ability to keep using PC software was an important factor.
Things like Clipper, dBase, and other professional programs were what many businesses depend on.

Also, printers and networking were beibg based on proprietary DOS software sometimes.
Changing them wasn't so easy. That's when multi-user/multi-tasking systems like PC-MOS/386 came in handy.

They were DOS compatible, but also had their native interrupts with additional functionality.

That way, a high-end developer PC (or the PC of the company owner) could be integrated on an existing DOS based ecosystem.

The use of 16-Bit instructions, combined with use of 32-Bit Protected-Mode allowed virtualization similar to what EMM386 did later on.

With the difference that an OS like PC-MOS/386 could directly use 16-Bit BIOS service routines (v3 still can run on XTs, at least. Minus enhanced features.)

So there was no risk involved, as there wpuld have been with true blue 32-Bit OSes that use 32-Bit pointers and registers all time.

So all in all, going full 32-Bit wasn't an option yet, I think. At least not on DOS, in mid-late 80s.
Here, Xenix and Minix were other 16-Bit alternatives to PC users.

But if 32-Bit was really needed (relative, SQL style databases), DOS Extenders by Pharlap and
other companies were a workaround to have such high-performance programs on DOS, if occasionally needed.

Functionally, they were akin to Win32s running on top of Windows 3.1 (ok, not fully; Win32s uses lots of thunking).
They maintained communication with both host OS and the application.

Edit:

Grzyb wrote on 2024-05-21, 21:47:

[..] […]
Show full quote

Jo22 wrote on 2024-05-21, 21:17:

There were DOS compatible, i386-based multi-user operating systems like real/32 or PC-MOS/386.
They weren't using much 32-Bit code yet, but that wasn't needed at the time.

[..]

And that's my point: if IBM and/or Microsoft released "32-bit DOS", it would have dominated the market as soon as 386+ machines got common, and everybody would have been forced to support it.
Majority of problems like "too much RAM" would have been easily resolved by upgrading the OS.

I'm not sure if that was ever going to happen.
IBM was afraid of the i386, also because of the mainframe business.

It was too powerful, simply. As far as IBM goes, the 80286 was limit for a desktop PC.

Also, IBM didn't support clone PCs before circa PC-DOS 3.30, released in '87.

And strictly speaking, MS-DOS 4 was meant to be the final DOS, anyway.

If it wasn't for Digital Research's DOS 5, the era of DOS had ended somewhere shortly after 1990.

Because nobody want to keep using DOS, once a good alternative was in sight.

That's why IBM created the Family API and wanted developers to move over to it.
It could help create programs that ran on then-current DOS, as well as future OS a ("real OS") like OS/2.

From a DOS 3.30 user's perspective, DOS was a very limited little single-tasking OS that was very cumbersome to use.

Unless Norton Commander, XTree Gold or GEM were being installed, I mean.

Meanwhile on Motorola 68000 computers, the matured CP/M-68k was available for years. Still 16-Bit, though, like DOS.

On the Atari ST, the TOS operating system was running on top of CP/M 68k, essentially.
Along with GEM as a GUI. So there was an powerful alternative to MS-DOS, already. It just wasn't x86 based.

The aforementioned PC-MOS/386 essentially was some sort of PC alternative to MP/M or MP/M-86, all in all.
Both had virtual consoles, could address lots of memory and so on.

Jo22 wrote on 2024-05-21, 22:14:

OS/2 1.x could handle about 512MB of RAM, if memory serves.

Physical, or virtual?

I suspect virtual...
286 protected mode = 14-bit segment + 16-bit offset = 30 bits = 1 GB
Half for system, half for application seems logical...

For more than 16 MB of physical, however, it would have to be 386-aware...
Was OS/2 1.x 386-aware?

And it really looks like we could use a general OS/2 thread 🤣

Grzyb wrote on 2024-05-21, 22:47:

Jo22 wrote on 2024-05-21, 22:14:

OS/2 1.x could handle about 512MB of RAM, if memory serves.

Physical, or virtual?

Um, not sure, have to check.

It depends on the type of OS/2 distribution, I think MS ot IBM.

Microsoft had added i386 support, whereas IBM was using 80286 code.

The 80286 had 1 GB adress space for virtual memory, using segmentation.

It had been split in two for user/kernal space, I suppose. Could be wrong, though. 🤷‍♂️

The Microsoft version might be able to address 512MB physically, if run on an supported i386 model.

That's what OS/2 1.x applications on OS/2 2.x and higher can use, at least. Or so I heard.

Memory beyond 64MB needs the correct BIOS support, I believe. That's why later PCs have an option in CMOS Setup.

IBM PS/2 PCs had some BIOS extensions that ATs didn't have.

Edit: I think what's ofgen being forgotten is that OS/2 started out as a text mode system.
It looked like MS-DOS, essentially.

The aforementioned Family API programs could run on DOS 3.30 and on OS/2.

I tested many games in the DOSBox first, and then distributed them to the retro PCs via CD or USB. So I apparently avoided the setup problems by accident. SimCity 2000 or Dune II will then work without errors. The sound could also be changed without any problems. The only example I can think of is Aladdin. I only installed this because it is very special. Lots (?) of XMS, plus EMS, but not over 32MB of RAM. I have 256MB of which 64MB can be used in DOS. Still 32MB too much. Everyone then calls directly for ramdisk, but without being an expert and coming to DOS late, I have no idea about it, it's far too time-consuming for me. For the real DOS (doesn't work with that of Windows 98) I found a small program called EATXMS. If necessary, you can divert 32MB from the RAM in the shortest possible time and without any effort.

I'm using a program called "Memeater" for such cases. Works without problems so far.

I want to try out EATXMS as well to have alternatives.
I can't find a download link 🙁

Can someone provide one?

Found a link for EATXMS:

http://www.win3x.org/win3board/viewtopic.php?t=27301

Himem.sys also has a switch that can be used to lower available XMS memory.
It's /INT15= and it'll reserve some memory for the int15h BIOS call, which might even increase application compatibility.

Another alternative to a RAM disk is to use an EMS manager, maybe.
Like EMM286 or EMS Magic. It can eat some XMS memory, too. But it also needs an 64KB page frame..

Sorry, didn't know there was interest in EATXMS. I got this from there, there are even more tools to get older games running, maybe someone can use something.
http://www.oldskool.org/guides/oldonnew/resources

Thanks @Demolition-Man 😀
Very useful link!

From memory... Command and Conquer (DOS) First/Original version. The game crashes. (BUT the "Setup" EVA works fine) I believe the later version did not...

Jurassic Park. If you have more than 8MB of ram the soundblaster SFX don't work.

Grzyb wrote on 2024-05-20, 19:56:

Strange, I've never encountered such problems. And it seems to only use conventional memory, refusing to run if too many drivers […]
Show full quote

Kalle wrote on 2024-05-20, 18:18:

Pinball Fantasies crashes on startup.

Strange, I've never encountered such problems.
And it seems to only use conventional memory, refusing to run if too many drivers/TSRs are loaded.
Why would it even care about extended memory?

I took a look at it again, and actually I was wrong. Pinball Fantasies itself runs fine, it's the setsound utility that crashes with a Page Fault when there's too much XMS available.
When launching Pinball Fantasies directly by executing PF.EXE, there's no issue.
When launching Pinball Fantasies using the PINBALL.BAT, setsound was called and it crashed. Limiting the XMS with XMSDSK helps, setsound runs fine again. I guess I must have always tried launching it using the bat file instead of the exe, which led me to think it was the game itself.

mkarcher wrote on 2024-05-21, 18:18:

There are different versions of Pinball Fantasies. Most notably, GOG sells "Pinball Fantasies Deluxe". IIRC something in Pinball Fantasies Deluxe uses a DOS externder that crashes if too much memory (EMS or XMS) is available, whereas classic Pinball Fantasies is a plain real mode application.

Kalle wrote on 2024-05-25, 19:29:

I took a look at it again, and actually I was wrong. Pinball Fantasies itself runs fine, it's the setsound utility that crashes with a Page Fault when there's too much XMS available.
When launching Pinball Fantasies directly by executing PF.EXE, there's no issue.
When launching Pinball Fantasies using the PINBALL.BAT, setsound was called and it crashed. Limiting the XMS with XMSDSK helps, setsound runs fine again. I guess I must have always tried launching it using the bat file instead of the exe, which led me to think it was the game itself.

OK, seems legit: SETSOUND in the later release uses extender, and crashes.

Warlords 2 Deluxe will crash if there's more than 8MB of EMS available.

The installer of Alien Trilogy check the total memory, and it is a pain.
But the game runs fine without checking.

capitaine wrote on 2024-06-01, 17:41:

The installer of Alien Trilogy check the total memory, and it is a pain.

There is a patch for Alien Trilogy allowing it to be installed on computers with larger amounts of RAM, can be found here.

SimCity 2000 CD-ROM version 1.01 installer complains about insufficient memory but installs and runs without problem. This was on a system with 128 MiB RAM.