Very nice to see new PalmOS apps being written, and good job on your strategy game.
I co-authored Warfare Incorporated, an RTS originally on Palm devices, if anyone remembers that. We had to pull out all the stops to get the perf and get it small enough to fit.
My favourite PalmOS game! The OS 5 version is well done in that it properly adjusts to any screen resolution, including ones that no device ever shipped with. I often use it to test rePalm builds on new hardware. The OS 4 version was not as well done, so i had to patch it to support Dana widescreen and HE330 HVGA. Patched versions are here: https://palmdb.net/app/warfare-inc
For Dana, it was a simple binary patch. For HE330, a separate hack is needed that I had to write that 'enables Warfare'. Thus I called it "Kissinger"
The article suggests json patch is idempotent, but it isn’t idempotent for array mutations. JSON merge patch on the other hand is fully idempotent (in the array case the array is replaced).
Indeed it does not seem idempotent. If you move A to B and insert a new A, then rerunning the patch would yield the new A at B.
I suppose a subset of this is idempotent though.
Broadly this seems fraught with peril. It sounds like edge case upon edge case, and only would work in the narrow case where you are 100% sure exactly what the remote document looks like such that you can calculate the patch. If anything gets out of sync, or serialization differs between local and remote, etc youre going to get subtle bugs...
Once Microsoft agreed to the graphics api change, it was open season to redesign the window manager api because backward compat was moot at that point. The OS/2 window manager api was designed by the same team who designed the win16 window manager apis. There were improvements and a bunch of api change but at the 10K foot level the model was the same - input loop, window messages, and window procs.
> at the 10K foot level the model was the same - input loop, window messages, and window procs.
That's a fairly broad description, isn't it? At least I have a hard time coming up with windowing API models that don't fundamentally work that way at the lower levels. (About the only exception think of is a text-based library that shipped with Microsoft BASIC 7.0, and that was mainly because the language didn't support any of the abstractions needed for callbacks.)
That's a fair point, I'll restate: the level of abstraction that developers were exposed to was 95% the same. Exposed message loops, window classes, window messages, unpacking window params, post and send message semantics, painting, single cooperative input queue (window app hanging would hang all apps), and other equivalences.
This is an important point. Being easier to create means faster to market, faster to create new features, easier cross platform, more value for users in less time. Not all apps can be web based but for those that can be, faster dev time has become a competitive requirement.
