Minor 387 Documentation Mystery

Posted on January 10, 2025 by Michal Necasek

So here I am, writing a bit of test code to figure out the behavior of x87 FPUs with regard to saving and loading the FPU state (FSTENV/FLDENV and FSAVE/FRSTOR instructions in different modes and formats).

The original real-mode only 8087 state format included the instruction and operand pointers as 20-bit linear addresses (because $REASONS) and also stored 11 bits of the floating-point (FP) opcode; the remaining five were always the ESC instruction.

The 287 also needed to be able to save the state in protected mode, with full segment and offset addresses. For whatever reason, Intel decided to keep the size of the saved FP environment (7 words); because the saved code and data pointer addresses used 32 bits each instead of 20, there was no longer room for the floating-point opcode. That wasn’t a huge deal because the opcode could be fished out of memory.

When the 387 came out, it naturally needed to support 32-bit state, with 16-bit segments and 32-bit offsets. Instead of 7 words, the 32-bit state was extended to 7 dwords, with extra padding in reserved fields.

I was pretty sure the floating-point opcode is there somewhere in the 32-bit protected-mode state, but needed a reminder as to where exactly. I happened to have Agarwal’s 80×86 Architecture & Programming, Volume II (1991) open on a nearby page, so I looked there first. On page 240, there’s a diagram of the 32-bit protected-mode FPU state format. But no FP opcode. Odd.

The next closest book was Hummel’s PC Magazine Programmer’s Technical Reference: The Processor and Coprocessor (1992). On page 696, documenting the FSTENV/FNSTENV instruction, there’s the saved state diagram. But again, no floating-point opcode! Is my memory that bad? (Rhetorical question, don’t answer!)

Continue reading →
Posted in Documentation, Intel, x87 | 6 Comments

The Other Three

Posted on January 2, 2025 by Michal Necasek

A previous blog post explored the semi-mysterious yet sometimes highly useful DOS APPEND command. Now it’s time to look at its relatives: ASSIGN, JOIN, and SUBST.

ASSIGN

ASSIGN is the oldest of the bunch. It was written by IBM and first appeared in PC DOS 2.0 in March 1983 (it wasn’t part of MS-DOS 2.x). It is very simple and rather limited.

ASSIGN re-routes requests to an existing drive to another drive. If the user runs

ASSIGN A=C

then requests to drive A: end up addressing drive C: instead.

Note “existing” — the drive letter that is being reassigned must exist. On a machine that has drives A:, B:, C:, and D:, an attempt to run

ASSIGN F=D

will fail with “Invalid parameter”.

Like APPEND, the ASSIGN command is a TSR, and it is one of the earliest DOS TSRs, together with the PRINT command.

ASSIGN works by intercepting INT 25h and 26h vectors (direct disk I/O) and re-routes all accesses according to its internal drive map.

There are no provisions to unload ASSIGN, but running ASSIGN without any arguments will clear its drive mapping table and undo any effects of previous ASSIGN commands.

In later DOS versions,

ASSIGN /STATUS

will show the current drive mappings, if any.

Continue reading →
Posted in DOS, IBM, PC history | 13 Comments

I Thought I Found a Bug…

Posted on December 25, 2024 by Michal Necasek

So I was working on improving a DOS emulator, when I found that something seemingly trivial wasn’t working right when COMMAND.COM was asked to do the following:

echo AB> foo.txt
echo CD>> foo.txt

Instead of ABCD, foo.txt contained ABBC.

I verified that yes, the right data was being passed to fwrite(), with the big caveat that what COMMAND.COM was doing wasn’t quite as straightforward as one might think:

  • Open foo.txt
  • Write ‘AB’
  • Close foo.txt
  • Open foo.txt
  • Seek one byte backward from the end of the file
  • Read one byte
  • Write ‘CD’
  • Close foo.txt

The reason for the complexity is that COMMAND.COM tries to deal with a case that the file ends with a Ctrl-Z character (which wasn’t the case for me), and if so, the Ctrl-Z needs to be deleted. Somehow the seek/read/write sequence was confusing things. But why?

Continue reading →
Posted in Bugs, C, Development, Watcom | 25 Comments

DOS APPEND

Posted on December 20, 2024 by Michal Necasek

For a long time, I couldn’t quite grasp what the DOS APPEND command could possibly be good for. Until I came across a situation which APPEND was made for.

When I worked on organizing and building the DOS 2.11 source code, I tried to place the source files in a tree structure similar to that used by DOS 3.x (this is known from DOS 3.x OAKs):

C:.
└───src
    ├───bios
    ├───cmd
    │   ├───chkdsk
    │   ├───command
    │   ├───debug
    │   ├───diskcopy
    │   ├───edlin
    │   ├───exe2bin
    │   ├───fc
    │   ├───find
    │   ├───format
    │   ├───more
    │   ├───print
    │   ├───recover
    │   ├───sort
    │   └───sys
    ├───dos
    ├───inc
    └───msdos

The inc subdirectory unsurprisingly contains shared include files such as DOSSYM.ASM, which are included just about from everywhere. No problem, right?

Except… to get output that most closely matches existing DOS 2.x binaries, it is necessary to use an old version of MASM (version 1.25 seems to do the trick). But MASM 1.25 is designed to run on top of DOS 1.x, and knows nothing whatsoever about directories.

It is possible that back in the day, DOS 2.x was built from a single huge directory on a hard disk. In fact it is known that DOS 2.0 could not be built on PCs at all, and was built on DEC mainframes. Yet DOS 2.11 was also clearly modified such that it could be build on PCs using Microsoft’s development tools.

However it was done back in 1983, lumping 150+ assembler source files into a single directory, and then adding hundreds of object and executable files, did not sound at all appealing. Cloning DOSSYM.ASM to every directory where it was needed seemed even worse.

That’s when I somehow remembered that APPEND exists, and realized that it’s the perfect solution to the problem. Before building, one can run

APPEND ..\..\INC;..\INC

and the inc directory becomes accessible from all of its sibling subdirectories and from subdirectories one level deeper. It would have been possible to use an absolute path as well, but this way the build batch file does not need to know where it lives.

With APPEND in place, the old MASM 1.25 which uses FCB I/O will find the centrally located include files, and the source code can be organized into a neat hierarchical structure that’s far easier to work with than one giant blob.

Continue reading →
Posted in DOS, IBM | 44 Comments

Stack Checking on OS/2

Posted on November 19, 2024 by Michal Necasek

A while ago I was involved in debugging a seemingly simple yet mysterious problem:

That error message should not have been there

A piece of code (a fairly simple interface DLL) built with the Open Watcom compiler was failing with a bogus stack overflow error. The mystery was that this failure only happened on OS/2 Warp Connect. It didn’t happen on OS/2 2.0 or Warp Server for e-Business (WSeB) or MCP2. And it also didn’t happen on Warp Connect updated to FixPack 40.

That’s weird, right? And getting to the bottom of the faulty stack check was a bit of a journey…

Continue reading →
Posted in Debugging, Development, OS/2, Watcom | Leave a comment

Programming NetBIOS on OS/2

Posted on October 23, 2024 by Michal Necasek

Recently I spent some time trying to understand a piece of networking code, and it turned out to be far more difficult than it should have been. The code in question is the NetBIOS interface of C-Kermit and was originally written in the early 1990s.

The module uses two very similar but not identical code paths. The comments suggest that one alternative, using ACSNETB.DLL, is the “Traditional NetBios interface” used by IBM’s LAN Adapter and Protocol Support (aka LAPS), OS/2 Extended Services, and Communications Manager/2. The other code path uses NETAPI.DLL and it’s called “Newer Netbeui Interface”, used by the Microsoft LAN Manager Requester, IBM LAN Server Requester, and Novell Netware Requester. The comments are wrong, but more about that below.

The API used by NETAPI.DLL is documented in the Microsoft LAN Manager programming reference. It consists of four functions: NetBiosEnum, NetBiosOpen, NetBiosSubmit, and NetBiosClose. The NetBiosSubmit function takes an NCB (Network Control Block) as input, except the NCB usage is left more or less completely undocumented by Microsoft.

The LAN Manager document points programmers curious about NCBs to the “IBM PC-NET Technical Reference”, “IBM PC LAN Technical Reference”, and “IBM PC-LAN Technical Reference”, all in the same Microsoft manual. (Which is exactly why IBMers considered Microsoft sloppy and undisciplined.)

My initial search for programming the ACSNETB.DLL interface turned up nothing. I could not find anything in the Communications Manager manuals, or in the MPTS documentation, or really anywhere one would normally find OS/2 programming information. Because it’s not there.

Continue reading →
Posted in Development, Documentation, IBM, Microsoft, Novell, OS/2 | 12 Comments

OS/2 TCPBEUI Name Resolution

Posted on October 8, 2024 by Michal Necasek

Sometimes I have the following problem to deal with: An OS/2 system uses NetBIOS over TCP/IP (aka TCPBEUI) and should communicate with a SMB server (likewise using TCPBEUI) on a different subnet. This does not work on OS/2 out of the box without a little bit of help.

History and Technology

NETBIOS (originally literally the ROM BIOS on the 1984 IBM PC Network adapter) was designed to work on a LAN, specifically a single LAN segment. There is no need for centralized infrastructure, workstations can come and go. This makes using ad hoc networks very easy and does not require additional dedicated infrastructure and administration.

When NETBIOS (or NetBIOS) moved to Ethernet, there were initially many different ways of implementing it. Eventually the world settled on NetBIOS Frames aka NBF.

But in the 1980s, there was also a parallel effort to move NetBIOS on top of TCP/IP, eventually standardized as RFC 1001 and RFC 1002 (both dated March 1987). This effort was originally driven by non-PC platforms, but soon enough DOS-based (e.g. HP ARPA Services circa 1990, PC/FTP likely earlier) and OS/2-based (MS LAN Manager 2.1 in 1991) implementations of NetBIOS over TCP/IP became available.

As mentioned above, classic NETBEUI (whether using the original IBM PC Network Adapter, Token Ring NETBEUI, the NBF protocol, or some other variant of NetBIOS over Ethernet) always resolves names using broadcasts. When a workstation (i.e. a NetBIOS application running on that workstation) looks for a NetBIOS “name”, it uses a broadcast to find out the network address of the machine which owns that name; this is not unlike ARP.

Continue reading →
Posted in IBM, Networking, OS/2, TCP/IP | 49 Comments

IBM PC 5150 Model Numbers

Posted on September 24, 2024 by Michal Necasek

Recently I came across a minor mystery—the model numbers of the original IBM PC. For such a pivotal product, there is remarkably little detailed original information from the early days.

When IBM started selling the PC, it used two methods to identify various items. The vast majority of peripherals and accessories used a seven-digit part number; for example the original CGA was part number 1504910.

The system unit itself was Type 5150 (the PC; 5160 was the XT), and the type designation was extended with a three-digit model number, such as 5150-013. The same scheme was used for “big ticket” peripherals that were not necessarily tied to the PC. For example the original monochrome monitor was designated as 5151-001 and the printer as 5152-001 (the color monitor was Type 5153 and so on).

For monitors and printers, the three-digit model number wasn’t all that meaningful as there often was only one model. But for the 5150 system unit, there were lots of different models.

Now, the problem is that there appears to be no official documentation whatsoever from the old PC days that would list the model numbers with clear specifications.

Continue reading →
Posted in IBM, PC hardware, PC history | 25 Comments

OS/2 2.0 Commitments

Posted on September 23, 2024 by Michal Necasek

Last week the OS/2 Museum received a rather interesting donation: a thick spiral bound document titled Third party commitment to IBM’s OS/2 Version 2.0, and labeled IBM COMDEX/SPRING ’92.

The binder is a collection of about 250 press releases that coincided with the release of OS/2 2.0 and also with the COMDEX trade show in early April 1992 (the press releases are dated April 6, 1992). The interesting thing is that each press release is printed on the respective company’s letterhead paper, using a wide range of paper weights and types; it is apparent that each company printed their own press release, mailed it to IBM, and then someone at IBM bound them into an official looking document. It is unclear how many copies of this document were made. There could conceivably be the only one copy in existence.

The document is a veritable who’s who of early 1990s PC world, predominantly software (Adobe, Attachmate, Borland, Citrix, Corel, Ingres, Lotus, Novell, SAP, Symantec, Watcom, WordPerfect, ZSoft) but also hardware (Accton, ATi, Cirrus Logic, Digital, Fujitsu, Intel, Logitech, Matrox, NCR, Racal-Datacom, Tseng). The companies range from one person operations (Hamilton Laboratories) to huge corporations. Only Microsoft was mysteriously missing.

For details, please refer to the scanned OS/2 2.0 third party commitment document.

Continue reading →
Posted in IBM, Marketing, OS/2, PC history | 8 Comments

OS/2 2.11 SMP Woes

Posted on September 8, 2024 by Michal Necasek

IBM OS/2 V2.11 for Symmetric Multiprocessing (OS/2 2.11 SMP) was released in mid-1994 in response to Windows NT and its SMP support. The package was nothing more (and nothing less) than OS/2 V2.11 with support for SMP hardware. It was intended primarily for server machines, not least because non-server SMP systems were nearly nonexistent in 1994.

OS/2 2.11 SMP was often shipped with high end servers, for example on IBM’s ServerGuide or Compaq’s SmartStart CD-ROMs (alongside Novell NetWare, SCO OpenServer, etc.). But a generic OS/2 2.11 SMP package had not been seen in the wild… until it appeared relatively recently (2020).

The included photos suggest that there was some kind of shrinkwrapped OS/2 2.11 SMP package, although in the absence of an actual box it’s hard to be sure. It is still unclear how exactly generic OS/2 2.11 SMP was sold and supported—although fixes for OS/2 2.11 SMP did exist, they do not appear to have been distributed through the usual public channels.

Knowing that OS/2 Warp Server Advanced SMP and Warp Server for e-Business work well enough, I thought I’d try OS/2 2.11 SMP in VirtualBox. Only that turned out to be much less than straightforward.

Continue reading →
Posted in IBM, OS/2, PC history, SMP | 31 Comments