OS/2 Museum

This doesn't answer the question, but FWIW the earliest reference I could find to setlocale or related is from a 1986 journal article, Programmer's Journal, Volume 4, page 45:

> In order to preserve the existing, large body of code, it was decided to place the burden of having a non-USA/ENGLISH environment only on those users who needed it. This will be done by making the C program startup environment default to a native "locale" of USA. Users wanting something else will need to call the setlocale function to set their locale to some other implementation-defined environment.

See https://books.google.com/books?id=XV4qAAAAMAAJ&focus=searchwithinvolume&q=setlocale

So either the 1985 draft already had setlocale, or it must have been added shortly thereafter. However, Microsoft's 1986 reference manual doesn't mention setlocale, despite the introduction saying it was based on the draft standard. See https://www.os2museum.com/files/docs/msc40/ms-c-4.0-rtlref-1986.pdf

IEEE Std 1003.1-1988 (i.e. POSIX), approved 1988, already copied setlocale from ANSI C, presumably based on a draft as ANSI C wasn't ratified until 1989. See https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub151-1.pdf

I can't find any implementation before Version 10 Unix from 1989, followed by BSD4.4-Net/2 from 1991. See https://minnie.tuhs.org/cgi-bin/utree.pl.

Unfortunately none of the early committee notes or minutes seem to be available online. Hopefully someone in the know (possibly an original committee…

>Do we leave real mode as soon as CR0 bit 1 is set

Yes, that's what the bit is defined as doing. Protected mode was introduced on the 16-bit 80286, and 16-bit code segment descriptors are still supported to this day.

Even in real mode, the segment registers have hidden fields containing base, limit and access rights. The difference is that when they get loaded in real mode, the base will be set to the segment shifted left by 4 bits, with the limit¹ and access rights² generally left unchanged. What the PE bit actually affects is how segment load instructions operate, how interrupts/exceptions are handled, and a few other details.

Most instructions run exactly the same microcode in either mode: any memory access will form the address and do protection checks based on whatever is currently in those hidden fields. But a segment load (or far jump) decoded while PE=0 will execute different microcode than one with PE=1.

>That's weird. I tracked down the commit

Shuffling the code around may have fixed some alignment bug? The jump could likely be replaced by two NOPs, in any case the comment is completely wrong.

2.6.22 seems to be the last version using LMSW followed by a near jump, and presumably worked on that CPU (at least there is a comment mentioning bugfixes for Elan), so it isn't likely to be the cause of the problem.

¹ the limit on power-on/reset is 64K, but it is possible to change it to 4G, allowing access to all memory ("unreal mode")

² CS will always be made a…

Given the context and your reference to Quake, I assume by "the older days" you mean the 90s, PCs and early Windows?

If you weren't previously aware of "The Old New Thing" blog, Raymond Chen has been sharing stories about Windows 95 development for decades at this point. So many in fact, he published a book under the same name (the book is essentially a best-of collection from the blog in paper form).

The os2museum[1] blog is also a gold mine. Tim Paterson at one point tried to start blogging, sharing a few anecdotes about the early days of DOS[2]

Speaking of books, you might enjoy "Showstopper!" about the development of NT, even tough it is a bit shallow on the technical side. For the technical aspects, you might want to get it together with "Inside Windows NT" (first edition) by Helen Custer.

You might also enjoy: "Another Boring Topic" [3] YouTube channel, covering (among other things) early Windows development in excruciating detail and "Old Computers Sucked" [4], actually trying to run the software on era appropriate hardware. "Cathode Ray Dude" is all over the place but often also covers hardware and software of roughly that era[5].

A sibling comment already mentioned JWZs blog, if you have fond memories about Netscape, you might enjoy "Project Code Rush" [6].

Btw. Netscape Navigator 3.0 has just turned 30.

[1] https://www.os2museum.com/wp/

[2] https://dosmandrivel.blogspot.com/

[3] https://www.youtube.com/@AnotherBoringTopic/videos

[4]…

What's noteworthy is that EMM386 is also a hypervisor, albeit a very thin one. It is absolutely noteworthy, and something I touch on in my article; Windows/386 was heavily based on EMM386's code, both for the EMS emulation as well as for the V86 monitor itself. EMM386 was the starting point for Windows/386, and CEMM/EMM386 are special because they know how to transfer their state into Windows/386 via GEMMIS aka the Windows/386 Paging Import Specification.

After a conversation with Ralph Lipe, designer of Windows/386, he revealed to me that Windows/386 was so thin of a layer over EMM386 (being a slightly more heavy hypervisor but not by much) that it had no scheduler for 32-bit code; there was one thread of execution in the VDMM that IRET'd into VMs, but each VM did not also have an independent Ring 0 protected-mode context like in Windows version 3.0.

One could imagine an alternate reality in which x86 gained full virtualisation extensions earlier, causing the hypervisor model to be taken even further and creating a bigger architecture gap between Windows and other OSes. Worthy reading would be: https://www.os2museum.com/wp/an-old-idea-x86-hardware-virtualization/

Graphics programming "in the 90s" encompasses a pretty wide range.

You had raw access to things like VGA cards and then different tricks per each individual card when it came to things like SVGA

http://qzx.com/pc-gpe/index.php

You had a few things like UniVBE that tried to create a common platform for VESA cards to be used

https://wiki.sierrahelp.com/index.php/Scitech_UniVBE

Meanwhile, you had things like video drivers for Windows, usually basic 2D functionality:

https://www.os2museum.com/wp/windows-9x-video-minidriver-source-code/

https://www.os2museum.com/wp/antique-display-driving/

In the mid-90's we started getting 3D hardware like 3Dfx and Rendition cards, they each had their proprietary interfaces.

And then finally, the 3D hardware was adopted by standards like OpenGL and DirectX.

>Jolla brings you the best of both worlds – super intuitive Sailfish OS apps and the latest Android™ apps.

The recent article on OS/2 [1] makes me wonder whether such compatibility (which, as I understand, is full and not selective) is actually good for them. Either way, tough, I wish Jolla success; I'd like to see Sailfish OS [2] on an actual device.

[1] See https://news.ycombinator.com/item?id=6792010. The short of it is that the Ars Technica article claims OS/2's compatibility with Windows made developers less inclined to write native applications for OS/2. Some discussion on whether that was the case can be found in the comments to this response to the article: http://www.os2museum.com/wp/?p=2144.

[2] https://sailfishos.org/