.info ... was it so much a good idea?

[Trev]

I've never liked how .info files are only loosely coupled to the object they represent. It might have made sense in the 80's given the simplicity (and limitations) of the period object formats and file systems, but they could just as easily have defined a new hunk type and embedded the data directly in the object. On AmigaOS 4.x, I'm surprised the data hasn't been moved into an ELF section. It would still be possible for tools like Workbench to override embedded data using an .info file if one exists.

[Trev]

@lsmart

What happens when an Installer script--not necessarily OWB's--overwrites your customized .info? That's not necessarily a drawback, but an installation routine should make an attempt to keep and upgrade a user's existing settings.

@mongo

Use IFF? That's not a good solution either. Deficons is the compromise solution, yes? It all depends on what--operating system or application--owns data. System designers are still looking for the holy grail of application agnostic storage containers.

There are some aspects of .info files, like tool types, that are pretty cool. The downside, I think, is having to write wrappers to combine ReadArgs(), FindToolType(), and generic command-line processing in a way that works with multiple releases of Workbench.

[Trev]

@Belial6

Shortcuts (.lnk files) are shell links (instances of IShellLink persisted to disk) [1]. Shell links and the extended data they support are more similar to program information files than either is to .info files. Both shell links and program information files manage pointers to separate persistent objects and neither contains an icon bitmap.

EDIT: URL files, while managed by Windows Explorer's shortcut interface, are just text initialization files with a .url extension.

1. http://msdn.microsoft.com/en-us/library/bb776891(VS.85).aspx

[Trev]

@bloodline

a similar (but more advanced) idea can be found in both nextstep and MacOSX with their bundles/packages respectively.

You can do something similar in Windows, but Windows users expect directories to behave like directories, regardless of what's in them or how they're managed. That's a drawback, but it is what it is.

@skurk

a .lnk file is like a fake symbolic link

That's not a great a analogy, as only Windows Explorer (the shell) knows what to do with shell links. An application that uses shell APIs to process files may be able to treat them like symbolic links, but not in all cases. Real symbolic links were added to NTFS with Windows Vista, although Windows Explorer treats them like second class citizens (the shell team not working with the file system team?).

@kolla

Yes, but .desktop (and .directory?) files are not part of UNIX or even Linux. If I understand their use correctly, they share a relationship with KDE and GNOME that's similar to a shell link's relationship with Windows Explorer.

[Trev]

My prediction is that .xml will eventually take over.

Not in any meaningful way. Too many companies own patents on generic uses of XML.

[Trev]

@Bloodline

It was a brilliant idea, and a similar (but more advanced) idea can be found in both nextstep and MacOSX with their bundles/packages respectively.

I was thinking about this a bit this morning, and Windows 7 provides an easy way to emulate the basic launch behavior of Mac OS bundles. Create a directory, e.g. MyApp (or My App--spaces are OK), and put all of your application's goodies in that directory:

MyApp\
  MyApp.exe
  dependency1.dll
  dependency2.dll
  data1.dat
  data2.dat

In MyApp, create a Desktop.ini text file with the following contents:

[.ShellClassInfo]
DirectoryClass=MyAppBundle
IconResource=MyApp.exe,0

You can add additional Desktop.ini values to further customize shell behavior. Strings in Desktop.ini can be localized. You can also set the read-only and system attributes on the Desktop.ini file to hide the file under Windows Explorer's default view settings, but it's not necessary.

Set the read-only attribute on the MyApp directory.

Add the following values to the registry (no snarky comments from the registry naysayers) ("@" is the key's default value):

[HKEY_CLASSES_ROOT\MyAppBundle]
@=""
"CanUseForDirectory"=""

[HKEY_CLASSES_ROOT\MyAppBundle\shell]

[HKEY_CLASSES_ROOT\MyAppBundle\shell\openDesktopIni]
@="Run" Note: This can be localized.

[HKEY_CLASSES_ROOT\MyAppBundle\shell\openDesktopIni\command]
@=

Where is of type REG_EXPAND_SZ and equal to:

rundll32.exe shell32.dll,ShellExec_RunDLL "%1\MyApp.exe"

You can any value you want in place of "MyAppBundle." Apple-style identifiers, e.g. com.Spacely.Sprocket, work just as well. It's nothing more than a unique text identifier.

The default action on the MyApp directory is now "Run," which runs MyApp.exe. The directory can be moved anywhere, and as a long as you've obeyed Windows guidelines for local execution and use of side-by-side components, everything will work just fine.

A more generalized approach to bundles could treat all directories with the .app extension as special, using shell extensions to manage behavior in ways mostly identical to Mac OS bundles. This approach would work on earlier versions of Windows.

(My primary reason for writing this was to have something useful show up when folks search for CanUseForDirectory, which is only very briefly mentioned in the Windows SDK documentation. The only Windows component on my system that makes use of CanUseForDirectory is Windows Backup and Restore.)

EDIT:

Questions re: Mac OS X bundles (which are complex and weighed down by legacy options--just like Windows--despite Apple's marketing hyperbole):

What happens to file type associations when a bundle is deleted? Does the operating system unregister associations automatically?

Are orphaned preferences files automatically removed, or are they left in place to be picked up again if the bundle is ever reinstalled?

[Trev]

Applications are free to control their own settings any way they like. .NET applications typically use local XML configuration files. (That bodes well for psxphill's prediction, but I suspect the OOXML lawsuit brought by i4i will only force Microsoft further away from standards, not closer to them. The lawsuit potentially affects all XML document implementations, including ODF. Standardization does not exempt users from patent claims.) EDIT: Of course, having well documented local configuration practices doesn't stop lazy, idiot developers from plowing over system-level settings.

Current versions of Windows support transaction-based changes to the registry, and it's a fairly simple process to perform bulk operations. A crude implementation might use 'regedit /e ...' to export and 'regedit /s ...' to import. If you wanted to use XML, you could write a fairly simple XSL transform to convert a registry-like XML schema to a normalized regedit file and vice versa.

Changes to the registry are written to a log before being committed, and most registry corruption is actually caused by disk faults, not a deficiency in the registry design. I'm not saying there aren't flaws, but most registry problems aren't effected by what most people seem to think are common sense root causes.

[Trev]

Most other systems are based on System V or BSD, and aside from the top-level etc directory sharing a common name, it's a free for all. I'm not convinced that's a strength. :-P

EDIT: Microsoft's biggest mistake regarding the registry, I think, was adding "serious problems might occur if you modify the registry incorrectly" to every knowledge base article with even a hint of registry. This is going to blow my point, but I'm reminded of a sign at Yosemite National Park that warns people against entering pools above the falls because "you WILL go over the falls, and you WILL die." Duh.