Vigil wrote:

The Info.plist file I have attached "educates" OS X that .conf files are plaintext, and tells it to describe them as "DOSBox Configuration Files" unless another application has a more authoritative claim to the .conf extension.

I claimed the Config file type describes as "DOSBox Config File", but your "DOSBox Configuration Files" looks much better...
The File Type for DOSBox config files I registered at Apple.com is: DBGc , depending suffix my frontend uses is ".conf"

Language files I registered as File Type DBGa , described as "DOSBox Language File", using the extensions ".lng" and ".lang"
(In fact, the DBGa was a placeholder, later used for language files).

Description texts and extensions are changeable everytime, though.

you either may use the same File Types or registrate another, but I suggest to use the same File Types.

The official File Type for PC applications Apple (or Microsoft for its Virtual PC application, I'm not really sure) uses is (who wonder) "PC Application"

OS X 10.4 has introduced UTIs (Uniform Type Identifiers) as the preferred way to describe filetypes. This format is intended to unite file extensions, mimetypes, and the old 4-letter Mac OSTypes into a single way of identifying what files an application supports. The documentation for them is here: http://developer.apple.com/documentation/Carb … _section_1.html

OS X (10.5 at least) defines EXE files as "Microsoft Windows Application" and gives them the UTI com.microsoft.windows-executable. If EXE files are described on your system as "PC Application" then this is probably given to them by VirtualPC or another virtualisation program.

Since there's no pre-defined UTIs for com or bat files, the modified Info.plist file I attached defines the new UTIs com.microsoft.msdos-program (for *.com files) and com.microsoft.batchfile (for *.bat files). These are defined as conforming to com.microsoft.windows-executable, and batchfiles also conform to public.plain-text (the official Apple UTI for plaintext files).

I also defined the UTI "com.dosbox.configuration-file" for .conf files, and "com.dosbox.language-file" for .lng/.lang files. It would be no trouble to also associate these with the DBGc and DBGa OSType codes you've already defined, as a UTI can have any number of file extensions, mimetypes and OSTypes associated with it.

However... many other programs use .conf files, so it's probably not appropriate after all to give them a DOSBox-specific UTI or title. Maybe .conf should instead be defined in an ImportedTypeDeclaration (this is less authoritative than an ExportedTypeDeclaration) and given a more general title like "UNIX Configuration File".

Yes, i think there is no conflict when using different file type creators, since the file content is the same.
Your file type description looks more MacOS X like than mine. 😀
They should be included with the official DOSBox Mac port.

I have now updated the attached Info.plist file. The new version adds the appropriate file-assocation keys for OS X 10.3 and below, as well as making the following tweaks:

- removed leftover icon file references from Boxer.
- changed .conf files to the UTI org.gnu.configuration-file and changed their description to "Configuration file", to reflect that .confs are used by many UNIX applications and are not DOSBox-specific.
- changed .com files to the UTI com.microsoft.msdos-executable and the description "Microsoft MS-DOS application", to match com.microsoft.windows-executable.
- made com.microsoft.msdos-executable and com.microsoft.batch-file conform to public.executable instead of microsoft.windows-executable, to reflect that they're not based on the windows-executable file format.

Almost forgot! it also associates the DBGc and DBGa OSType codes with com.microsoft.msdos-executable and com.microsoft.batch-file respectively.

I found when testing these that once you've declared imported types for an application, it's *really really hard* to make OS X respect any later changes to them. OS X instantly respects changes to exported type declarations, but assumes your changes to imported type declarations are no more authoritative than the old version of your Info.plist.

For this reason, it's important to get them right first time before including them in a released application.

Vigil wrote:

Almost forgot! it also associates the DBGc and DBGa OSType codes with com.microsoft.msdos-executable and com.microsoft.batch-file respectively.

Does it automatically associate? Usually, the DBGc stands for config file, the DBGa for language file, not for executables or batch files.

I needed the file types to filter the browse dialogs, also to let the OS X know that the frontend can handle such files (if other frontends uses other file types, that shouldn't interfere the OS). 😉

Vigil wrote:

If EXE files are described on your system as "PC Application" then this is probably given to them by VirtualPC or another virtualisation program.

Yes, I'm sure it is.

Argh sorry, I meant to say that I'd assigned them to org.gnu.configuration-file and com.dosbox.language-file respectively. The info.plist file is correct, I'd just confused the names in my post.

OS X 10.4 and above use the UTIs for filtering the file dialogs, specifying what filetypes an application can open, and what formats of clipboard data it can handle. So, basically everything you would use the OSType for.

Vigil wrote:

OS X 10.4 and above use the UTIs for filtering the file dialogs, specifying what filetypes an application can open, and what formats of clipboard data it can handle. So, basically everything you would use the OSType for.

😀 + Thanks for this information, I think it' useful for me. 😉

No problem! 😀 I also realised I should make it clear that this Info.plist doesn't assign confs and lang files to be *opened* by DOSBox - it just tells OS X what kind of file they are (plaintext) and how to describe them ("Configuration File", "DOSBox Language File"). This information will mean they're opened in TextEdit by default.

Boxer now uses these same UTI declarations, again without assigning confs or langs to be opened by Boxer.

Vigil wrote:

Boxer now uses these same UTI declarations, again without assigning confs or langs to be opened by Boxer.

That was a (short) problem for me, since dg needs the file types of conf and lang to handle them (mainly re-directing them to DOSBox), the MacOS Finder thinks dg can handle such files. That wasn't really true since I added text field windows to display their content when double-clicked in the Finder.

True, the better way is to open these files with TextEdit (standard text editor in MacOS X).

Vigil (and others who knows their way around OSX) - I noticed this blog/article about a little fix to some plist-thingy that enabled Firefox 3 to update the screen much faster.

Is this something that would benefit the OSX port of DOSBox?

Apple Tech Note:
http://developer.apple.com/technotes/tn2005/t … 133.html#TNTAG9

I'm not a technique freak, but Rhoenie could reply something to your intention...

Vigil, when trying to detect disk images by our MacOS frontends, would the file type called public.disk-image make the job?

System-Declared Uniform Type Identifiers

It's described as "Base type for items mountable as a volume", so I assume a dialog box using this file type should enable all types of disk images, isn't it?

The problem is that public.disk-image encompasses types of disk images that DOSBox does not support. For instance, I don't believe DOSBox can mount the mac .DMG image format, nor Nero .NRG disk images, both of which are (or would be) encompassed by public.disk-image.

So, it would be safer to use only the specific image types that DOSBox 0.72 currently supports. But at the moment I'm not clear on what those are! I know it supports ISOs - so public.iso-image is appropriate - but I have no idea what format HDD or floppy images are meant to be in, or what Type ID they would correspond to (if one even exists), or how to identify them by file extension or mimetype. If one of the devs could clarify this and maybe provide some example image files?

Regarding the "coalesced updates" fix - I did a VERY unscientific test of this with System Shock, which suffers from framerate problems for me, but didn't notice any difference in performance with it on or off. Reading the tech note, it sounds unlikely to me that it would affect SDL-based applications anyway. If it were affecting DOSBox then the effect would be to cap the framerate to 60fps (the refresh rate of standard Apple LCDs) and to result in frames being dropped if DOSBox takes too long rendering them.

Not a dev, but of the top of my head:

ISO - yes

CUE/BIN pairs - mount the CUE, ignore the BIN

BIN - maybe. Seems a lot of formates are lumped into that.

IMG - maybe. Could be anything. DOSBox HD (and diskette) images should be the type created by the Bochs utility bximage. No idea how to identify them as such.

MiniMax wrote:

IMG - maybe. Could be anything. DOSBox HD (and diskette) images should be the type created by the Bochs utility bximage. No idea how to identify them as such.

Both of you, you're right, public.disk-image covers *all* disk images, not only such supported by DOSBox, but others, too.

I tried bximage before and I think it should be included with the frontends to create such files. So I know bximage creates files with extension *.img. The only way to recognize bximage files seems to be their extension (*.img).

Vigil wrote:

so public.iso-image is appropriate

Yes, that's true, it's a part of the number of supported images.

Here is a list of images supported by Apple's DiskImageMounter:
http://en.wikipedia.org/wiki/DiskImageMounter
There is listed a file type called com.apple.disk-image-pc, but no further informations are provided for it.

Try the file command (should be included with your MacOSX):

1$ file *.img
2a.img: DOS floppy 1440k, x86 hard disk boot sector
3b.img: DOS floppy 1440k, x86 hard disk boot sector
4c.img: x86 boot sector, FREE-DOS MBR; partition 1: ID=0x1, active, starthead 1, startsector 17, 20468 sectors

Next, look at /etc/magic (or /usr/share/file/magic).

Edit: Ups - small error in my code-example

MiniMax wrote:

Try the file command (should be included with your MacOSX)

Yes, but I don't understand it. What should it do? 😕

Ups - Sorry IIGS_User, small error in my code-example. Try

$ file some-image-file.img