[rotuts]

this is both a software and hardware question and relates to the possibility fo Intel chips in the future.

a long time ago, shortly after the Sun first gave light, I did programing on an IBM 360-67. they had cards in those days and my longest program was one box! for those who remember. then I gave up computures and restarted with the first Mac. Fotran was a long time ago as was PL-1

I recall then your program ( Fotran, PL1 etc was compiled, translated into mysterious machine language, then ran and some paper was eventually spit out, based on your willingness to spend time formating your answerin your program.

Now, OS 10 or Window, programs have the GUI, but doesn't then the same general thing happen? "Runnin" the program compiles it, some sort of machine language runs it, etc all of this taylor made to the chips you are using?

so an OS IBM-PPC program has to be re written for Intel? or recompliled? or what? itsn't this a massive undertaking?

can someone flow chart this out even if Mon the new s is different?

thanks rotuts

[ghporter]

Software that runs on modern computers is generally already compiled into an executable image before being shipped. You can find interpreters (which is what your mainframes did "in the day") for various languages, but that's not where most software is.

When you load a program on your computer, the installer customizes the image stored on your drive with whatever variables (drive location, hardware support needed, usernames, etc.) are required for it to run. It is in a form of machine language that the OS recognizes as loadable and executable, not in any way related to source code.

I hope this answered your questions.

[TETENAL]

Programs these days are usually written in a "high level programming language" (sort of english-like). High level programming languages are usually machine independent.

To execute the program on a certain machine it is either:

a) compiled
Which means it is automatically translated into machine code. Usually then only the machine code is delivered to the customer who runs it. Carbon and Cocoa applications are of this kind on Mac OS X.

b) interpreted
Which means that the code is interpreted at runtime. AppleScript is of this kind on Mac OS X.

Obviously interpreting the code while running is slower, but the same code could be run on any processor. Compiled code only runs on the processor it was compiled for. If you'd like to run it on another processor you have to recompile the source code and deliver the machine code for that particular processor type to the user.

If Apple had Macs with either PPC or Intel processors (which will not happen on Monday) Mac programs will need to be compiled for both processors (which is an automated process) and both binaries will have to be delivered to the user (which Mac OS allows to do in the application package).

[rotuts]

thanks for an update for Personal Comps.

so the CD's you get now for programs are 'machine language". so Apple would then have to send two versions of its OS compiled in ML for intel or PPC?

TET: would you elaborate more on:

both binaries will have to be delivered to the user (which Mac OS allows to do in the application package).

what do you mean by: which Mac OS allows to do in the application package).

I sure hope that PPC does not become a 'dead end' that a lot of $$ to buy software yet again when updating hardware, and if it did go to Intel in 2y for top of the line, why develop faster PPC now?

we will see. thanks

rotut

[TETENAL]

Originally Posted by rotuts

tTET: would you elaborate more on:

both binaries will have to be delivered to the user (which Mac OS allows to do in the application package).

file:///Applications/Safari.app/Contents/

Control-click this link and choose "Open in new window" from the context menu. It will reveal the actual package contents of Safari. The "Resources" folder therein contains all the resources like pictures and dialog layouts used in the program. Those are independent of the processor the program is run on. The "MacOS" folder (somewhat unfortunately named) contains the actual executable in machine code compiled for PowerPC processors. In addition to this "MacOS" folder (meaning for PowerPC) the Safari package could also contain an "x86" or "Itanium" folders with executables compiled for other processors. The operating system would then simply run the executable of the correct type depending on the processor.

Someone would also write a shareware called "Monoprocessual".

[rotuts]

TET

for some reason nothing seems to happen when I control click the line you mentined. but I get the idea of what you are saying.

Im using Mozilla as a browser, do I have to see the link in safari?

monday will be interesting toooooooo bad no web cast as far as I can see. I would to love to see those Mac events choppy on a dial up!

thanks rotuts

[Chuckit]

Just control-click on Safari in the Finder and choose "Show package contents" and it'll do the same thing as that link.

It's also worth pointing out that even though most languages are intended to be machine-independent, it's rare that you can write a fairly complex program for one platform and then just recompile it for another. Even in a language like Java, which isn't compiled into machine code and thus should be write-once-run-anywhere, true platform independence hasn't really happened yet.

[TETENAL]

Yes, sorry. I was assuming you were using Safari as everybody else.

[rotuts]

OT: now that I have 10.3.9, should I try Safari?

thanks for the tip[s

Rotut

[Chuckit]

I used Firefox until 10.3.9. Now I use Safari. I guess you may as well give it a try.

[TETENAL]

Originally Posted by Chuckit

It's also worth pointing out that even though most languages are intended to be machine-independent, it's rare that you can write a fairly complex program for one platform and then just recompile it for another.

Actually, except for endianness, if you write in a high level language I can think of no problem. Switching to another processor is nothing more than a recompile.

Now switching to another operating system, that is a different matter.

[Chuckit]

I guess it depends on what you means by "high-level language." But I think it's fair to say that any language where you can directly address memory can get bitten by more than just endian-dependency. For instance, programs may make assumptions about the size of primitive data types (e.g. sizeof(int) == sizeof(short)*2, or sizeof(long double) == 12) that won't necessarily hold true across architectures.