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

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-

--
Don Bruder - dakidd@xxxxxxxxx - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info
.

Relevant Pages

  • Re: Code curosity - long, technical, and probably boring!
    ... > the second snippet, be aware that *ALMOST ALL OF WHAT YOU SEE* is there ... > of assembly language the compiler has produced from my source code (For ... > Elbonian, and somewhere, at the same time, an interpreter is listening ...
    (comp.sys.mac.system)
  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: access(FULLPATH, xxx);
    ... with "trial& error" to just silence the compiler. ... void *foo); ... given that the language in the specification _was_ abiguous and both ... documentation was paramount. ...
    (freebsd-questions)
  • Writing a Roguelike in D, C# and C++
    ... Since I have seen some interest on this newsgroup about which language ... The official compiler is dmd. ... The roguelike I am writing uses variable sized glyphs. ... trigger Hejlberg's garbage collector. ...
    (rec.games.roguelike.development)