AppKit:
NSSavePanelOverRetainToCompensateForAdobe
NSShouldWorkAroundBadAdobeReleaseBug
Adobe Invener Fusion opted out due to odd event processing
com.adobe.Reader
com.adobe.Acrobat
com.adobe.Acrobat.Pro
_allocWithZone:.do_adobe_hack
My DAV server has hacks for Microsoft bugs and misfeatures, hacks for older Apple clients, hacks for Konqueror of all things, because I tested against it.
And our current CalDAV code has just inherited two new hacks this week to work around weird bugs in shit that Google Calendar has been serving up:
* years with only two digits or two leading zeros rather than 20xx.
* unquoted TZNAMEs with :s in them.
At least events from year "0012" are allegedly legitimate parsable ISO8601 times, and the events from year "12" are at least legitimate VCALENDAR. The broken TZNAMES parse legitimately, but
DTSTART;TZNAME=GMT+10:00:20120101T01010101 needs to be fixed up pre-parse.
Welcome to interoperability, where liberal in what you accept is the only choice when your communication partner is much bigger.
> The Radicale Server does not and will not support the CalDAV and CardDAV standards. It supports the CalDAV and CardDAV implementations of different clients (Lightning, Evolution, Android, iPhone, iCal, and more).
Contributing to devguide.calconnect.org on the other hand, helps everybody.
I was actually astonished that connectathons are still running; I haven't been to one in decades: http://www.connectathon.info
This would be perfect to re-add Win16 support to W10, for example. Try to double-click a 16-bit app? It opens with its handler, "Windows 3.1 Hyper-V Association Background Launcher". As long as no W3.1 apps are running, it unloads, and the rest of the OS can be completely free of 3.1-era cruft.
You could deprecate features from your latest OS at a breakneck pace if you really took this strategy to heart. WinRT really could have been just Metro/UWP + a "Desktop" that's actually a Windows 7 VM with a high-level paravirtualized shared filesystem.
(And it's not like Microsoft didn't do this themselves before; this is essentially how DOS applications ran under Windows 3.1, in a [hypervised!] DOS VM.)
---
EDIT: let me clarify the specific point I was getting at.
If you ship $OldOS as a VM within $NewOS, very tightly sandboxed, then you never have to update $OldOS again, nor do you have to keep the code from $OldOS around in $NewOS. The $OldOS VM is now a "static artifact"—something that will never change, but will continue to run old software perfectly.
So, if $OldOS gains more security flaws, you don't update $OldOS; you update the virtualization software to make the sandbox stricter.
And when you find that your $NewOS is now, itself, old—well, you just do the whole thing again, writing an emulator for $NewOS within $EvenNewerOS, and then your $OldOS programs run by launching a VM-in-a-VM. If you like, you can port the $OldOS emulator to run on $EvenNewerOS—but you could also just consider it legacy software of exactly the type your $NewOS emulator is built to run.
The point of this is to decrease maintenance burden, by freezing the previous OS, so that you never need to think of it again. This wasn't what was done with "XP Mode"; Windows XP continued to receive updates as a component of Windows 7. The point here would be to EOL the older OS, and then virtualize it.
You could even hold down the Commodore key while booting to get a mode compatible with the previous system.
Once a install base has been built up, compatibility (or lack there of) can make or break you.
[0] : https://en.wikipedia.org/wiki/Mac_68k_emulator
[1] : https://en.wikipedia.org/wiki/Rosetta_(software)
[2] : https://en.wikipedia.org/wiki/List_of_macOS_components#Class...
My point was less about compatibility, and more about security. If you took this approach, old software would still expose the new OS it was virtualized atop of, to its old security flaws. So you'd still have to move away from old software, eventually, for security reasons.
But with proper VM isolation (and checkpointing, and a few other things), you could still have programs like IE6 around today, serving in its last purpose as the '90s-era Intranet web-services equivalent to the '80s 3270 mainframe terminal clients.
Most any modern VM software can offer this level of isolation, but most have "host integrations" that turn them back into security holes. To be able to ship a static, EOLed copy of XP that could run IE6 indefinitely, without that causing problems, your compatibility layer would need to be a lot less like "Windows XP Mode" or Rosetta, and a lot more like DOSBox or qemu.
There is one case where this already happens: many pieces of IBM z/OS software have been wrapped in layers of hard-isolated emulators for decades now, such that programs from the 70s are able to continue running without recompilation, atop a stack of VMs, where many of the intermediary pieces of VM software have themselves long been EOLed.
https://technet.microsoft.com/en-us/library/ee681616(v=ws.10...
While the virtual environment integrated somewhat with the base (eg audio, printers, some networking shares and hard drives), it still is a separate window running a separate virtualized OS. I'm not sure I would call that too tightly integrated.
Nonetheless I personally found it handy nonetheless to run the occasional very old 16-bit application.
I think Raymond Chen discussed this on this blog at one point. The answer is that users want a single integrated environment for all their apps and not a bunch of isolated sandboxes. They want to drag and drop, copy and paste, share files, inter-application communication, etc. They also want a single look and feel.
The other reason is that creating a new platform from scratch is a good way to lose features and alienate developers. The core of Windows NT doesn't look anything like Windows 3.1 but for developers the API they present is similar enough to get them on board.
MS tried to rewrite and get compatibility by using these sorts of features. It was looked at by the PMs and dismissed because it was completely broken.
Turns out most hacks are in the software for a reason. They actually solve a problem that needs solving. Who knew ?
https://www.microsoft.com/en-us/research/project/drawbridge/
There is no reason to ditch the backwards compatibility in my opinion. All components can be kept functional alongside each other (like how UWA can function next to Win32) with some extra effort. I love the fact that there's a host of applications that target Win32 that I've been using since windows 2000 and still work on windows 10.
Can't find it now but someone posted a Linux mailing list where Torvalds ripped a Dev for breaking something that impacted a user. The dev responded something like the parent: It's a 3rd party app/not Linux responsibility.
The OS has to be stable and the users experience is Paramount. Even a technical crowd (based on the thread) is 50/50 split on this being a Microsoft issue. A non-technical users response: "this software is shit, these idiots broke X in [this version] Microsoft sucks"
Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messages? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)
...
This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95. (Games were the worst. Often the game vendor didn't even care that their program didn't run on Windows 95!)
Even better was Windows (Live) Photo Gallery. Sadly it's dead since Feb 2017, you can't even install it anymore, as only a now broken WebInstaller exists. Photo Gallery was hand down 1000 times better than Picasa/Lightroom/Photos/iPhotos for just browsing photos and videos. And it alo supported tags with hierarchy (eg "City/New York/Manhattan").
https://en.wikipedia.org/wiki/Windows_Photo_Gallery
Sadly WinFS failed, metadata is nowadays often misunderstood and persived by companies contra productive in the age of cloud service strategies. Flickr is probably the only well known photo service tht keeps metadata. Facebook made it popular to strip metadata and keep annotations internally (as vendor lockin) - now common also with other services.
I hope there will be a kind of come back of metadata. People need more education to understand the concept, that's all.
It's cruft when those assets are now embedded into your compiled, bundled, distributed software and such metadata now has no purpose whatsoever, as is the case for the examples cited in the article.
This sounds like a challenge. You're on.
- Do some scratching around; discover sites hosting "wlsetup-all.exe"
- Point the Web Archive at download.live.com
- After some trial and error with broken pages find http://web.archive.org/web/20161130174327/https://support.mi...
- Follow the "Download options" link
- Eventually land on http://web.archive.org/web/20161226002912/https://support.mi..., and disable JavaScript so the page doesn't kill itself (remember on Chrome you just click the (i) to the left of the URL)
- Ah, a "Download Now" link!
$ curl -vv http://go.microsoft.com/fwlink/?LinkID=255475
Location: http://g.live.com/1rewlive5-web/en/wlsetup-web.exe
$ curl -vv http://g.live.com/1rewlive5-web/en/wlsetup-web.exe
Location: http://wl.dlservice.microsoft.com/download/C/1/B/C1BA42D6-6A50-4A4A-90E5-FA9347E9360C/en/wlsetup-web.exe
(note s/web/all/g)
$ curl -vv http://g.live.com/1rewlive5-all/en/wlsetup-all.exe
Location: http://wl.dlservice.microsoft.com/download/C/1/B/C1BA42D6-6A50-4A4A-90E5-FA9347E9360C/en/wlsetup-all.exe
$ curl -vv http://wl.dlservice.microsoft.com/download/C/1/B/C1BA42D6-6A50-4A4A-90E5-FA9347E9360C/en/wlsetup-all.exe
< HTTP/1.1 404 Not Found
(...)
<div id="header"><h1>Server Error</h1></div>
(...)
<h2>404 - File or directory not found.</h2>
<h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3>
- Try and load wl.dlservice.microsoft.com/robots.txt in the Web Archive
- Get redirected to Microsoft homepage!!
- Lookup wl.dlservice.microsoft.com/* in Web Archive
- "805 URLs have been captured for this domain."
- Search for "c1ba..." - get hits!
http://web.archive.org/web/20170416220642/http://wl.dlservic...
137329840 bytes.
There are other sites that have copies of the file, but a) this one is from the Web Archive and b) I've verified using a mixture of WA and still-live Microsoft redirects that this is the latest-ever release.
I previously copy&pasted the folder to another PC, and manually patched the registry and copied some dlls to get it working.
Slightly OT: is there any good photo organizer for windows? I would be happy with sth at the level of shotwell even https://wiki.gnome.org/Apps/Shotwell
Photo Gallery supports video too, and is s lot easier to use and has s polished UI and stable path-like-metadata support. DigiKam can read such metadata tags, even edit them but adding new ones is buggy (path like City/New York/Manhattan are then stored as three separate tags City, New York, Manhattan).
It isn't talking about the metadata columns for files.
I wrote about the metadata handling in Explorer/shell32. It's a light version of what was tried out with WinFS.
The metadata that the author finds is actually inside resources inside the executable itself. It does not include any strings found in the executable which are used to parse the metadata from other files that you have on disk.
I'm not saying metadata is cruft. Metadata is very useful during production or for managing art assets. It is however superfluous once it is embedded in an executable or other code library or packed archive. This is simply because its purpose has already been served and it is no longer needed at that point, thus wasting space.
This is kind of OT, but F-Spot on Linux supported hierarchical tags, as well, and I loved it. Was really sad when it was discontinued and distros replaced it with Shotwell.
(Almost?) all other other major vendors at the time used it heavily too: Microsoft Office until 2011, FileMaker until 2010.
If Apple released the OS a year earlier, but without any available third-party software (waiting for almost-rewrites to happen), would they really have been better off? At this time they were on life support and would have had difficulty convincing third-party vendors to invest heavily in their platform, or to convince users to adopt it without any major applications available.
In either case, Adobe's sway clearly declined over the years, as Apple cancelled the 64bit version of Carbon while Adobe was still heavily built around it, forcing Adobe to switch (and an awkward year or two when the Mac, but not Windows, versions were stuck with 32bit memory limitations)
Apple wrote the Finder in Carbon as a dogfooding exercise, to prove to third party developers that Carbon was a first-class fully supported framework. The Finder has since been re-written in Cocoa.
iTunes needed to support both Mac OS 9 and X, so Carbon made much more sense than writing all of the UI code twice. Also, it started as SoundJam MP, which was written for Mac OS 8, so Carbonization was much less work than a Cocoa rewrite.
It's like a co-worker said, "Adobe's software is bloated and cumbersome, but they have a top notch marketing team that keeps it afloat." But yes, if there is a company that is ripe to have some serious competitors it would be Adobe.
MS have no one to blame except themself and their 'legacy code'.
Blame the customers. Microsoft never would have captured the marketshare they have if they didn't cater to them.
But most of the real nightmare scenarios I've heard related to backwards compatibility have more to do with third-parties doing things they were never supposed to do.
Things like hitting private, undocumented APIs. Or checking the Windows version with a "9x" wildcard, giving us the jump from W8 to W10 over a decade later.
Microsoft has made their own mistakes, but supporting the mistakes of third parties has been absolutely vital to them keeping their core customer base.
I don't personally believe the "Windows 9" story - if a program is old enough to feel the need to check for Windows 95/98 then it should already be fine to run under Windows' own app-compat layer which spoofs the Windows version string anyway. I believe it's marketing-based out of fear consumers would see "MacOS 10 vs Windows 9" (like how it was PlayStation 3 vs Xbox 2 - hence "Xbox 360").
In any case, your reasoning doesn't really make sense. I can run a program that was written for Windows XP on Windows 10 without the need from a app-compat layer. Given that a developer can hide/show all sorts of random functionality with an if-branch-on-version - the user will see a broken or strange app and it won't be clear (and MS probably didn't have the means to detect) that the app should run in compatibility mode.
I still believe that MS wanted to ship an OS that "just worked" and did so under 10, than trying to compete in version numbers with an OS that has had 10 in its name for last 18 years.
X means 10 in latin.
Look at old MacOS X 10.3 books, X always stood for 10.
I could understand the confusion.
This is just a rumor made up on reddit. It's completely false. Windows returns its version number as a series of integers. And even if it was a string, they could've just called it "Windows Nine".
That's entirely Microsoft's fault too: they made internal APIs accessible to applications, and did not provide comprehensive documentation on the full features of their public API.
The latter means that application developers were forced to just guess what a function could do. And since no API performs proper input validation, undocumented usage became the norm.
Public APIs are documented, guaranteed to work like documented (otherwise it's a bug and will be fixed) and intended for others to call. Internal APIs are none of these things. They are not documented because they're not supposed to be called. Anything not documented in an API it (to me at last) something that's not guaranteed to remain like that. Whether it's a complete function or just a side-effect of something that is public.
They did, in Windows 8. It is called Metro/Modern/UWP. Everyone hates it.