edit: Thank you cormacrelf for the explanation re: lib being mandatory. Thank you OP for explaining your rationale.
Considering that, 'spng' is different enough from 'png'.
I would call this library "spng" and the original "png"; once compiled they would be named "libspng" and "libpng".
It's different, but I think it's so close as to verge on namesquatting, especially when the description and purpose is almost identical to the original libpng --- in fact, that's why I clicked, to see what exactly this is about.
I’ve been really distracted lately thinking about what things need named handles in my data models/representations, and what they should be handles for, and how to do so, and how to change them in sane ways. So far all my thinking has just convinced me that I am a mediocre architect.
No thanks.
https://docs.microsoft.com/en-us/windows/win32/com/com-class...
I’m also kinda reminded of aws lambda URLs, or I guess URLs in general.
I worked on a spike once to try and get a modern web browser embedded in a proprietary business basic language who's UI toolkit only exposed some COM/OLE stuff.
It was an unholy abomination of unmaintainable software, but it worked and worked well. It made me think a lot about how things would have looked today if ActiveX managed to keep it's foothold.
The meeting should have gone like this:
Manager: We're going to put COM on the Web!
Engineer: What about this COM function that deletes files?
Manager: We'll blacklist that.
Engineer: Or this one that reboots the PC?
Manager: Blacklist. In fact I'm assigning you the job of making the blacklist.
Engineer: I think there's an unlimited number of problematic features of COM.
Manager: Good point. OK, ActiveX is cancelled. Thanks for your time, good meeting everyone, make sure to implement PKIX correctly so we don't cause more holes there too.
My guess is that a team at Microsoft in the 90s saw the need for a cross-process runtime object system, saw Objective-C and thought to themselves "Hey, this Objective-C is pretty useful but it doesn't suck enough to be part of Win32. Lets fix that - GUIDs, GUIDs for everyone!."
There's an amusing video on youtube where Steve Jobs is demoing remote Objects on NextStep and (I think) Openstep on Windows, and having a laugh at MS since Next managed to get remote Objects working before MS got their Remote OLE (aka DCOM) working. Steve calls it Doh'LE.
The only different thing that COM had was support for scripting the objects via IDispatch, but that was such a pain (VARIANTS !) that only those really needing it bothered.
MS were also very proud of their MTS where an on the fly proxy object was created, but even that was inspired by Remote objects.
However they really jumped the shark when they made it possible to create COM objects from Visual Basic - the endless grief caused whenever a VB developer decided to change any parameters on the interface and caused all GUIDs to be regenerated and a big fat binary with all revisions of the code. They then created a tool to strip that all down to just the last version, thereby totally removing any backward compatibility - which then caused other random components to fail.
GUID were already part of DCE/RPC and Taligent.
And COM IDL is initially based on DCE IDL.
Do you pronounce it as "sping"?