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.
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.
It isn't talking about the metadata columns for files.
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
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.
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)
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.
Total bytes wasted: 5341278
[1] https://gist.githubusercontent.com/riverar/f4a56b91580af1bd3...
Bloat arises from a lot of different places, a lot of which cannot realistically be controlled without drastically affecting user expectations, system performance, and how software is developed.
Consider graphics. If you are quadrupling the color depth, you are quadrupling the amount of memory required for graphics resources. Even more fun, if you are doubling the resolution you are quadrupling the amount of memory required for graphics resources. Going back to the olden days would only be an option if they are willing to compromise on the quality of the graphics.
At the other end of the spectrum are developers. Should they really be choosing things like the type of an integer to reduce the size of code and data? Old software was often limited due to such considerations. In some cases software used bizarre tricks to reduce bloat, such as cramming data into the unused bits of an address. (Apparently that was common on 68000 based personal computers.)
Don't get me wrong, there is a lot of unnecessarily bloated software. Yet I suspect that the vast majority of that bloat exists for very good reasons.
I suspect a lot of this bloat is due to the current and IMHO horrible trend of "every UI element is a separate bitmap image", even if the image is trivial to generate procedurally; consider gradients, for example --- they're easily described by an equation that may take no more than a few dozen bytes of code, yet developers seem to think it requires storing a multi-MB PNG image, maybe even in multiple resolutions (smartphone apps are a particularly notable example of this).
The irony is that this wasteful technique is often combined with the "flat" UI trend, which would be even easier to generate procedurally, so we've arrived at UIs which are less featureful and yet more bloated.
While Windows may suffer from unnecessary bloat, this article is not a very good evidence in that direction. Windows itself is much (much) more than a 4.5 MB binary and the growth of Windows over the years likely has more to do with changes in technology and the market than anything else.
I also doubt that this is an indicator of sloppy software development, nor is this basic stuff. It simply indicates that the resources were added to the executable file more-or-less as is. Developers are unlikely to be concerned with the structure of the resources as long as those resources are in a format that is well understood by the software. Graphics designers are unlikely to be concerned with how the embedded data bloats the size of the executable. While stripping the excess data may seem like a basic good practice in retrospect, it is not basic nor is it sloppy in the sense that it doesn't strictly fall in the domain of the two groups responsible for handling the data.
"We didn't have time to do it right."
And yet they always have time to do it over.
I wouldn't say it was very common, but there are some notable examples, such as Amiga BASIC which was incidentally written by Microsoft. As a result it needed a patch to run on machines with the bigger M68k CPUs (which had 32 address lines vs. 24 address lines on the 68000), but it was so awful it died a swift death in any case.
I understand why they kitchen-sink operating systems - its mainly so they can crow about new features when releasing new versions of the OS. But I wish they would offer alternate installs for those of us who are proficient.
I would bet that case was a contractor who was using their own equipment. Similar things have bit us in the ass with freelancers that have ripped off stock images and presented them as their own.
Example: He cites effects on startup time - but has he considered the existence of virtual memory? When explorer.exe loads and maps the bloat into address space, it doesn't need it in RAM until the first page fault accessing it which likely will not even happen.
In the happy case, yes, virtual memory will save us. But there are a lot of ways we could still end up loading the junk into ram.
Also, there are potential runtime costs to it being larger just on disk (need to seek over it, etc).
How many applications on Mac OS utilize PNG assets which were exported from Photoshop without any further optimization?
Example pulled at random:
D:\analysis\Windows\WinSxS\amd64_microsoft-windows
-imageres_31bf3856ad364e35_10.0.15063.0_none_edd17c6c30b4bf9f\imageres.dll
...
- Total: 4435
D:\analysis\Windows\System32\imageres.dll
...
- Total: 4435
cmd> fsutil hardlink list \Windows\System32\imageres.dll
Windows\WinSxS\amd64_microsoft-windows-imageres_31bf3856ad364e35_6.3.9600.16384_
none_cd7c033dcbdd0cab\imageres.dll
Windows\System32\imageres.dllThere's still a lot of size growth over time, of course.
And in a perfect world the external PNG content would also be verified.
There is also a Windows system integrity checker service which disallows changes to protected Windows files, and repairs them automatically (using a cached copy).
And to repeat it over and over — it's like a boot stomping on disk space, forever.
I remember that certain XML tags had to use the exact namespace defined in the Adobe spec, but other than that it all seemed pretty XML compliant.
I was using Python / ElementTree, and had to override the namespaces to make sure the exact name was being used. Or something.
https://docs.python.org/2/library/xml.etree.elementtree.html...
What other problems did you encounter regarding XML compatibility?
I wonder how easy it actually is to remove this XMP metadata, considering that it could potentially break some application which loads a PNG directly from explorer.exe with a broken PNG parser or something.
<?xpacket begin="?" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.4-c002 1.000000, 0000/00/00-00:00:00 ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:xmp="http://ns.adobe.com/xap/1.0/">
<xmp:CreatorTool>Picasa</xmp:CreatorTool>
</rdf:Description>
<rdf:Description rdf:about=""
xmlns:mwg-rs="http://www.metadataworkinggroup.com/schemas/regions/"
xmlns:stDim="http://ns.adobe.com/xap/1.0/sType/Dimensions#"
xmlns:stArea="http://ns.adobe.com/xmp/sType/Area#">
<mwg-rs:Regions rdf:parseType="Resource">
<mwg-rs:AppliedToDimensions rdf:parseType="Resource">
<stDim:w>912</stDim:w>
<stDim:h>687</stDim:h>
<stDim:unit>pixel</stDim:unit>
</mwg-rs:AppliedToDimensions>
<mwg-rs:RegionList>
<rdf:Bag>
<rdf:li rdf:parseType="Resource">
<mwg-rs:Type></mwg-rs:Type>
<mwg-rs:Area rdf:parseType="Resource">
<stArea:x>0.680921052631579</stArea:x>
<stArea:y>0.3537117903930131</stArea:y>
<stArea:h>0.4264919941775837</stArea:h>
<stArea:w>0.32127192982456143</stArea:w>
<stArea:unit>normalized</stArea:unit>
</mwg-rs:Area>
</rdf:li>
</rdf:Bag>
</mwg-rs:RegionList>
</mwg-rs:Regions>
</rdf:Description>
<rdf:Description rdf:about=""
xmlns:exif="http://ns.adobe.com/exif/1.0/">
<exif:PixelXDimension>912</exif:PixelXDimension>
<exif:PixelYDimension>687</exif:PixelYDimension>
<exif:ExifVersion>0220</exif:ExifVersion>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<!-- whitespace padding -->
<?xpacket end="w"?>
(*TOP* (*PI* |xpacket| "begin=\"?\" id=\"W5M0MpCehiHzreSzNTczkc9d\"")
(|adobe:ns:meta/:xmpmeta|
(@ (@ (*NAMESPACES* (|adobe:ns:meta/| "adobe:ns:meta/" . |x|)))
(|adobe:ns:meta/:xmptk|
"Adobe XMP Core 5.4-c002 1.000000, 0000/00/00-00:00:00 "))
"
"
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:RDF|
(@
(@
(*NAMESPACES*
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#|
"http://www.w3.org/1999/02/22-rdf-syntax-ns#" . |rdf|))))
"
"
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:Description|
(@
(@
(*NAMESPACES*
(|http://ns.adobe.com/xap/1.0/| "http://ns.adobe.com/xap/1.0/"
. |xmp|)))
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:about| ""))
"
"
(|http://ns.adobe.com/xap/1.0/:CreatorTool| "Picasa") "
")
"
"
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:Description|
(@
(@
(*NAMESPACES*
(|http://ns.adobe.com/xmp/sType/Area#|
"http://ns.adobe.com/xmp/sType/Area#" . |stArea|)
(|http://ns.adobe.com/xap/1.0/sType/Dimensions#|
"http://ns.adobe.com/xap/1.0/sType/Dimensions#" . |stDim|)
(|http://www.metadataworkinggroup.com/schemas/regions/|
"http://www.metadataworkinggroup.com/schemas/regions/" . |mwg-rs|)))
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:about| ""))
"
"
(|http://www.metadataworkinggroup.com/schemas/regions/:Regions|
(@ (|http://www.w3.org/1999/02/22-rdf-syntax-ns#:parseType| "Resource")) "
"
(|http://www.metadataworkinggroup.com/schemas/regions/:AppliedToDimensions|
(@ (|http://www.w3.org/1999/02/22-rdf-syntax-ns#:parseType| "Resource")) "
"
(|http://ns.adobe.com/xap/1.0/sType/Dimensions#:w| "912") "
"
(|http://ns.adobe.com/xap/1.0/sType/Dimensions#:h| "687") "
"
(|http://ns.adobe.com/xap/1.0/sType/Dimensions#:unit| "pixel") "
")
"
"
(|http://www.metadataworkinggroup.com/schemas/regions/:RegionList| "
"
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:Bag| "
"
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:li|
(@
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:parseType| "Resource"))
"
"
(|http://www.metadataworkinggroup.com/schemas/regions/:Type|) "
"
(|http://www.metadataworkinggroup.com/schemas/regions/:Area|
(@
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:parseType| "Resource"))
"
"
(|http://ns.adobe.com/xmp/sType/Area#:x| "0.680921052631579") "
"
(|http://ns.adobe.com/xmp/sType/Area#:y| "0.3537117903930131") "
"
(|http://ns.adobe.com/xmp/sType/Area#:h| "0.4264919941775837") "
"
(|http://ns.adobe.com/xmp/sType/Area#:w| "0.32127192982456143") "
"
(|http://ns.adobe.com/xmp/sType/Area#:unit| "normalized") "
")
"
")
"
")
"
")
"
")
"
")
"
"
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:Description|
(@
(@
(*NAMESPACES*
(|http://ns.adobe.com/exif/1.0/| "http://ns.adobe.com/exif/1.0/"
. |exif|)))
(|http://www.w3.org/1999/02/22-rdf-syntax-ns#:about| ""))
"
"
(|http://ns.adobe.com/exif/1.0/:PixelXDimension| "912") "
"
(|http://ns.adobe.com/exif/1.0/:PixelYDimension| "687") "
"
(|http://ns.adobe.com/exif/1.0/:ExifVersion| "0220") "
")
"
")
"
")
(*COMMENT* " whitespace padding ") (*PI* |xpacket| "end=\"w\""))
...but given how well DNS-based package names in Java have worked out (i.e. poorly) I'm surprised they went in that direction.
On the bright side - URIs (and so, XML namespaces) don't need to use the http:// scheme - they could easily switch to urn: http://stackoverflow.com/questions/4116282/when-to-use-a-urn...
E.g. that shrinking tunnel under "normalized".
Gee whiz! What a world!