Hacker News new | past | comments | ask | show | jobs | submit login

Apple really needs to stop removing documented APIs. If they want to announce that some APIs have been moved to "maintenance mode", that's fine—just make some effort to ensure said APIs keep working.

When I was deep into Windows development, I remember how crazy it was that MS refused to deprecate APIs.

Just the concept of a “string” when programming on Windows could be different depending on the API Microsoft had:

- standard C strings: a null terminated character array

- the standard 16 bit wide character string that was null terminated.

- a BSTR - a double byte character array where the first byte is the length.

- the C++ STL string class.

- a CString - not to be confused with the C style string. This was part of the Active Template Library

- CStringT - it’s been awhile. I have forgotten what this is.

Keeping APIs forever leads to bloat, is a maintenance nightmare, and increases the surface area for security vulnerabilities.

One of the earliest security vulnerabilities that I remember was that it was easy to run shell commands on a remote computer just by escaping the command in IE if the site was running IIS because MS overlooked a type of string encoding.

https://flylib.com/books/en/2.819.1.43/1/




As a user, however, I think MS has it right.


The worst is COM's apartment threading model, which is still in your face to this day despite being pretty much nothing more than an extremely elaborate workaround for the fact that Visual Basic 6 didn't support threads. (VB6 was released in 1998; it became old enough to drink this year.)


I doubt that VB6 is actually the only justification for COM's apartment threading model. If that were the case, then I don't think WinRT would still have ASTA (application single-threaded apartments). I think the real rationale is that making sure certain code runs on the UI thread is something that applications have to do all the time, even today, even on non-Windows platforms.


If I'm not mistaken, CStringT is just the template class for CString, CStringW, and CStringA. Makes perfect sense :)

My personal favorite is the PCZZWSTR type, which I've only ever seen used by SHFILEOPSTRUCT. Basically it's a null-terminated collection of null-terminated strings. And of course, there's a corresponding PCZZSTR for narrow-char paths.

VC++ is... interesting.


Random thought, could the attack surface be reduced by limiting old APIs to programs running in compatibility mode?

This would basically be a modification of the "least permissions" principle—only expose old APIs to programs old enough to need them.


It’s almost impossible to get developers to move to newer APIs as long as you allow them to use old APIs. Fortunately (?) only two third party developers really matter on Macs - Adobe and Microsoft. The rest either have to come along for the ride or get left behind.

iOS on the other hand is ubiquitous enough and there is no one killer app that people can’t live without, Apple can deprecate and then abandon APIs and pull developers forward.


> It’s almost impossible to get developers to move to newer APIs as long as you allow them to use old APIs.

Even if the old APIs requires the user to manually right click the executable, go into properties, and enable compatibility mode? It's not hard for the user to do, but I wouldn't want it to be my users's first experience with something I made.


When the super-geniuses of Redmond devised WinRT which was supposed to be the savior of it all, they tried to fix this problem with a new string type, HSTRING. It had some additional quirks around NULL that the other types didn't have.


I'd like to think that there's a balance between Apple and Microsoft in this area.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: