I would expect you to need to create a project in your solution that targets the windows platform, then hook everything up so it runs your game.ĭepending on your design, this can be non-trivial. I don’t have any experience using a Mac myself, but I would expect it to be fairly similar to building for Android on Windows. How did these files specifically come to you? How were they transferred? Had they been compressed? If you can describe (in detail) the route they took from hard drive to hard drive, CD to CD, network to network, we may be able to pinpoint where, exactly, the resource fork info was lost and find a workaround.Don’t mind Martenfur, he’s our resident troll here FAT32, NTFS both seem to do ok with it most times). They should use a compression (.zip usually works) that preserves resource fork information, or store the files on a file system that retains this information (MS-DOS format = yuck for resource forks. There's not much you can do to get around the problem without teaching the clients new tricks. Windows machines know nothing of reading/writing Mac-compatible resource forks.Ģ) The files originated on a Mac, but were either transferred with a protocol or compressed with a program that ignores or strips files of that resource fork information. doc extension to associate the file with Word.ġ) The files originated from a Windows machine (or some non-Apple operating system) and no extension was put on the file. This doesn't happen with files with extensions most of the time, because even if a Word document lost its resource fork (type/creator codes, specifically) information, it could still use the. What's happening is that Mac OS X can't read the file's resource fork (and, since there's no extension on those files either, it can't even "guess"), and therefore doesn't know what the file is.
0 kommentar(er)
