External data files or hardcoding? Why not both?

Gurth

At the museum I do the odd bit of volunteering for, one of the computers running a touchscreen stopped working. Not too surprising, it was donated something like 15 years ago, probably by someone who got a new computer at the time and decided to give the old one away to a good cause. It ran a kind of interactive presentation showing a map of the local area with changes through the years, allowing visitors to press a year number and see what was constructed in that particular year.

This obviously needs to be put onto a new computer — but how does it even work? It’s the only touchscreen in the museum that still dates from before I involved myself in this, so I have no clue what software it’s actually running. But it was apparently written by “a computer sciences student”, for whatever that may be worth.

Anyway, I pull the hard drive from the computer and hook it up to a new one, so I can hopefully copy over the software and if I’m really lucky, have it work right away. (Incidentally, a quick glance tells me the hard drive is an IBM Deskstar™ of 20.5 GB and 7200 rpm, manufactured APR-2003 — and it has a sticker reading “SERVICEABLE USED PART” on it. The thing makes a very high-pitched noise when it runs, but it does run, so we’re one step in the right direction already.

I find the software in the root of the C: drive … Some Windows executable that, if I double-click it, brings up the interactive thingie, so good, that’s the one I need. Windows calls it some kind of Macromedia Flash app, but I’m not sure exactly anymore because I’ve now got it hooked up to my iMac at home, which just says it’s a Windows EXE file.

Copy it over to the new PC’s hard drive, double-click … and yes, it runs. But it has no year numbers to press, and also no map of the area. However, the buttons for the years are there. Back to the old drive: hey, there is an XML file in the root too — copy that over, restart the EXE on the new machine: yep, we have year numbers now, but no pictures. Oh, there is also a folder titled images lurking between the normal Windows folders you expect in the roof of the C: drive. Copy that too, and yes, it works completely.

Yay!

But … if it needs the XML file to work, why does it show the buttons anyway if that’s not there? What is in that file?

<perioden>
 <periode>
  <naam value="1946"/>
  <afdbeelding value="1946-1947.png"/>
 </periode>
 <periode>
  <naam value="1947"/>
  <afdbeelding value="1946-1947.png"/>
 </periode>
 <periode>
  <naam value="1948"/>
  <afdbeelding value="1946-1947.png"/>
 </periode>

and so on for more years.

periode is Dutch for, hey, period and add an n to the end and it’s plural. naam is name, as I’m sure you've guessed. afdbeelding translates something like picdture — yes, that first d is a typo and shouldn’t be there at all.

So that must mean the Flash code also has that typo in it … Why wouldn’t he have noticed/fixed that? But hang on, it’s probably ignoring the whole afdbeelding node, because all of them, for all the years defined in this file, have the same value. And there is no 1946-1947.png file in the images folder at all — only ones with names 1946.jpg, 1947.jpg etc. Half the nodes in the config file are unnecessary, then.

Except that the screen shows the exact number of buttons needed for all of these years and a few other functions if the whole XML file is totally missing — just with no captions on them …

And an added is that the interactive display shows “zoom” icons on some features, which if tapped, show a corresponding photo from the images folder. All of which must be hardcoded into the program, because there is nothing in the XML file that defines any of these.

But as it works, I guess it will just go back on display soon — I CBA to write my own version of this to be more flexible/configurable, anyway.

BernieTheBernie

@Gurth Butt... what happened during the last 15 years? No more photos added, i.e. the latest history just not available?

e4tmyl33t

If it hasn't been buried in the ground for at least 50 years and then dug up again, it's clearly not history.

/sarcasm

Anonymous Throwaway

I find the software in the root of the C: drive … Some Windows executable that, if I double-click it, brings up the interactive thingie, so good, that’s the one I need. Windows calls it some kind of Macromedia Flash app, but I’m not sure exactly anymore because I’ve now got it hooked up to my iMac at home, which just says it’s a Windows EXE file.

Mac OS can’t read Windows-specific metadata; the only reason it even says it’s a Windows program is because the file name has “.exe” at the end. The “Macromedia Flash” thing is embedded in the file in some way (presumably as part of the file itself, but it could technically be metadata in the filesystem — I don’t know what mechanism is used for this purpose in Windows). The same limitation is true in reverse — if you copy a Mac app to Windows, Windows won’t be able to tell you the version number or copyright string unless they’re in the file name anyway. (Then again, since the Carbon API went obsolete, I’m fairly certain all GUI Mac apps are now required to be “bundles”, which means they appear to be folders if copied to other operating systems, so they wouldn’t have metadata anyway. Stuff like the version number and copyright string are stored in a standardized property list file in a particular location inside the bundle.)

(Macromedia Flash programs are just a Flash file with a generic player app attached to the front, similar to how self-extracting archive files used to work on Classic Mac OS. It is conceivable that you could find a copy of the corresponding version of Flash and open the program up. On the other hand, I think Flash used to obfuscate files which were “published” to self-playing executables, so maybe not.)

uschwarz 0

Ah yes, that looks like a clear case of "we want you to use XML config so we can do that stuff and you don't have to, here's what it needs to look like" and then that never happened, so nobody noticed.

Yup, that's an unsupervised student project alright. I mean, why would you supervise the student, you got them to save time.

Gurth

@BernieTheBernie said in External data files or hardcoding? Why not both?:

@Gurth Butt... what happened during the last 15 years?

It’s stood in the museum doing its thing, basically.

No more photos added, i.e. the latest history just not available?

Nope. It goes to 1957, off the top of my head, because it just covers a specific timeframe. But even then, I would have written it so that everything actually displayed is defined in that XML file so that you can expand it if you want to. Like adding more years like you say, or putting in more photos of places of interest.

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

Mac OS can’t read Windows-specific metadata

I know, I just meant to say that I don’t recall the exact details Windows supplied about the EXE file, and I can’t check them on my Mac. Well, I could have started up a VM

@uschwarz-0 said in External data files or hardcoding? Why not both?:

Ah yes, that looks like a clear case of "we want you to use XML config so we can do that stuff and you don't have to, here's what it needs to look like" and then that never happened, so nobody noticed.

Yup, that's an unsupervised student project alright. I mean, why would you supervise the student, you got them to save time.

I highly doubt there was more specification than, “We want a screen that shows an interactive map of the area, with people being able to tap on years and see the changes. Oh, and that they can tap on some things to see a photo of that thing.” Which the student then decided to do in Flash (it appears to have 2007, based on the file dates, so Flash was still a thing) and for some reason chose to use XML and external image files but not really understanding why that could be actually useful — like for later changes.

BernieTheBernie

@Gurth said in External data files or hardcoding? Why not both?:

So that must mean the Flash code also has that typo in it … Why wouldn’t he have noticed/fixed that?

You stumbled upon the reason why the data written in the XML file are duplicated in the code: because of the typo, the data could not be retrieved from the file, hence the CSS (computer science student) had to add that in the code again.
And there was no need to remove the data from the file then either - just a little dead code, so what?
Never did he find out that he by accident also hit the d when he typed the f.

Gribnit

@Gurth sweet, the student remembered to internationalize the text for the local history kiosk.

Is this located in the Sudetanland?

Bulb

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

Mac OS can’t read Windows-specific metadata; the only reason it even says it’s a Windows program is because the file name has “.exe” at the end.

Can't it? And does it use the extension? Because from MacOS, being based on Unix, I would expect the opposite. That is, I would expect it to recognize it as Windows EXE because it starts with the two characters PE no matter what extension it has, and at least some of the subtypes like whether it is x86, amd64, arm5te or CRL (.нет) one. It just does not bother recognizing these obscure wrappers like flash.

… at least that's what Linux does.

dkf

@Bulb said in External data files or hardcoding? Why not both?:

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

Mac OS can’t read Windows-specific metadata; the only reason it even says it’s a Windows program is because the file name has “.exe” at the end.

Can't it? And does it use the extension? Because from MacOS, being based on Unix, I would expect the opposite. That is, I would expect it to recognize it as Windows EXE because it starts with the two characters PE no matter what extension it has, and at least some of the subtypes like whether it is x86, amd64, arm5te or CRL (.нет) one. It just does not bother recognizing these obscure wrappers like flash.

… at least that's what Linux does.

It depends on how the magic number recogniser has been set up. That often knows how to poke around quite deep inside things and could therefore say what sort of EXE it is... but might be defeated by macOS bundles (as those are directories). I've never checked.

Gurth

@Bulb said in External data files or hardcoding? Why not both?:

Can't it? And does it use the extension? Because from MacOS, being based on Unix, I would expect the opposite.

Don’t forget, though, that macOS frequently handles things like this as part of the Finder rather than by calling a Unix command. A very quick test (touch ~/Desktop/foo.exe) produces this icon on my desktop:

foo.exe.png

contrasts with:

% file ~/Desktop/foo.exe
/Users/gurth/Desktop/foo.exe: empty

Then renaming the file to change the extension:

foo.empty.png

… and it all leads me to suspect that the Finder doesn’t examine the files themselves at all but just looks at the extension.

dkf

@Gurth Magic number inspection is relatively expensive (you have to open the file and poke around in it in a bunch of places — mostly near the beginning or end of the file, but even so) so if you can avoid that then so much the better. I'm pretty sure that Finder's aggressive about caching info like this; Apple have spent serious effort on trying to make Finder look fast.

HardwareGeek

@dkf said in External data files or hardcoding? Why not both?:

trying to make Finder look fast

As opposed to actually being fast?

dkf

@HardwareGeek said in External data files or hardcoding? Why not both?:

@dkf said in External data files or hardcoding? Why not both?:

trying to make Finder look fast

As opposed to actually being fast?

That'll depend on what you call fast. Everything to do with filesystems is really awkward to measure because of the sheer number of things done with caches at various levels. If the caches are persistent (i.e., some sort of hidden small database file) then you won't get a true cold-start view except very rarely. You would still have the old favourite of fun with cache invalidation, but I believe their preferred filesystem makes that easier.

APFS apparently uses B+trees for directories, so it's not going to have many speed problems if a directory holds a lot of files.

Gurth

@HardwareGeek said in External data files or hardcoding? Why not both?:

@dkf said in External data files or hardcoding? Why not both?:

trying to make Finder look fast

As opposed to actually being fast?

Certainly when it comes to copying large amounts of files, especially to another volume, the Finder doesn’t even look fast. It first works out if there’s enough room for them — not just by seeing if $totalfilesize < $freespace but (I have the impression) checking if the files will actually all fit before copying anything at all over.

Though I haven’t tested it, cp gives the impression of being faster than just that second step — never mind the first. Of course, with cp you could find your target volume is full before all the files have been copied. But if I’m copying, say, 50 MB of files to a drive with 1.2 TB of free space … why the stringent check at all?

Anonymous Throwaway

@Bulb said in External data files or hardcoding? Why not both?:

Can't it? And does it use the extension? Because from MacOS, being based on Unix, I would expect the opposite. That is, I would expect it to recognize it as Windows EXE because it starts with the two characters PE no matter what extension it has, and at least some of the subtypes like whether it is x86, amd64, arm5te or CRL (.нет) one. It just does not bother recognizing these obscure wrappers like flash.

… at least that's what Linux does.

Okay, yes, technically, Mac OS can read it. But since nobody with any sense uses the command line for file management on a GUI system unless they absolutely have to, that was shorthand for “the Finder does not bother to interpret Windows metadata into the Mac paradigm because it would not only be slow but potentially misleading to do so because there is not a 1:1 mapping between the metadata options in Windows and the options on the Mac”. Happy?

(The very, very few times there’s an actual reason to test whether a file matches its extension or MIME type (Mac OS X apparently uses MIME types sometimes, which is actually a superior system to extensions or file sniffing, but still inferior to the Classic Mac OS system of Type and Creator Codes, which they were crazy to abandon… but I digress) it implies a situation where you’ll want some more serious tools anyway. There’s not much point in the Finder telling you anything more since “Windows executable” already tells you the only thing that matters: you won’t be able to run it here.)

And, incidentally, Windows itself doesn’t look at the program and inherently recognize that it’s Flash — the Flash Player string (whatever it was, I’m not going to scroll back up to look) isn’t a categorization provided by Windows, it’s provided as some other piece of metadata like the copyright string. Linux probably can get you that, because it’s just another string stored in a standardized way. And given the specific file in question, you can be sure it’s X86.

HardwareGeek

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

inferior to the Classic Mac OS system ... which they were crazy to abandon

Ok, @blakeyrat.

dkf

@Anonymous-Throwaway There is the ability to add metadata to files in APFS. It certainly could be used to attach the true MIME type to a file (the attributes that I know they use are ones that say where the file was downloaded from and whether it has been cleared to be opened on the current machine). The advantage of MIME types over the old type codes is a stronger system for registering the particular identifiers used (IANA is widely recognised) and the cost of using a string for that information isn't too large (fast string matching is a solved problem). They might instead keep that information in the database that what I think of as Spotlight searches; that's extremely fast.

I don't think they do anything like creator codes any more, but that isn't as important as knowing the type.

Gurth

@dkf said in External data files or hardcoding? Why not both?:

I don't think they do anything like creator codes any more

The OS does have the ability to store which app each individual document is to be opened with. This defaults to the standard app for opening that type of document (as determined by its extension), but you can override it for any given file in that file’s info window. I wonder if this is stored as file metadata or remembered by the OS itself — which transferring the file to another Mac would easily prove, but again …

dkf

@Gurth said in External data files or hardcoding? Why not both?:

which transferring the file to another Mac would easily prove

Not necessarily. If the metadata is there in the first place somewhere, it's in principle easy to transfer to another location that understands it, and that would be true whether the information is held attached directly to the file (like the quarantine attribute) or is in a filesystem-level DB. If the transfer is of a filesystem, the DB goes with it; if it is of a single file, the metadata is in a side channel (akin to using email/http headers, even if not technically the same).

But remembering the "preferred opener" info is only really ever needed when it isn't the default, and so will normally be omitted. Most files simply don't spend their time being fought over by several apps...

Bulb

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

Mac OS X apparently uses MIME types sometimes, which is actually a superior system to extensions or file sniffing

It makes sense to cache the sniffed values, but sniffing is the only universal approach simply because many transfer methods don't bring the metadata along.

And by the way, as good MIME types are, they are still huge mess, and for the most part fail to capture the real complexity. This is best seen on formats like XML, JSON or SQLite database. You can have a .xml file, and there is a lot of useful things you can do with it just based on the fact it is XML, but for other things you care which schema it actually is. Extensions don't capture this, but MIME basically does not either.

Steve_The_Cynic

@Bulb said in External data files or hardcoding? Why not both?:

That is, I would expect it to recognize it as Windows EXE because it starts with the two characters PE no matter what extension it has

Um. No. Windows Portable Executable files, no matter what their target is (x86-32, x86-64, MIPS, ARM, etc), begin with MZ because they are fat binaries and also contain an EXE-format program capable of running on MS-DOS, and they begin with that program.

dkf

@Bulb said in External data files or hardcoding? Why not both?:

Extensions don't capture this, but MIME basically does not either.

MIME types have a better chance as you can at least use a vendor type code or a subtype modifier attribute.

Bulb

@dkf Yeah, you can – and should – do something like application/xml+yourapplication. I even saw it once. But most people don't, and I fear a lot of things like web service frameworks would choke if they got application/json+something instead of just application/json even though it's precisely what they should be getting (and producing).

dkf

@Bulb Well, if they say they accept that then they must indeed accept that. I've seen code that produces multi-gigabyte JSON docs...

Bulb

@dkf The problem is that everybody has different idea about what they should be using and what they should be accepting. Because for the middleware it's “just” JSON or “just” XML, so the middleware knows which de/serializer to call, but for the de/serializer requires specific schema, otherwise it won't bind to the data structure the handler expects.

Ad multi-gigabyte JSON, well, if there's that much data, feel free. A binary format would be (much) more efficient, but often content-encoding: gzip or content-encoding: brotli can fix that well enough that nobody cares about better underlying format.

… which is, by the way, another instance of the same problem. You can have content-type: application/x-gzip, or you can have content-type: text/plain with content-encoding: gzip for the same document. And which is more appropriate, who nose. But XML or JSON are, in sense, also just “encodings”, as is obvious in that some application servers can call the same service with either, just calling appropriate de/serializer based on content-encoding and accept-encoding in the request. So there can be potentially multiple levels of “encoding”, but mime only provides one content-type and one content-encoding.

Anonymous Throwaway

@dkf said in External data files or hardcoding? Why not both?:

@Anonymous-Throwaway There is the ability to add metadata to files in APFS. It certainly could be used to attach the true MIME type to a file (the attributes that I know they use are ones that say where the file was downloaded from and whether it has been cleared to be opened on the current machine). The advantage of MIME types over the old type codes is a stronger system for registering the particular identifiers used (IANA is widely recognised) and the cost of using a string for that information isn't too large (fast string matching is a solved problem). They might instead keep that information in the database that what I think of as Spotlight searches; that's extremely fast.

I don't think they do anything like creator codes any more, but that isn't as important as knowing the type.

The advantage of having creator codes, though, is that it preserves whatever system you use for types (you could have creator codes mixed with any other system you like for type matching) but lets users decide that some particular set of files of a given type are to be opened by a program which isn’t the default. For common file types that can be astonishingly handy. (For example: with creator codes HTML files can open in a web browser by default but in your editing application if you created them there, so that the default behavior preserves the editing vs. viewing divide. This comes up more often than you would think — for example, when an XCode project contains a Python file, you want to edit it within XCode, but since launching XCode takes forever and the editor honestly kind of sucks having non-XCode-associated Python files open in, say, BBEdit is a really good idea.) (It also used to help when a file type was meant to be for internal-use-only but had an obvious type, like “PREF” or “TEXT”.) For a while it looked like Apple was going to stick with some variant of the creator code system, but they more or less abandoned it entirely, or at least the behavior of the Finder suggests that they did. (Maybe they just made it so obscure that developers stopped jumping through whatever hoops are now necessary? Wouldn’t be the first time.)

Gribnit

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

Maybe they just made it so obscure that developers stopped jumping through whatever hoops are now necessary? Wouldn’t be the first time.

Possibly. Unfortunate, since for local-only application the feature could have been made transparent. It's not like the OS doesn't know when an application creates a new file, and stuff like cp,mv would be hitting syscalls, those could preserve the originator. It wouldn't even be expensive (as a local-only feature); executable paths aren't a large set and indexing would be feasible.

Gurth

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

The advantage of having creator codes, though, is that it preserves whatever system you use for types (you could have creator codes mixed with any other system you like for type matching) but lets users decide that some particular set of files of a given type are to be opened by a program which isn’t the default.

See above: you can still do that, though you have to select it yourself for the files in question (which you can do as a group if you want, rather than for each separately). Though this may not be as convenient in some cases as the OS saving the creator code with the file, it certainly beats having to manually open those files in the app you want to edit them in every time.

Anonymous Throwaway

@Gurth said in External data files or hardcoding? Why not both?:

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

The advantage of having creator codes, though, is that it preserves whatever system you use for types (you could have creator codes mixed with any other system you like for type matching) but lets users decide that some particular set of files of a given type are to be opened by a program which isn’t the default.

See above: you can still do that, though you have to select it yourself for the files in question (which you can do as a group if you want, rather than for each separately). Though this may not be as convenient in some cases as the OS saving the creator code with the file, it certainly beats having to manually open those files in the app you want to edit them in every time.

The question isn’t “is it possible to force a different program from the default to open specific files”, it’s “is there a mechanism to make it so that the default program for a file type varies based on which program created/saved the file”. You can always just drag the files to the application icon or open them from within the program, it’s just less convenient. If you’re not going to make a GUI more convenient, then it calls into question why you have one at all.

Gurth

@Anonymous-Throwaway Yes, that’s why I said you can still approximate that by a one-time selection you have to make yourself, which is more convenient than having to open a file by dragging it to the right app (etc.) every time you want to open it.

I’m not a Classic-era Mac users, but it seems to me like automatically saving creator codes can be just as inconvenient as not doing that, depending on the scenario. Sure, if you’re working on an HTML file you probably want it to open in an HTML editor by default, rather than a web browser. But if you make a quick HTML file that doesn’t need much or any editing, you probably don’t want it to open in the editor that created it but in a browser. Regardless of whether the creator code is saved automatically or not, you will have to change it manually for one of those files.

Anonymous Throwaway

@Gurth said in External data files or hardcoding? Why not both?:

I’m not a Classic-era Mac users, but it seems to me like automatically saving creator codes can be just as inconvenient as not doing that, depending on the scenario. Sure, if you’re working on an HTML file you probably want it to open in an HTML editor by default, rather than a web browser. But if you make a quick HTML file that doesn’t need much or any editing, you probably don’t want it to open in the editor that created it but in a browser. Regardless of whether the creator code is saved automatically or not, you will have to change it manually for one of those files.

You didn’t have to match the creator codes to open a file in another program — that’s what made the system so useful! For example, “TEXT” was the file type code for a plain text file. TeachText (later SimpleText), the default super-primitive text editor which came with the OS, had the creator code “ttxt”, Microsoft Word had the creator code “MSWD”, ClarisWorks was “BOBO” (the name of a programmer’s dog, apparently). You could open a ttxt/TEXT file in Word or ClarisWorks, a MSWD/TEXT file in TeachText or ClarisWorks, a BOBO/TEXT file in TeachText or Word. The question is simply: which program opens this file by default if I double-click it/use the “Open” command in the Finder? Mac OS X lost this ability — you can realistically only change the default for the all files at once.

It may not seem obvious if you’ve never had the capability to do so, but if you seriously work for a while with a system which has this capability it is very definitely preferable to have it. Changing the creator code was technically getting into power user territory (originally you had to have tools which did not come with the OS, most commonly the old ResEdit program) but once AppleScript came along (Wikipedia says: System 7.1.1, in October 1993) it was something you could do with built-in tools, and I can testify that I had drag-and-drop editable AppleScript programs to do that. (It occurs to me now, in hindsight, that I could have built one which would have loaded the creator codes of all available programs and presented you with a list, instead of either hard-coding the destination creator code into the script or asking the user to enter one and then having to do sanity checks on the value… oh, well.)

Tsaukpaetra

@Gurth said in External data files or hardcoding? Why not both?:

checking if the files will actually all fit before copying anything at all over.

Which (especially on remote targets that have compression or filesystem-level limitations that aren't exposed) is fraught with gotchas.

I was playing with a toy-formatted drive that had exceptionally large cluster sizes and copied a few hundred thousand teeny files before the TB of space suddenly ran out.

Good times!

Gurth

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

You didn’t have to match the creator codes to open a file in another program — that’s what made the system so useful!

How is that different from the situation now?

“BOBO” (the name of a programmer’s dog, apparently).

Bobo is a rabbit, not a dog.

It may not seem obvious if you’ve never had the capability to do so, but if you seriously work for a while with a system which has this capability it is very definitely preferable to have it.

If you say so … I think it would more likely confuse me that you can never really know in advance if, say, a JPEG will open in Preview, Photoshop, Safari, or whatever depending on the program that originally wrote the file. Having a single default app that you can permanently override for individual files feels like the better solution to me.

Gurth

@Tsaukpaetra said in External data files or hardcoding? Why not both?:

@Gurth said in External data files or hardcoding? Why not both?:

checking if the files will actually all fit before copying anything at all over.

Which (especially on remote targets that have compression or filesystem-level limitations that aren't exposed) is fraught with gotchas.

True, but a faster check would be nice — I don’t know how it works behind the scenes, of course, but I get the strong impression it performs the exact same check regardless of the volume being copied to, when I would expect the check could be much faster when copying to the same volume than to another.

Anonymous Throwaway

@Gurth said in External data files or hardcoding? Why not both?:

How is that different from the situation now?

Looks like somebody isn’t reading before they shoot their mouth off. Go back and read the post I made quoting dkf where my first words were “The advantage”.

HardwareGeek

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

Looks like somebody isn’t reading before they shoot their mouth off.

Welcome to TDWTF.

Gurth

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

@Gurth said in External data files or hardcoding? Why not both?:

How is that different from the situation now?

Looks like somebody isn’t reading before they shoot their mouth off.

No, I had read that. That’s how we got into this digression in the first place: you keep saying it’s so handy if there is a creator code in the file, and I keep saying I don’t understand how they are so helpful — because I don’t understand. From where I’m sitting, I don’t see much practical difference between files having metadata that says “I need to be opened in this app” because they were created in it, vs. having that because the user set it manually.

Watson

@Gurth said in External data files or hardcoding? Why not both?:

I’m not a Classic-era Mac users, but it seems to me like automatically saving creator codes can be just as inconvenient as not doing that, depending on the scenario. Sure, if you’re working on an HTML file you probably want it to open in an HTML editor by default, rather than a web browser. But if you make a quick HTML file that doesn’t need much or any editing, you probably don’t want it to open in the editor that created it but in a browser. Regardless of whether the creator code is saved automatically or not, you will have to change it manually for one of those files.

I had very little interaction with Classic Mac, so perhaps I just Didn't Get It either; I had a document that I was having to use two applications to edit (it was >25 years ago, don't ask me for details) and most times I saved, the application I was using would set the creator code. So the default "open" action would change frequently. I'm not sure whether the fact the document's icon kept changing to match as well was a benefit or a further hindrance.

ixvedeusi

@Anonymous-Throwaway said in External data files or hardcoding? Why not both?:

they more or less abandoned it entirely, or at least the behavior of the Finder suggests that they did

Type / Creator code were stored in the file's resource fork and they died together with it when MacOS X was introduced. Such a shame, resource fork and ResEdit were among the most awesome features of MacOS Classic (At least as long as you didn't try to interact with those second-class "PC" users running DOS or Windows or similar crap but why would you do that? )

dkf

@ixvedeusi I suspect they're holding the info in the .DS_Store hidden files (but can't check right now). As long as you're moving the files around with Finder and using the correct OS APIs for interacting with the UI, they're maintained correctly. File types are things that you want to communicate to other systems, but creator info isn't (because you can't count on the other system having that app or the user of the other system wanting to give a shit about how you last opened that file). Untyped files can be run through file or whatever MIME sniffer they want whenever it becomes something relevant to worry about.

In short, types are still there (in a different form because IANA is simply a better global registry of that stuff) and creators are now "last thing I asked to open this" info maintained just by Finder.

ixvedeusi

@dkf said in External data files or hardcoding? Why not both?:

In short, types are still there (in a different form because IANA is simply a better global registry of that stuff) and creators are now "last thing I asked to open this" info maintained just by Finder.

Yes, as I said type / creator codes (i. e. the thing @Anonymous-Throwaway got dreamy about) died with the resource fork. They were replaced with mime types. I think these are actually stored as xattrs but I might be wrong.

@dkf said in External data files or hardcoding? Why not both?:

because IANA is simply a ~~better~~ global registry of that stuff

: To my knowledge there was no global registry for either type nor creator codes; for types you were supposed to use one of a handful of standard codes if any applied. If not (and for the creator code) you just made up some value and hoped there'd be no collisions.

Though I'm pretty sure that had very little to do with the change. Simply with the demise of the resource fork their previous system needed a replacement anyway, and by then mime types had become the go-to solution for such things.

dkf

@ixvedeusi said in External data files or hardcoding? Why not both?:

Simply with the demise of the resource fork their previous system needed a replacement anyway

For short things like these, there are extended attributes and macOS definitely uses them for some things. I'm just not sure if they're used for these specific bits of metadata.

HardwareGeek

@ixvedeusi quoted in External data files or hardcoding? Why not both?:

the behavior of the Finder

My brain read this as "the behavior of the Finger".
My brain needs more caffeine.

dkf

@HardwareGeek said in External data files or hardcoding? Why not both?:

My brain needs more caffeine.

#MeToo

Parody

@ixvedeusi said in External data files or hardcoding? Why not both?:

: To my knowledge there was no global registry for either type nor creator codes; for types you were supposed to use one of a handful of standard codes if any applied. If not (and for the creator code) you just made up some value and hoped there'd be no collisions.

In the Classic Mac OS days creator codes were supposed to be registered with Apple. (Old FAQ about it from the Wayback Machine.) You could search to see if one was already registered but they didn't give you any other info about it.

Of course, there was nothing stopping a program from using whatever it wanted.