grr res edit os x

Guy, on Jan 23 2005, 09:40 PM, said:

Check the iTunes package. In the resources folder is a file called iTunes.rsrc. This is full of resources in the data fork.
View Post

Finally, someone who doesn't just believe everything Apple tells them. iTunes is not the only app to use traditional resources; there are plenty of apps in OSX which use them. Apple want's to move away from them, which is understandable. Just don't believe them when they claim resources are no-longer used under X.

This is kinda like how Microsoft claimed that Windoz XP no longer used DOS. Wrong, it's still there. They just changed the name.

I took great delight in demonstrating to my fellow PC-zealots at college this fact.

Arion, OS X uses resources. If it didn't, Nova wouldn't work on X, MC wouldn't work on X, EVONE wouldn't work on X, etc. Resources are fully supported under X, despite Apple's claims to the contrary (they're just trying to push .nibs, that's all).

A resource editor for X would be perfectly logical; more so, in fact, than one for 9, since 9 already has a (mostly) well-working one by Apple, and it's even free.

I bet Apple's trying to make us forget about them because of so many bad memories involving hacked System Files...

But then again, why would ResEdit warn you when you open a System File? I bet Apple wanted us to toy around with stuff back then, but now it's a different situation...

Apple has never encouraged people to modify thier systems in any way... They made the early macs unopenable for that reason. They tried to make OSX not take any kind of extension, as we pre-X people know them.

Though hacked system files have saved my ass far too many times to count!

orcaloverbri9, on Jan 24 2005, 03:14 AM, said:

Arion, OS X uses resources. If it didn't, Nova wouldn't work on X, MC wouldn't work on X, EVONE wouldn't work on X, etc. Resources are fully supported under X, despite Apple's claims to the contrary (they're just trying to push .nibs, that's all).View Post

I don't think anyone's disputing the fact that OS X recognises resources. Just that programs specifically developed for OS X don't (generally) have any because they're really an OS 9 thing.

Yeah, but they're still used for Carbon applications (which can be made with Apple's tools under X), so in fact it makes perfect sense to have a X resource editor.

Whether or not it makes perfect sense, there's never going to be one until one of you people who want one so bad makes one or asks a favor of someone who can. Apple certianly isn't, so it's up to the independant programmers to make one.

My point is that whether or not there should be one, there isn't, and there won't be until it is made. My other point is that though there might be some people outside of the Nova community who realizes that X uses resources, they probably won't code one. In other words, it's probably up to us, or at least our programmers...

...And before you ask, I know a tiny bit of Python, and that's it.

I was not disputing any point by you. I was saying that it is logical, i.e. disputing Arion's point.

By the way, you're wrong either way; there are multiple editors; off the top of my head, ResFool and ResKnife. Hell, even MissionComputer works (RDL scripts).

<.<

.>

Well...

I forgot. ^.^v

I was just tired of people saying "They should do this" and "They should do that" when "they" weren't going to do either.

Anyways, once one of those programs supports user templates... Ya think there's going to be a Novatools update?

ResKnife, I know, has support for TMPLs, but not RSSC/RMAPs.

All of this seems like more and more of an argument to still use OS9...

ResFool also support templates. ResKnife's template support seems to be limited at the moment but it says it supports plug-in editors. I'm not sure if that simply means templates or some form of proper editors.

rmx256, on Jan 28 2005, 03:00 AM, said:

All of this seems like more and more of an argument to still use OS9...
View Post

At the least, an argument to keep Classic Mode around.

I believe the binary format for resource files is undocumented (or hidden away in some dark corner of pre-1990 Inside Mac).

ResEdit is a deceptively simple, but very complex little program.

While it would be nice to have a carbonized version, I can't see any developer justifying the effort to do it, given that only a very small people would make use of it.

I'm with Rik on this. OSX is for playtime.

All your serious work should be done in OS9

tycho61uk, on Jan 28 2005, 12:35 PM, said:

I'm with Rik on this. OSX is for playtime.

All your serious work should be done in OS9
View Post

Actually, most of my games are OS9(Marathon1-2-3-AlephOne, Mars Rising, Maelstrom, etc.).

And all my graphical/EVdevving apps besides Terragen are for OS9. I still use Mission Computer 9(v. 3.0.2), ResEdit w/NovaTools, and I tried to use EV-Edit one time... It was too unreliable.

Does anyone else use Super ResEdit? I find it to be more stable than normal ol' ResEdit.

^Haven't heard of it. Link?

Lindley, on Jan 29 2005, 05:50 PM, said:

Link?
View Post

google.com

I found a download within 30 seconds of searching. To save time however, its on the Mac section on this page.

This post has been edited by Jules : 29 January 2005 - 03:25 PM

Undocumented, the resource file format? Yeah, right.

I can bring some balance to this discussion. For one, I'm actually programming on the Mac. No kidding. Using good ol' C with the Carbon API. I'm a registered (online, i.e. free) developer and I received the ADC newsletter and check the ADC website.

The resource manager is still supported in Carbon (with a few exceptions such as ROM resources, since there is no more ROM in OSX). However, it's obvious Apple is trying to get/move us (developers) away from resources.

To begin with, they are most of the time irrelevant right now. Resources are not just a storing format, but a complete virtual memory management system: the resource manager loads the resources from the drive to the memory when we ask them, then they remain on memory and we can still ask for data in them. If ever memory becomes tight, then the resource manager purges resources from memory to make room for others; if ever the program wants to access the resource that has been purged, then the resource manager (transparently) reloads the resource from the disk. This allowed to work with limited memory.

Also many managers (menu manager, for instance) were based on resources. For instance to refer to a menu, the program passed the handle of the loaded MENU resource to various functions, and could even directly modify in memory the data in the resource, which would then be used by the menu manager to draw the menu the next time the user would pick it. But now in Carbon these same managers use opaque structures to which the program does not have direct access, we have to use accesor functions, and that are not resource handles (a handle is a pointer to a pointer to the resource data, this allowed the memory manager to move this data in memory and the program still have a valid, modified pointer to it), just a pointer to the opaque structure. Menus can still be loaded from resources with the same functions, but it's just for compatibility, since in the memory they are no longer resources. We might as well load them from nibs. Which I did for my latest program.

Now, there are two separate issues. The first is the one of the resource fork. You're aware by now that it's a major pain in the ass to move in contexts (zip compression, internet transfer protocols, UNIX and Windows filesystems, etc...) that support only one fork per file. That's why resource in bundles are actually in the data fork of a file in the bundle, so that applications can be distributed more easily than non-bundle apps, that had to be compressed in .sit or encoded in .bin (even installers). Apple is tring to move away from the resource fork as fast as they can. Unfortunately, due to limitations in CarbonLib, there still needs to be resources in the resource fork of Carbon applications to make them work in OS9, so the OS9-compatible apps still have to use the resource fork.

The second issue is that of the resource format itself (in the data fork or resource fork) and the resource manager that uses them. We can still use them without problem, and since they have not been declared unsupported in Carbon, we will probably be able to use them for some time, even if the relevance of resources is no longer strong. Though for instance in Carbon nib files, some interface elements can be given a picture, that has to reside in a PICT resource in the resources of the application bundle... I'm still using one or two resources (leftover from the project template) in the application I'm working on right now; of course they are in the data fork of a xxxx.rsrc file in the bundle. Notice that I'm working with Project builder (July 2002 dev tools, that came with Jaguar), and that it cannot target OS9. Ironically, I can still use ResEdit (that isn't aware of the resoure-in-data fork scheme) for this: I just have to include the ResEdit resource file in the project instead of the main.r (a rez file that can be compiled in resources), and when building Project Builder copies the resources inside the file to the data fork or the xxxx.rsrc in the built bundle.

Apple does no longer support or updates ResEdit to try to move programmers from relying on resources, and use instead files in the bundles (such as images), xml stuff for settings and preferences, and nibs for UI elements (menus, windows, dialogs, controls). But resources will continue to be used, though it makes the work of people who work on "resources" (in the general sense, that is stuff in the bundle that's not the executable), such as localisers, harder since they have to use ResEdit on Classic mode or expensive or limited resource editors, instead of interface builder, an xml editor, and the actual editors for the files (for intance images).