And when you delete the .pxml file, what happens?
1) You can't if it's built into the PND file. As mentioned, the PND is just an archive, with the PXML being just another file in it, or appended to the end of it, however it works. Point being that it's just one file.
2) If, for some bizarre reason, the author is distributing an unpacked version, or you've unpacked the PND file manually, the PXML file is irrelevant. It tells what the executable is, what icon to use to display, other things like that (from my understanding), so deleting it has absolutely no impact on the programs ability to run. The difference is that instead of being told which file in package is the one to be executed, you have to select it. And you don't get a useful icon on the desktop to make selecting it easier, but I imagine there's a default just as there are in every other OS.
QUOTE
I just see it as another file I have to keep around, know about, deal with, etc.
Not really. It's in the PND package, and there are very few useful games and apps that don't already have many other files already. What's one extra file that the user shouldn't normally be touching anyway?
QUOTE
I don't think there are any valid cases for user-editing of the PXML file that wouldn't exist if it weren't for the fact that the PXML file exists as a separate entity in the first place - i.e. the only reason you'd want to edit the PXML file is because .. you MOVED the PXML file!
Just because you can't see a reason to use a feature is no reason to actively remove that feature. Doing work to intentionally limit yourself seems counter intuitive.
QUOTE
Ah, now this is a bit more sensible, and I think its interesting - but if it really is the case that a .pnd container is being wrapped around Pandora-only executables, then why bother forcing the programmer to add a .pxml file to the archive when they can just as easily render the PXML data to stderr/stdout on processing of argv[]?
A PND isn't a wrapper around the executable, it's a package around everything: the executable, map files, icons, music files, etc...; anything and everything that that program would rely on.
QUOTE
I just like the idea of having the app talk directly to the program-manager by way of stdout on prompting to do so by a cmd-line argument .. this seems 'neater' to me, but okay ..
This is not to be taken as an insult, but 99% of the "neater" ideas I've seen in software development are candidates for the
http://thedailywtf.com/
QUOTE
Obviously, the .pnd extension is a solution to the FAT32 exe-bit not being settable. So, just parse all the .pnd files, find the executable files within, run them individually with '--output-pxml', and oila ..
There's no way to "find the executable files". FAT32 doesn't have an execute bit. You would have to run --output-pxml on every single file in the pnd archive until it hit with a match. This will not only take a long time, but you'll be trying to execute a bunch of files that simply aren't executables. Some of those files might actually look like executables anyway, but not be the right one, and there you get into dangerous territory. It just doesn't sound like a good idea.
Consider this, however. Suppose there is an easy way of figuring out what file is the correct executable. If only the executable could produce the pxml, then you rely on the developer to have actually coded that in. What about all the existing packages, or beginner or lazy programmers that didn't add it? They would need to be recompiled to output the pxml data under your scenario, or simply add a pxml file separately to the package and be done. It's easier the second way. What if the format is found to be buggy and needs to change for some reason? You can either write a parser which very easily takes all existing pxml files and fixes them to the new format, or force everyone to recompile their executables.
It just sounds like you're "neat" idea is locking down too many features for the sake of being neat.