HN user

pdw

3,036 karma
Posts14
Comments491
View on HN

In the early 90s Microsoft distributed the full Win32 API documentation as a WinHelp file. It felt very much as hyperlinked man-pages. Super fast too, even on machines of the time. WIN32.HLP can still be easily found, but modern Windows versions no longer ship WinHelp :(

"Shipping" wouldn't be a problem, they could just run it from a network drive. Their PCs were networked, they needed to test deathmatches after all ;)

And the compilation speed difference wouldn't be small. The HP workstations they were using were "entry level" systems with (at max spec) a 100MHz CPU. Their Alpha server had four CPUs running at probably 275MHz. I know which system I would choose for compiles.

All of Microsoft's applications used to do that! The 16-bit versions of Word, Excel, PowerPoint, etc all were implemented using bytecode. That technology was only integrated in Microsoft C and made public in 1992 [1], before that the Microsoft applications group used their own private C toolchain. A copy of it can be found in the Word 1.1 source release [2] ("csl").

[1] https://sandsprite.com/vb-reversing/files/Microsoft%20P-Code... [2] https://github.com/danielcosta/MSWORD

Rosetta uses software emulation for x87 floating point. That's slow, but in practice that doesn't matter much. Mac software never had a reason to use x87 FP, every Intel Mac had at least SSE3 support.

The signedness of `char` is implementation-defined, it is signed on x86 but unsigned on ARM. So assigning a plain char to a wider integer type is suspicious, did the programmer expect sign-extension or zero-extension?

I always wondered how secure AS/400 actually is. The original implementation might have checked tag bits in hardware (I don't know), but the current (PowerPC) implementation relies on the compiler generating a "check tag bits" every time a pointer is dereferenced [1]. So it seems that any arbitrary code execution vulnerability would be absolutely devastating. And the "SLIC" is not a small microkernel -- it also contains the compilers, the database and other system components. It'd be hard to believe there would no exploitable bugs in there.

[1] https://www.devever.net/~hl/ppcas

Debian woody (2002) shipped gnustep. I tried it back then, but as far as I remember, it was weird enough that anybody who didn't have NEXTSTEP experience would bounce right off. The floating menus, the weird scrollbars, etc. There were also no non-trivial applications that I can remember.

People back then were looking for something that would be familiar to Windows/Mac users. GNUStep (at least at the time) was not interested in being that.

As a user you can only use the polyfill to replace the XSLTProcessor() JavaScript API. You can't use the polyfill if you're using XSLT for XML Stylesheets (<?xml-stylesheet … ?> tags).

(But of course, XML Stylesheets are most widely used with RSS feeds, and Google probably considers further harm to the RSS ecosystem as a bonus. sigh)

Emacs: The macOS Bug 12 months ago

With an old and conservative project like Emacs, the reason could just as likely be that it was done that way for the NEXTSTEP port in the early 90s and that nobody revisited it since then. Oftentimes the reason is just legacy, limited manpower and "don't fix what ain't broken".

Another fascinating aspect of COBOL is that it's the one programming language that actively rejected ALGOL influence. There are no functions or procedures, no concept of local variables. In general, no feature for abstraction at all, other than labelled statements. Block-structured control flow (conditionals and loops) was only added in the late 80s.