Re: Code curosity - long, technical, and probably boring!



In article <43925743$0$81266$742ec2ed@xxxxxxxxxxxxxx>,
Don Bruder <dakidd@xxxxxxxxx> wrote:

> In article <mipaine-329E7A.10084703122005@xxxxxxxxxxxxxxxxxxxxxxxx>,
> "G. Michael Paine" <mipaine@xxxxxxxxxxx> wrote:
>
> > In article <stevewjackson-F6A738.13051502122005@xxxxxxxxxxxxxx>,
> > "Steve W. Jackson" <stevewjackson@xxxxxxxxxxx> wrote:
> >
> > > In article <mipaine-A9ACB9.09312702122005@xxxxxxxxxxxxxxxxxxxxxxxx>,
> > > "G. Michael Paine" <mipaine@xxxxxxxxxxx> wrote:
> > >
> > > > I run a Mac G4/400., OSX 10.4.3
> > > > I am not a programmer.
> > > > But I am curious. Is it possible to view the actual code of any
> > > > application? If there is a difference I mean only to view the code but
> > > > I
> > > > have no desire to access same.
> > > > I would just like to see what it looks like.
> > > > Humor me please, someone.
> > > >
> > > > Michael
> > >
> > > Generally speaking, no, such is not possible.
> > >
> > > Consider a commercial product. Would they want me (and I am a
> > > programmer) to learn how their program works by being able to view its
> > > code? I think not, since that might give away proprietary information.
> > >
> > > OTOH, there are a lot of open source applications. If the application
> > > you use is among those, you may be able to find the source code should
> > > you want to look through it.
> > >
> > > = Steve =
> >
> > So the code is there but hidden within the application and cannot be
> > accessed? Have I got that right?
>
> Yes and no.
> Yes, the application contains *A FORM OF* the instructions that make up
> the program.
> No, looking at it isn't likely to do you much good.
>
> Compare the two snippets at the end of this note. Both of them are the
> same program code. The first one is in "human readable", AKA "High-level
> language" form - specifically, it's in the language called "C". The
> second one is the "assembly code" - the low-level code that gets turned
> into the actual final product. The "final product", called "machine
> code" or "object code" would be a string of random-looking hexadecimal
> numbers - A *LONG* string that looks something like "07C2F8BBA3901D4..."
> - and isn't very useful for us poor stupid humans, but to a computer, is
> a program that actually does something.
>
> For what it's worth, this snippet, regardless of which form it's in,
> does one thing, and one thing only: It creates a window on the screen
> for the user to look at. It doesn't put anything *IN* the window, just
> creates and displays it so that another bit of code has someplace to put
> whatever it is that it's trying to show the user. Also, when looking at
> the second snippet, be aware that *ALMOST ALL OF WHAT YOU SEE* is there
> for the benefit of a human trying to read and understand the code, but
> it doesn't end up in the application. - You'll notice that the original
> code from Snippet 1 is reproduced line-by-line in Snippet 2, with each
> line followed by a mess of "gibberish" - For instance:
>
> OSStatus MakeDisplayWindow(WindowRef *TheWindow, Rect *Bounds, Boolean
> Visible)
> {
>
> is followed by
> 00000000: 7C0802A6 mflr r0
> 00000004: 93E1FFFC stw r31,-4(SP)
> 00000008: 93C1FFF8 stw r30,-8(SP)
> 0000000C: 93A1FFF4 stw r29,-12(SP)
> 00000010: 90010008 stw r0,8(SP)
> 00000014: 9421FFB0 stwu SP,-80(SP)
> 00000018: 7C7F1B78 mr r31,r3
> 0000001C: 9081006C stw r4,108(SP)
> 00000020: 98A10073 stb r5,115(SP)
>
> The line starting "OSStatus..." is my original "C source code". The
> stuff after it that starts "00000000: 7C0802A6", and more specifically,
> the "mflr r0" and "stw r31,-4(SP)" and similar, is "assembly language".
> After the compiler processes my "source code" into "assembly code", a
> sub-program of the compiler, called an "assembler", looks at each line
> of assembly language the compiler has produced from my source code (For
> instance, the "mflr r0" text) and converts it into "Machine Code" - The
> computer's "native language" - That machine code is represented by the
> gobbledygook in the second column from the left - For the mflr r0
> instruction (Which means "move from link register to register r0" - It's
> a "menmonic" - Like "ROY G. BIV" is a mnemonic for the order of colors
> in a rainbow (Red, Orange, Yellow, Green, Blue, Indigo, Violet) the
> machine-code bytes are 7C0802A6. Even at this point, there's a
> good-sized dose of "make it readable for the human" fiddling involved,
> in the form of converting the raw binary string into hexadecimal before
> it gets displayed - What the computer actually sees when the program
> runs isn't "mflr r0", or even "7C0802A6", but
> "01111100000010000000001010100110" - Quite the mouthful, huh? :)
>
> Most (not all, just most) of the programs running today are written in a
> high-level language like C or C++, pushed through a compiler, and come
> out the other end as a string of what looks like gibberish to most
> humans. There are exceptions, of course - Some languages, like Python or
> BASIC, don't get "compiled" - They get "interpreted" - A program on the
> computer looks at each word, number, or whatever, and instead of
> generating a machine-code instruction that gets stored away, it says Oh
> - "X=X+1" means "add one to X", and calls a subroutine to do exactly
> that, repeating the process for easch instruction it encounters
>
> The end result is the same, but arriving at it takes a different path.
>
> Interpreted code is a lot like what goes on at the U.N. - The
> representative from East Elbonia rattles off his speech in fluent East
> Elbonian, and somewhere, at the same time, an interpreter is listening
> to it and deciding what he means, then repeating what he says, only in
> English, Russian, Greek, or whatever. Each time the East Elbonian
> representative speaks, even if he's repeating himself, the process goes
> from start to finish - Listen, translate, speak.
>
> Compiled code, on the other hand, is more like translating a written
> speech - The "source code" (The Elbonian Rep's speech) is converted into
> some other language, written down in that language, then passed around
> as needed - It happens once for each language desired, and then never
> needs to be done again. (unless the speech gets changed, in which case,
> it needs to be recompiled/retranslated)
>
> The major difference between interpreted and compiled languages is that
> for a compiled language, the code only has to be converted once, where
> the interpreted version has to be converted *EACH TIME IT GETS USED*,
> which, as you might imagine, slows running the program down - sometimes
> considerably. The other difference that most people notice is that it's
> usually *RELATIVELY* easy to read and understand the source code of an
> interpreted language directly, while reading the source code of a
> compiled language when all you have is the machine code is often
> anywhere from "a pain in the butt" to "just plain impossible". Sometimes
> this difficulty is intentional, but *MUCH* more often it's simply a
> side-effect of how the compile process works.
>
> Here are the two code-snippets I promised - Read through them carefully
> (keeping in mind that they both do the same thing: create and display an
> empty window on the screen), and I think you'll see why you're being
> told that (for the most part) "looking at code" isn't particularly
> useful or interesting.
>
>
> -Start Snippet 1-
> OSStatus MakeDisplayWindow(WindowRef *TheWindow, Rect *Bounds, Boolean
> Visible)
> {
> OSStatus Result = noErr;
> WindowAttributes Attribs = kWindowCloseBoxAttribute |
> kWindowCollapseBoxAttribute |
> kWindowStandardHandlerAttribute;
>
> Result = CreateNewWindow(kDocumentWindowClass, Attribs,
> Bounds, TheWindow);
> if (Result)
> {
> *TheWindow = (WindowRef)0;
> }
> else
> {
> SetWindowTitleWithCFString(*TheWindow, CFSTR("Display/Preview"));
> MoveWindow(*TheWindow, 10, 45, true);
> if (Visible)
> TransitionWindow(*TheWindow, kWindowZoomTransitionEffect,
> kWindowShowTransitionAction, (Rect *)0);
> }
> return Result;
> }
> -End Snippet 1-
>
>
>
> -Begin Snippet 2-
> OSStatus MakeDisplayWindow(WindowRef *TheWindow, Rect *Bounds, Boolean
> Visible)
> {
> 00000000: 7C0802A6 mflr r0
> 00000004: 93E1FFFC stw r31,-4(SP)
> 00000008: 93C1FFF8 stw r30,-8(SP)
> 0000000C: 93A1FFF4 stw r29,-12(SP)
> 00000010: 90010008 stw r0,8(SP)
> 00000014: 9421FFB0 stwu SP,-80(SP)
> 00000018: 7C7F1B78 mr r31,r3
> 0000001C: 9081006C stw r4,108(SP)
> 00000020: 98A10073 stb r5,115(SP)
> OSStatus Result = noErr;
> 00000024: 3BC00000 li r30,0
> WindowAttributes Attribs = kWindowCloseBoxAttribute |
> kWindowCollapseBoxAttribute |
> kWindowStandardHandlerAttribute;
>
> 00000028: 3FA00200 lis r29,512
> 0000002C: 3BBD0009 addi r29,r29,9
> Result = CreateNewWindow(kDocumentWindowClass, Attribs, Bounds,
> TheWindow);
> 00000030: 38600006 li r3,6
> 00000034: 7FA4EB78 mr r4,r29
> 00000038: 80A1006C lwz r5,108(SP)
> 0000003C: 7FE6FB78 mr r6,r31
> 00000040: 48000001 bl .CreateNewWindow
> 00000044: 60000000 nop
> 00000048: 7C7E1B78 mr r30,r3
> if (Result)
> {
> 0000004C: 2C1E0000 cmpwi r30,$0000
> 00000050: 41820010 beq *+16 ; $00000060
> *TheWindow = (WindowRef)0;
> 00000054: 38000000 li r0,0
> 00000058: 901F0000 stw r0,0(r31)
> }
> else
> {
> 0000005C: 4800005C b *+92 ; $000000B8
> SetWindowTitleWithCFString(*TheWindow, CFSTR("Display/Preview"));
> 00000060: 80620000 lwz r3,@698(RTOC)
> 00000064: 48000001 bl .__CFStringMakeConstantString
> 00000068: 60000000 nop
> 0000006C: 7C641B78 mr r4,r3
> 00000070: 807F0000 lwz r3,0(r31)
> 00000074: 48000001 bl .SetWindowTitleWithCFString
> 00000078: 60000000 nop
> MoveWindow(*TheWindow, 10, 45, true);
> 0000007C: 807F0000 lwz r3,0(r31)
> 00000080: 3880000A li r4,10
> 00000084: 38A0002D li r5,45
> 00000088: 38C00001 li r6,1
> 0000008C: 48000001 bl .MoveWindow
> 00000090: 60000000 nop
> if (Visible)
> 00000094: 88010073 lbz r0,115(SP)
> 00000098: 28000000 cmplwi r0,$0000
> 0000009C: 4182001C beq *+28 ; $000000B8
> TransitionWindow(*TheWindow, kWindowZoomTransitionEffect,
> kWindowShowTransitionAction, (Rect *)0);
> }
> 000000A0: 807F0000 lwz r3,0(r31)
> 000000A4: 38800001 li r4,1
> 000000A8: 38A00001 li r5,1
> 000000AC: 38C00000 li r6,0
> 000000B0: 48000001 bl .TransitionWindow
> 000000B4: 60000000 nop
> return Result;
> 000000B8: 7FC3F378 mr r3,r30
> 000000BC: 80010058 lwz r0,88(SP)
> 000000C0: 38210050 addi SP,SP,80
> 000000C4: 7C0803A6 mtlr r0
> 000000C8: 83E1FFFC lwz r31,-4(SP)
> 000000CC: 83C1FFF8 lwz r30,-8(SP)
> 000000D0: 83A1FFF4 lwz r29,-12(SP)
> 000000D4: 4E800020 blr
> 000000D8: 00000000 dc.l $00000000 ; traceback table
> 000000DC: 00002041 dc.l $00002041
> 000000E0: 80030000 dc.l $80030000
> 000000E4: 000000D8 dc.l $000000D8
> 000000E8: 00122E4D dc.l $00122E4D
> 000000EC: 616B6544 dc.l $616B6544
> 000000F0: 6973706C dc.l $6973706C
> 000000F4: 61795769 dc.l $61795769
> 000000F8: 6E646F77 dc.l $6E646F77
> }
> XRef: Kind=HUNK_XREF_24BIT Offset=$00000040 Class=PR
> Name=".CreateNewWindow"(3)
> XRef: Kind=HUNK_XREF_16BIT_IL Offset=$00000060 Class=TC Name="@698"(1)
> XRef: Kind=HUNK_XREF_24BIT Offset=$00000064 Class=PR
> Name=".__CFStringMakeConstantString"(4)
> XRef: Kind=HUNK_XREF_24BIT Offset=$00000074 Class=PR
> Name=".SetWindowTitleWithCFString"(5)
> XRef: Kind=HUNK_XREF_24BIT Offset=$0000008C Class=PR
> Name=".MoveWindow"(6)
> XRef: Kind=HUNK_XREF_24BIT Offset=$000000B0 Class=PR
> Name=".TransitionWindow"(7)
>
> Hunk: Kind=HUNK_GLOBAL_CODE Align=4 Class=PR Name=".MakeGWorld"(19)
> Size=120
> -End Snippet 2-

Thanks a lot for this explanation. Especially for the explanation of
Interpreted and compiled. I wondered if my BASIC was lacking compiling
now I know it does not.
Now I just need to find a very simple explanation of just what a
microprocessor does and how. I know, Good luck, right? And after that an
idiot's explanation of just what the OS does.
Thanks again.

Regards,

Michael
.



Relevant Pages

  • Re: Seed7 - what is it? What does it do?
    ... The language you use influences the way you are thinking. ... Seed7 is statically typed (which in most languages is a virtual guarantee ... The interpreter does not use bytecode. ... Interpreter and compiler are tools ...
    (comp.lang.misc)
  • Re: Code curosity - long, technical, and probably boring!
    ... For what it's worth, this snippet, regardless of which form it's in, ... of assembly language the compiler has produced from my source code (For ... 00000044: 60000000 nop ...
    (comp.sys.mac.system)
  • Re: to learn jQuery if already using prototype
    ... language is inherently using that process. ... Compiler, then it becomes clearer how to, at least, distinguish the ... An interpreter is defined by *two* things: ... you run the implementation language and give ...
    (comp.lang.javascript)
  • Re: A C Adventure: your comments are welcome
    ... in one language - the source language - and translates it into an ... The root form of compiler and interpreter is a verb and not a noun. ... source code and input and executes the source code. ...
    (comp.lang.c)
  • Re: Help with some VB Code
    ... implementation of a threaded language does not require that it be an object ... or what is called a p-code system. ... VBA does have a compiler, and it does compile it down to a p-code lanague ... As long as you write a p-code interpreter for that platform, ...
    (comp.databases.ms-access)