29

MS-DOS drivers were designed to handle character or block devices. HIMEM apparently does not fall into this "paradigm"; and if we look into HIMEM disassembly, we can see that HIMEM, despite providing a bogus device name "XMSXXXX0", actually only supports the "init" function and responds with the "unsupported function" error to any driver request other than "init".

On the other hand, HIMEM installs interrupt handlers to provide its API to other programs which would be more typical for a TSR program.

Did the MS-DOS driver model provide any other non-obvious (or, perhaps, even undocumented) benefits that led to a decision to implement HIMEM as a driver and not as a TSR?

Improve this question
5
  • "On the other hand, HIMEM installs interrupt handlers to provide its API to other programs which would be more typical for a TSR program." Isn't that the same as many block drivers do when hooking the disks int as well?
    – Raffzahn
    Commented Aug 17 at 14:01
  • @Raffzahn I'd assume such interrupt hooking would only be needed if the block driver in question also provides a lower-level BIOS disk device interface in addition to the standard DOS block device driver interface? If anything, I'm not saying DOS drivers should not hook interrupts, I'm only saying I was naively expecting that providing character / block device interface was the primary DOS driver function (which is not the case with HIMEM which only benefits from the early loading available exclusively to installable drivers)
    – DmytroL
    Commented Aug 22 at 8:16
  • @Raffzahn Another interesting example here is sound card drivers, which ARE hardware device drivers but usually install themselves as a TSR (unlike e.g. in Linux where a sound device is available somewhere inside /dev)
    – DmytroL
    Commented Aug 22 at 8:21
  • 1
    Well, for one, disk drives, at least if they are traditional ones, must install interrupt drivers to work with all software directly accessing disks. After all, DOS compatibility alone was never really good enough for the PC market - it always needed to include low level interfaces as well to satisfy all those horrible programming 'tricks' used.
    – Raffzahn
    Commented Aug 22 at 12:28
  • 1
    Sound cards are a different issue as DOS has no Sound-API - DOS does not support sound in any way (BEL handling is not part of DOS). Thus there is neither reason nor benefit to create a DOS driver. Sure, could have been done, only to fight an uphill battle to convince programmers to use complex file I/O and tons of IOCTL calls. No way. Too slow, too complicated, everyone would just write their own low level routines (see games). Linux is different, as a 1990 386 is way faster than a 1981 9088, but it also doesn't allow hardware access or offers a BIOS type interface. Drivers are mandatory.
    – Raffzahn
    Commented Aug 22 at 12:45

5 Answers 5

Reset to default
60

HIMEM has to load very early for it to be most useful. The DOS loader processes config.sys (loading drivers), then loads command.com, which then processes autoexec.bat (loading TSRs). Had HIMEM been a TSR, you couldn’t have drivers that used Extended Memory without conflicts, or (in later versions) load DOS itself in High Memory.

And in a very real sense HIMEM does manage a device: the device is “RAM assigned to high addresses”

Improve this answer
5
  • 9
    As evidence in support of this, the XMS spec explicitly states that “An XMS driver is installed by including a DEVICE= statement in the machine's CONFIG.SYS file. It must be installed prior to any other devices or TSRs which use it.”
    – Stephen Kitt
    Commented Aug 15 at 16:16
  • 7
    DEVICEHIGH and friends wouldn't work too well without this either, unless XMS functionality was built into DOS.
    – ErikF
    Commented Aug 15 at 17:31
  • 3
    @ErikF Despite the "HIGH" or (DR-DOS) "HI" in "DEVICEHIGH" and "HIDEVICE", these directives never make use of "high memory" as in the HMA. Rather, they try to allocate memory from the UMA ("upper memory"). DOS technically uses the XMS interface to access UMBs but HIMEM type drivers generally have never provided UMBs, those are usually provided only by EMMs like EMM386.
    – ecm
    Commented Aug 16 at 14:52
  • …and also because the INSTALL= directive wasn’t available back then. XMS 1.0 was released in 1988, the same year as DOS 4.0, which introduced the former.
    – user3840170
    Commented Aug 18 at 13:42
  • @user3840170 but INSTALL= directives are processed last, so they wouldn’t have been suitable for an XMS driver anyway. (And compatibility constraints meant that INSTALL= couldn’t be designed so that it could work for an XMS driver. In particular, DOS=HIGH[,UMB] must be resolved before regular executables can be started.)
    – Stephen Kitt
    Commented Aug 18 at 17:39
15

XMS was not the first memory driver to use this technique: EMS 3.0, introduced three years previously in 1985, used a similar handle name, EMSXXXX0 to indicate its presence. (Sadly, I couldn't easily find the 3.0 specification and linked to the 4.0 one, but it's been around since then.)

The name itself was arbitary, and as the EMS specification indicates, it's not the only (or preferred) detection method for all programs, as there are some drawbacks to detecting EMS using the driver name: for example, other device drivers and TSRs interrupting DOS services were supposed to check the fake INT 67h address.

Improve this answer
1

While Euro Micelli's Answer already points out two important facts,

  • it being a device driver for an additional memory system and
  • the need to load it early on,

one might want to add a third, quite relevant reason:

  • Providing XMS is a hardware specific service, only to be loaded on machines with that hardware - aka at least a 80286 or later type CPU, as well as enabling hardware.

This ends up as two additional facets:

  • It must be optional as DOS is a straight 8086 OS. Packaging features for any hardware past a basic 8086 CPU needs to be packed into drivers not just because they are additional, but as a driver it can also decide not to stay resident, thus not clogging up memory on an 8086/88/186/188 machine.

  • It must be machine specific. Other machines than the IBM PC/AT may feature enhanced or plain different hardware (*1) Than the PC/AT. HIMEM.SYS driver delivered with Win/286 is machine specific for the PC/AT. Likewise the one delivered since 4.01 with PC-DOS and generic MS-DOS. It's made for an IBM AT computer ore a 100% compatible machine - as in featuring an A20 gate, etc.

    Any other machine would need (and did get) its specific HIMEM.SYS by MS or its manufacturer. Yes, those were still a thing during all of the 1980s.

Bottom Line: HIMEM.SYS is a prime example of a driver that needs to be loadable.

*1 - This includes several later IBM machines.

Improve this answer
-4

Himem.sys provides access to extended memory using the XMS api. Several software packages require this, including MS-DOS itself and Microsoft Windows.

The other answers are correct implementing himem.sys as a device driver allows it to be loaded before other device drivers, including emm386.exe which requires himem.sys to be loaded first. However parts of MS-DOS (starting with version 5.0) can be loaded in the HMA, which would happen after himem.sys is loaded, so it is possible to move code within memory. However, this might be something complicated to do. So this only happens with known code. Which is is fine because there only room for one 64Kb segment in the HMA.

Before MS-DOS 5.0, Windows 2 was another Microsoft product that could load itself in the HMA. It was the first product to include himem.sys. It also included ramdrive.sys and smartdrv.sys which both could use extended memory without himem.sys loaded first, but later versions do need himem.sys to be loaded first. However, a readme file included explicitly states that himem.sys should be loaded first to make sure enough extended memory is availible to use the HMA. So that would be a more specific reason that himem.sys was implemented as a device driver, to allow it to be loaded before ramdrive.sys and smartdrv.sys. However, if both where implemented as a TSR, I don't see a reason why himem.sys could not be implemented as a TSR as well.

Windows 95 actually included a program called xmsmmgr.exe. This was more or less an implementation of himem.sys as an TSR. It was loaded when setup was started from MS-DOS when himem.sys was not loaded. Setup ran, just like previous Windows versions, partly in Windows which would require extended memory. So it is possible to implement himem.sys as a TSR and there would be a good reason to do so. Otherwise it would have to copy himem.sys to the hard drive, change config.sys, reboot, and then start setup again. Or would ask the user to do this. Both these methods could fail in many situations. It may also break some applications if the setup was aborted or the computer was restarted in previous DOS mode.

It would also be possible to implement the himem.sys functionality as a part of the MS-DOS system files (io.sys and msdos.sys). However this would make those files a little bigger and might require more memory if extended memory is not needed or is not present. Or if a different memory manager is required, for example a newer version of himem.sys which is supplied with a version of Windows that is newer than the installed DOS version. Eventually Microsoft did combine the MS-DOS system files and himem.sys into one file in Windows ME.

Improve this answer
9
  • 5
    AI is getting better at it...
    – Raffzahn
    Commented Aug 17 at 13:57
  • @Raffzahn I'm curious, did you comment on my answer because you didn't liked it? If so what did you not liked about it? Did my writing style bother you in some way? Or was it too long? Or perhaps too much off topic? Please be honest, so I may learn from it.
    – Arjen Krap
    Commented Aug 17 at 18:27
  • 4
    Well, sure 'you' want. It ticks all the usual boxes of AI generated text, including the ones mentioned. Long, meandering along many often only marginally related details and so on - while at the core neither answering the question nor showing real understanding of topic and it's structure. Bottom line: the usual superficial fact soup an AI isgood at.
    – Raffzahn
    Commented Aug 17 at 21:56
  • 1
    @Raffzahn I agree this is a poor answer for a bunch of reasons. I'm not convinced it is an Artificial so-called-Intelligence creation.
    – manassehkatz-Moving 2 Codidact
    Commented Aug 18 at 2:02
  • @Raffzahn I now understand I did not read question in a good way. DmytroL specificly asked about technical differences between programming a device driver and programming a tsr, while I focused on the more practical use of himem.sys.
    – Arjen Krap
    Commented Aug 18 at 8:47
-6

HIMEM was implemented as a DOS driver to manage extended memory efficiently and provide system-wide memory access, unlike TSRs which are typically used for task-specific, temporary operations.

Improve this answer
1
  • 5
    This generates more questions than it answers. Why can a DOS driver manage memory efficiently but a TSR could not? If you could explain that, rather than just asserting it to be true, this could turn into a reasonable answer.
    – dave
    Commented Aug 17 at 16:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .