Posts by ThomH 3115 publicly visible posts • joined 18 Jun 2009
If you don't understand what was so fantastic about 640x256 pixels with no effect on CPU speed, a full-quality keyboard, both television and RGB monitor support, various ports dedicated to what we'd now call GPIO, and even and a national TV programme to teach you how to use it, all in 1981, then you probably lack substantial historical context.
I'd guess the potential blocker may have been device drivers, especially those written for MS-DOS; Windows 95 and 98 used to jump through some extraordinary hoops to try to retain compatibility with hardware that had shipped years ago with only DOS support, including routing device calls through the DOS filing system stack where necessary.
It'd be surprising if it didn't; e.g. ARC-enabled Objective-C* is smart enough to know when it needn't put things in the autorelease pool**.
* which is not garbage-collected but also definitely, definitely has nothing to say about static memory safety. So not otherwise like Java and definitely not like Rust, in case the mention of anything Apple-related brings the usual red mist amongst any readers.
** a dynamic, runtime-collected list of things that can be freed when the call stack next returns all the way up to the event loop. Objective-C is [almost-]everything-on-the-heap but uses the autorelease pool to allow for temporaries where another language might just use a stack-based object. But with ARC enabled, the compiler doesn't necessarily put things in the autorelease pool, it also sometimes just deallocates them when they've been fully used. But with no scope guarantees, sometimes leading to bugs by C++ developers who mistake ARC as a means of doing RAII for things like mutexes.
I think possibly you're acting under a misapprehension; until a month ago no CHRP version of Mac OS has ever been seen in public. There were a negligible number of CHRP machines ever released, most of them ran AIX, some others ran Windows NT and none whatsoever ran Mac OS.
The licensed Mac clones were not CHRP machines. It seems that later Macintoshes were close, but they came after the shuttering of the clone programme.
Agreed on the '80s not being a wasteland, even though they're before my time; this weekend I had a very strange experience though: I live in the US, and went to my local Waitrose-esque supermarket (it's a Whole Foods), where the in-store music for as long as I was there was: There is a Light That Never Goes Out, followed by Made of Stone.
I tried to spot a 50-ish-year-old Mancunian who might be in charge of the track list but none was obviously present.
My thoughts on Facebook are neither original nor interesting, so I'll just note that it's a shame the Facebook group is private so that it can't easily be read, and that the old NVG list is no longer used.
Otherwise, my code could definitely be used for a full game, it just has restrictions due to its conceit, primarily: single-axis scrolling, and when scrolling that happens at a fixed speed. And obviously you could overload it with too many sprites, too much background detail, etc. I was imagining something in the Dizzy/Wonderboy III vein with collecting objects and/or player transformations acting to gate player progress, but — how original! — I'm very bad at finishing things.
Oh, and I've no idea what music would cost because I've never worked with audio. If it's just push a few registers every frame (and accept that music will be on the simpler side) then there's definitely room for that.
Yep. Links below. But I think I've figured it out: continuing to own and occasionally program for a SAM Coupé makes me feel like I'm somehow righting a 35-year-old injustice. Intellectually I know that this is silly, but it's also pleasant in a solve-a-puzzle sense. I am also aware that programming for the SAM Coupé is almost exactly as consequential as doing a crossword but I also often do a crossword.
Downloads are within its repository; video is here, albeit captured from SIM Coupé on a 60Hz screen so some smoothness is lost.
I'm on my lifetime third SAM; it's hard to qualify the attraction. I recently managed to get a full-screen 50Hz scroll with sprites working, for which I ripped off assets from the Master System... and then wondered whether perhaps I shouldn't just play a Master System game.
Answer: I shouldn't, it would remove the joy. Though I don't know why.
I just checked the website, and apparently it's still a product.
I think I'm very typical in iPhone terms: I picked mine based on screen diagonal. I don't have a clue what depth it is, and as long as it's within ordinary bounds I really don't care.
I had and very much liked a Retina MacBook back in its day but at that scale there was a substantial difference in heft. Even now between the Pro and the Air. I don't think the difference between an ordinary phone and the iPhone Air would even register.
There was an attempt to merge in 2018 but thanks for reminding us of how bad it could have been.
Qualcomm isn't Broadcom and it isn't Oracle. The only mild controversy I could find following a Qualcomm acquisition was the case with ARM as to whether acquiring Nuvia caused its ARM licences to transfer to Qualcomm. Not exactly the liquidate-all-value stuff of Broadcom.
It's unclear who and what you think you're responding to with that comment. But if it helps for clarity: whether signing requires a developer ID or not is unlikely to be a factor in why people are reacting negatively to your posts, which was briefly where the conversational goalposts were a couple of posts ago.
Enjoy whatever tangent you're on now; good luck to anybody who responds and expects coherence.
I'm not a mindreader so I can but posit reasons you got downvoted. But, obviously, splitting hairs would be one of them. Do you agree with MachDiamond's assertion that "Lots of small developers have a hard time navigating Apple's red tape so it requires manually authorizing installs. " or not?
As a secondary guess at the reason, the text you quoted said (emphasis added):
> Beginning in macOS 10.15 [Catalina], all software built after June 1, 2019, and distributed with Developer ID must be notarized.
You said:
> If you don't [upload your bundle to Apple for notarization], you can't distribute it at all.
Those are not equivalent statements. Your claim may very well be true but it isn't supported by the quotation given.
> You've been required to upload your bundle to Apple for notarization for a very long time.
You seem to be challenging my assertion that signing for direct distribution involves no red tape. Can you explain what red tape you think exists?
A quick check of my GitHub history shows that I've signed my application for direct distribution something like 15 times in the last year and a half. There is no review process. Apple has not checked my application for content or purpose. There are no criteria that I have to meet.
The only obstacle is the developer fee. Which I'm not that bothered about. But here's a fun fact: preferences are not objective.
> Lots of small developers have a hard time navigating Apple's red tape
I don't think that's the issue; for the Mac signed apps are most-commonly signed locally and then distributed directly. The Mac App Store is the thing where you're navigating Apple's opaque acceptability criteria of the week, and that's not all that popular.
I think the issue is more the annual developer fee that is required to obtain a certificate from Apple.
> Remind me who was saying in 2020 that they 'would never take the Trump vaccine'?
Nobody whatsoever.
Though in a world where the majority still think Trump actually said to inject bleach into your veins*, I can understand why you might think there's some nonsense about.
* he sort-of implied it, then clarified that it's definitely not what he meant when answering the immediate follow-up question.
The power of competition, I guess?
Windows 95 must have felt far from a sure-fire thing when development began: it provides a bridge towards a modern OS while retaining full backward compatibility — including support for devices with only DOS drivers — without incurring anything beyond a regular generational speed penalty, despite the underlying hardware being all over the map. And that's against IBM which already has a full modern OS on the market for the same hardware, without the legacy baggage.
Modern Windows development must feel like a walk in the park.
Speaking as a member of the habitually lazy, it's only faster to swap SIM cards if you already have an additional SIM card.
We landed in Buenos Aires mid-afternoon on a Saturday a few years ago, and missed the local phone shop by a few hours. It, and all the others, were additionally shut on Sunday. So no SIM cards until the Monday. Though they did at least work immediately, unlike the ones we bought on a different trip, to Milan; for whatever reason the network (probably Vodafone, but I could be misremembering that) took something like 10 hours to activate them.
I'm sure that organised people order these things in advance for delivery direct to their house but for people like me the availability of eSIMs is a boon.
*sigh* for the sad little anti-Microsoft troll, https://lunduke.locals.com/post/4037306/myth-windows-3-1-was-just-a-shell-on-top-of-dos is just one of many statements of reality available to anyone will the intellectual capacity honestly to enquire. Amongst other things:
> Win386 ran individual "V8086" processes -- which was a key feature of the Intel 386 processor running in Protected Mode -- in a completely preemptive multitasking way.
> This is key: All DOS applications ran as independent "V8086'' processes.
> Which means that, if you were running DOS software under Windows 3.1... every single DOS application was preemptively multitasked.
Windows 95 used concurrent multitasking for all win32 apps.
Windows 3.x used concurrent multitasking for DOS apps if you had a 386 or better.
You're thinking of native Windows applications; these were cooperatively multitasked prior to Windows 95.
But at least, unlike Mac OS, they were designed to be from day one. Prior to the MultiFinder Mac OS was explicitly single-tasking (desk accessories aside, which had specialised constraints).
You mean never rewrote any part of DOS from scratch? I disagree.
Microsoft rewrote the filing system interface and underlying implementation from scratch for DOS 2, modelling it on UNIX-style file streams in order opaquely to support directories, multiple users, network drives, and any other novel filing systems that might become relevant.
This replaced the file-control block interface of CP/M and DOS 1, in which the storage for any given file's state has to fit within a fixed-size blob owned by the calling application. This was a substantial internal change relative to the limited total amount of functionality that DOS implements; it's less true to call it just a filing system dressed up as an OS than it is with CP/M but, well...
There was also the abandoned multitasking DOS 4, a few years before Windows 3.x became the Microsoft thing that can multitask DOS applications. That made it out briefly, so the rewriting must have happened.
There are 1,000 things you could use to argue that the 68000 is the better processor, so for the sake of being devil's advocate I'll just point out:
* the 8086's asynchronous bus unit does a better job at prefetching than the 68000's microcoded slots; the 8086 therefore does a better job of bus saturation; and
* later, after the heyday of the ST and the Amiga and all the other 68000 excellence, the fact that x86 instructions have at most one indirect operand massively simplified the handling of exceptions. x86 instructions don't have to be restartable, they can all always just start again from the beginning if an exception was caught and handled the last time around. The 68ks jump through a lot more hoops here.
Though obviously the ARM2 is the really smart way to spend about the same transistor budget as the 8086, albeit with an additional seven years of microcomputer hindsight. Spend the transistors on registers, hence make indirect accesses few and far between, hence use page-mode accesses almost all the time.
In Apple v Franklin the court found that according to existing principles of copyright, it was infringement to copy ROMs if the code they contain amounts to the expression of an idea rather than the idea itself, in particular being interested in whether the code contained is the only way to achieve an idea or whether it's one that was selected from a range of possibilities.
So, sticking with an example machine already raised, the composite colour ROM in an Oric — essentially a PCM sampling of the composite pattern that should be produced based on the TTL RGB colour — probably isn't copyrighted under that test. But the BASIC ROM is (modulo that it might itself be an unlicensed copy of Microsoft BASIC, though I'm not sure whether that's apocryphal).
I'm honestly unclear on what basis you think that decision was flawed, or really anything other than inevitable. If you don't like the concept of copyright then fair enough, agree to disagree, but it's an odd case to focus your ire on.
If someone's motivation were more anti-Apple then they should probably even celebrate it: between that ruling and the complete lack of any meaningful order or separation of concerns in Wozniak's coding it more or less strangled the Apple II clone industry in its cot and thereby cemented the IBM PC as the thing that grew into a commodity. IBM's lawyers were just as keen as Apple's but the PC BIOS has a clean and well-documented interface as far as it goes.
Probably the worst case of all time was the original iPad; the iPad 2 doubled the RAM and added a second processor core, so not only did official iOS support end only about two years after the original had launched, you'd ideally probably have stopped updating at least a version before that as iOS 5 on it is a chore.
That said, Apple generally does excellently. My iPhone 6s remained perfectly usable for a solid eight years and its replacement iPhone 13 Mini is still going strong four years after the fact. Fifteen years on from that iPad experience, the general maturity of these devices is really obvious.
> Why would a software maker do that?
I have been resident in the US for years but am from the UK originally. I therefore have bank accounts in both countries, and am offered banking apps in both countries.
... except I'm not, because half the software makers tick the little box that limits their banking app to a single country, and Apple allows neither accounts that nominate multiple countries of residency nor multiple accounts to be active on a device at once. So — because banking apps like to impose their own staleness checks — I routinely have to log out of one account, sit through a lengthy process of ditching local copies of that set of iCloud content (photos and music, mainly), log into the other, update apps, then do the same in the other direction.
And, of course, it's not just banking apps. The application that is the only way to get alerts on my local public transit other than signing up to X, is also not permitted to be downloaded by anybody with any other country of residency nominated in their Apple account. That's just across the river from New York, where obviously nobody who isn't originally American lives.
So I'm off on a tangent here, but if we're asking "why would a software maker do that?" then I'd very much like to tag that on to the list. Were they worried that the people of Birmingham might be too interested in the daily train delays of New Jersey? Was there a massive influx of people downloading applications for foreign banks and wondering why they couldn't log in?
> Making use of an out-of-bounds write doesn't sound especially sophisticated to me,
It's very rare that attacks rely upon only a single exploit. The out-of-bounds write may have been used by a sophisticated attack but that does not mean the sophisticated attack used only the out-of-bounds write.
Though with the lack of fuller disclosure by Apple, who knows?
> There's no home, end, pgup or pgdown,
Just on this one thing, in case it improves anybody's day: command+left acts like Windows' home; command+right end; func+up is page up; func+down is page down. So you can do all those things without moving your hand away from the main keyboard.
Standard terminal shortcuts also work in all native text boxes, so control+a goes to the start of the line, control+e goes to the end, control+k removes text from the cursor to the end of the line, control+u removes text from the cursor to the start of the line, etc, etc. It's very common to use the built-in option to remap caps lock as control for such purposes.
The 65816 is always my personal kicking boy for worst "16-bit" processor: only available with an 8-bit bus, no prefetch or cache and retaining many of the redundant bus accesses of the 6502 even long after RAM speed had unambiguously become the bottleneck, arguably an even worse take on segmented addressing than Intel, and weird modal operation that lets you chose whether you currently want to be doing 16-bit or 8-bit operations but not cleanly to mix them. Along with unduly arcane rules on if and when calculated addresses wrap to page boundaries, mostly to do with maintaining 6502 compatibility in emulation mode but spilling out beyond there.
The 80286 inherits the segmented-memory problems of the 8086 but isn't terrible in other regards; primarily: it's extremely bus efficient, and pretty cheap in execution terms too.
On bus efficiency: like the 8086 before it, the 80286 uses separate bus and execution units, with the bus unit opportunistically filling a comparatively large prefetch queue. Compare and contrast with the pre-cache 68k approach in which the prefetch queue is very short and is fed explicitly by incorporation of appropriate microcode steps in the execution unit. So e.g. if the processor is doing a long operation such as a multiply then on the uncached 68ks the bus sits fairly idle whereas the x86s use the opportunity to fetch a few instructions ahead.
On execution times: it's reputedly twice as efficient per clock as the 8086, which was already perfectly mediocre.
16-bit protected mode is indeed a complete misfire though. It was eventually used by Windows 3.x to expose the full 16mb an 80286 can address to programs but its problems are manifold. As you say, Intel didn't think anybody would ever want to exit protected mode, making it a bad fit for DOS and therefore as an upgrade path for the majority of PC software. But it's also that by redefining segment registers as selectors into descriptor tables it also takes away the ability to do segment arithmetic, severely hampering work with blobs of data larger than 64kb.
So: bad instruction set, good implementation. But I guess x86 was always thus. So I'm probably adding nothing.
I can confirm that they are good stuff. Having used the same author's 8088 test suite in the past I also found them easy to integrate (modulo having broken my own testing code in the interim).
For various reasons I'm unable to be unbiased about it but I'm a big fan of test sets like this for unlocking emulator development in almost any order the author wishes because each single test case tests just the one thing, and for very quickly isolating whatever the failures are because there are large swathes of them for each instruction and the test failure occurs immediately after the error.
Big applause to Daniel!
I had the following issues with late-era Nokia phones — i.e. once Androids and iPhones were also in contention:
* far too many contextual dialogues, with menus branching into menus;
* a small number (three?) of fixed levels of zoom in the browser; and
* very poorly grafted-on touchscreen controls.
On the final point I'm primarily thinking of my experience with an N8; some text screens were direct-manipulation push to scroll but some still involved trying to poke at a scroll bar. The direct-manipulation screens would sometimes have momentum, sometimes not. Some programs were able to adapt to having a virtual keyboard appear, some weren't, creating an odd experience where you'd tap on a text box then be taken to a completely context-free screen with a virtual keyboard and a text box to type your content, then hit submit to return to the original screen and have that input inserted.
And this is all using the out-of-the-box software. To their credit it seemed like they'd tried to optimise for the main user flows, e.g. the scroll bar text screens were mainly things like buried legal notices, but it overall felt like a rush job.
I don't recall whether they were still substituting that one Nokia font for everything on a web page.
My memory might easily be adrift, of course, but I seem to remember that Android was well over its initial touchscreen pains by then and still doing unique usability things like the scroll ball on the Nexus One, because being able to place a cursor accurately still mattered to the people that get to make these decisions.
> Although you could, if you wanted, spend (by the standards of the time) what seemed like terrifyingly large amounts on some of the really high-end devices
Or indeed spend a genuinely terrifyingly large amount just using Symbian — I had a 6600 from 2004 and at the time O2 was charging something like £20 for 250mb of contract data. Suffice to say, other than installing applications I'd downloaded at home and transferred by infrared, it rarely got used as anything more than a feature phone.
Or do it DOGE-style: fire the employees, desperately rehire 50% of them at substantially increased salaries, contract out for most of the rest at some other multiple of the salaried rate and let somebody in the future deal with the reductions in effectiveness and cost efficiency. That'll show those liberals!
Digressive, but: Apple has eliminated all plastic wrapping from its products in the last few years in favour of glued-on cardboard seals and tear strips for opening.
... but nobody seems to have told the counterfeiters, who still seem to be shrink-wrapping despite otherwise often doing an excellent job on box reproductions. At least that's per my observations strolling through Manhattan most days, where people throwing down a rug and trying to sell knock-off handbags and electronics is a surprisingly-common sight.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
