 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> ...and as a
> matter of fact it is /not/ part of the real .cpp and .h source code
> files. They just contain the raw uncolored text.
>
Ah, so that's why the code looks somewhat 'different' in, say, POV-Ray vs.
Windows' basic Notepad.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/6/2013 1:09 PM, Le_Forgeron wrote:
> Le 06/02/2013 20:30, Kenneth nous fit lire :
>> Not how to 'understand' source code ;-)
>>
>> Just wondering what kind of little Windows app I could download to actually
>> *see* (take a look at) the source code for a program (well, one that has
>> publicly-available source code, anyway--like POV-Ray.) I've never thought of
>> doing so before now, and don't know what's involved. Not to EDIT the stuff, or
>> compile/recompile it; that's way beyond me.
>>
>> From what I've read, some 'text' editors can do this. Or would it require a 'hex
>> editor'? Or perhaps something like Notepad++, which apparently can open and
>> display programs written in C, C++ etc?
>>
>
> Any text editor (not wordprocessor) should do.
> You might enjoy an easy to use search function (just to spot all the
> occurrence of a variable, or finding a function)
> An optional line numbering might help too.
>
>> What I would basically like to do is see the code the way the original developer
>> saw it, while writing it (in whatever programming language that happened to be.)
>> I might even learn a few things!
>
> <start holy war>
> * PFE (programmer's File Editor)
> * use eclipse with C/C++ or Java setting
> * use Microsoft Visual Studio (or whatever its name), if available as
> free edition on your OS (IIRC, MSVC 2012 need something like Vista or 7
> and won't install on XP)
>
Scite/WScite
Its got something for nearly every bloody language possible, and now
supports its own scripting using Lua, for which someone else made..
scintalua, or something like that. Basically, a "prebuilt" dll, which
extends Scite, so that you can slap together a simple lexer, to color
code, and such (documentation could use some work, and a few things I
never did work out while trying to create something for use with LSL
(Linden Scripting Language), so, if there is something it doesn't
support, its fairly easy to patch so it can.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/6/2013 4:19 PM, Kenneth wrote:
> Off-off-topic: While I was doing my research into this stuff, I read about 'hex
> editors.' Apparently they can open an executable (.exe) file for editing?? (Not
> in a higher-level language, of course.)
>
Well, yeah, and no. Its not going to be "readable" in any real sense.
Way back, like the 80s, you could find some "decompilers". The concept
meant one of two things. Some fairly good ones could "guess" at whether
your program, based on clearly known factors, like how branching was
done in certain compilers, and internal naming conventions (if you
looked at an EXE in an hex editor, or even something else that could
read it in well enough, you would find a mess of words, names, etc. in
many of them, that you where using say Borland C, and then "rebuild" the
source code, minus the original names for variables, and such. In many
cases, a final compile, with all the "debug" data removed is/was never
done, so "some" labels, variable, etc. might still be in those things,
even in modern applications.
This is especially true with certain dlls, since they expose "entry
points", which, in principle, you can look up by asking the dll, and
some applications include entry points as well. Explorer, for example,
functions both as a "stand alone", as part of the OS, and as something
you can "attach" to your own program, ask for entry points, and then use
those to talk to its own code, when loaded.
Less sophisticated ones, and even DOS' own little machine language
utility could "sort of" do this, for very small programs, would just
generate a machine code version, with what ever data you could get out
of it.
I am sure there is, out there some place, applications that could pick
apart an EXE and come up with something "close" to the original,
possibly even in the same language it came from. But.. there are obvious
legal issues with such tools, so finding one, at all, never mind a
really good one, might be really hard today.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hey, this is really fantastic! So I downloaded POV-Ray's 3.62 source code, and
> it shows up in Windows Notepad, EditPadLite--even in POV-Ray itself! (I think
> the latter is my favorite 'reading platform' so far.)
>
> Thanks to everyone who posted about this. I didn't know it was so easy.
>
> Hey, there are LOTS of separate source code files for POV-Ray! Where to begin...
> I naively thought that *whatever makes POV run* would be just one big file. Am
> I correct in thinking that the program's source code is actually split up into
> lots of little (therefore manageable) chunks?
Watch out - soon you will want to just change something and then
recompile to get your own custom povray.exe :-)
> One other thing: Does POV-Ray (or any of the other text reader apps I mentioned)
> need ...uh... built-in 'code libraries' or something, to show *correct*
> C/C++/whatever syntax?
They need a list of words that are specific to that language, and some
"rules" about the syntax of the language. If you open the file in
notepad you'll see it's just plain text, something like povray or
notepad++ interprets this plain text and makes it more human readable.
Some of the more advanced editors (eg the one in MS VisualStudio) help
you even further when editing by figuring out what valid text you could
possibly type next and give you that list to choose from, underlining
errors in real-time and giving pop-ups with required parameters for
functions etc.
> Off-off-topic: While I was doing my research into this stuff, I read about 'hex
> editors.' Apparently they can open an executable (.exe) file for editing?? (Not
> in a higher-level language, of course.)
Of course (*any* file is just an array of bytes), but what do those
bytes mean? In the case of a .exe file there will likely be data
portions in a non-human-readable format and code which will be in the
form of byte-code for the CPU - it's not recommended to edit or even
view this byte-by-byte.
The best you can really do is to use a "disassembler" that will take the
code in the .exe and convert it to human-readable instructions for the
CPU (eg things like "load variable X from address Y", or "add X to Y").
This is still very low level (no useful variable names or function
names) and will take an order of magnitude more time to figure out
what's going on compared to the source code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It has been a long time since I've made so fundamental(!) and exciting a
discovery as this. Those who already know what source code is may not truly
understand my elation. I feel like I've suddenly climbed to the top of a very
tall mountain--and can finally see the wondrous and vast mountain range
stretching before me, just waiting to be discovered.
The POV-Ray newsgroups are great!
The root of my *long-term* basic misconception (of not realizing that source
code is a simple text file, AND WRITTEN in a text editor) is this: I thought it
needed to be written in some kind of special 'source-code' program or
environment--and linked in some way with C/C++ code libraries or some such, to
make even the writing process work. Admittedly a funny/goofy concept, now that I
understand what the truth is. (I'm leaving out the compiling or interpreting
process, that's a different thing.)
In going back over the info in some of the web resources that I looked at prior
to my post, I see that 'source code as text' *is* mentioned, fairly often. I
probably did understand that part of things, if only in a vague way. But
apparently it wasn't enough to *trigger* an ultimate understanding. Funny thing
is, I never came across anything that said, "...and you can read and write it in
a simple text editor. It's just text, dummy!" ;-)
Oh, and I'm now making other conceptual connections: I recently bought an
Arduino Uno board. Haven't done much with it yet--but coding for it IS just a
simple matter of writing text, in any old text editor (in a subset of C, which
is then compiled.) But *again* I thought the Arduino code-writing environment
was a 'special case'--purposely made easy for end users, to 'hide the ugly
details.' NOW, I realize that what I'm doing is writing...source code! I don't
think this is actually mentioned in the (one) Arduino book I have.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.02.2013 20:35, schrieb Kenneth:
> The root of my *long-term* basic misconception (of not realizing that source
> code is a simple text file, AND WRITTEN in a text editor) is this: I thought it
> needed to be written in some kind of special 'source-code' program or
> environment--and linked in some way with C/C++ code libraries or some such, to
> make even the writing process work. Admittedly a funny/goofy concept, now that I
> understand what the truth is. (I'm leaving out the compiling or interpreting
> process, that's a different thing.)
While being funny & goofy, the concept isn't /too/ far-fetched. For
instance, Visual Basic for Applications has some traits that go in that
direction.
Real programmers have always scorned the idea though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It has been a long time since I've made so fundamental(!) and exciting a
> discovery as this. Those who already know what source code is may not truly
> understand my elation. I feel like I've suddenly climbed to the top of a very
> tall mountain--and can finally see the wondrous and vast mountain range
> stretching before me, just waiting to be discovered.
>
> The POV-Ray newsgroups are great!
>
> The root of my *long-term* basic misconception (of not realizing that source
> code is a simple text file, AND WRITTEN in a text editor) is this: I thought it
> needed to be written in some kind of special 'source-code' program or
> environment--and linked in some way with C/C++ code libraries or some such, to
> make even the writing process work. Admittedly a funny/goofy concept, now that I
> understand what the truth is. (I'm leaving out the compiling or interpreting
> process, that's a different thing.)
There *are* tools that work this way. They are often called RAD (Rapid
Application Design) tools and will allow you to drag and drop Windows,
buttons and list boxes, and auto-generate code in the background. By
right-clicking on each of those, you can modify some or all of the
underlying code. This is usually used to create front-end apps for
entreprise databases, but the underlying code will tend to be a jumbled
mess.
Kind of like using Moray or Blender to generate POV-Ray SDL.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth <kdw### [at] gmailcom> wrote:
> The root of my *long-term* basic misconception (of not realizing that source
> code is a simple text file, AND WRITTEN in a text editor) is this: I thought it
> needed to be written in some kind of special 'source-code' program or
> environment--and linked in some way with C/C++ code libraries or some such, to
> make even the writing process work. Admittedly a funny/goofy concept, now that I
> understand what the truth is. (I'm leaving out the compiling or interpreting
> process, that's a different thing.)
There are, in fact, many types of programming languages in this respect.
The two oldest, and most common ones, are compiled languages and interpreted
languages.
A compiled language is (usually) written in ASCII text with a well-defined
syntax, and then a compiler program is used to (basically) convert those
instructions into equivalent machine code, which are bytes that the CPU
directly runs. (The nitty gritty details are actually much more complicated
than this, especially because of how operating systems work, but those are
not very relevant for the purpose of understanding what a compiled language
is.)
An interpreted language is not compiled into anything. Instead, the
"compiler" (which in this case would be called an interpreter) instead
just executes the commands as it parses the source file. (Again, the nitty
gritty details are much more complicated than this, but irrelevant at this
conceptual level.) So-called scripting languages are almost always
interpreted.
Then there's a kind of third category, where a language is actually
compiled, but not to native machine code, but to a more hardware-independent
"byte code", which is then "interpreted" by a runtime environment. (This
is kind of a mix of both techniques. The source code is compiled into
"machine code", but not the machine code of the CPU, but a more abstract
one. This custom "machine code" is then interpreted by a program which,
technically speaking, is an "interpreter". It kind of acts like a CPU,
but rather than being a physical CPU it's a program that "emulates" one.)
Of course it can get even more complicated than this. The most advanced
runtime environments will compile the "custom machine code" into actual
machine code of the CPU on the fly, for speed.
(Why not compile from the source code directly to the target CPU, you
might ask? The advantage of using "custom" machine code is that the exact
same program can be run on any computer that has the proper runtime
environment. Interpreting the custom machine code is much faster than
interpreting the original source code directly.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BTW, my 'computing' and basic code-writing experience goes way back--first in
college, in a single introductory course, writing 'batch process' programs for
an IBM mainframe using punch cards(!) and Fortran IV; then with a Commodore VIC
20, then a Commodore 64, probably using BASIC.
Yet in ALL that time, I don't think I ever heard or knew of the concept of
'source code.' Or even heard the phrase! (If I did, it was just one more
*arcane* computing term that made no sense at the time, as that 'introductory'
college course was WAY over the heads of most of the students, almost like a
philosophy course taught in a foreign language. Yet the programming itself was
easy.)
Actually, it has only been while using POV-Ray (and visiting the newsgroups)
that I've been made aware of what source code even *is*.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 06 Feb 2013 14:30:25 -0500, Kenneth wrote:
> What I would basically like to do is see the code the way the original
> developer saw it, while writing it (in whatever programming language
> that happened to be.)
> I might even learn a few things!
You have to be given the source code to see it this way - and that would
be in text format.
There /are/ decompilers available, but they won't tend to include
comments or even necessarily variable names the way the developer wrote
the code.
If you have code from a complex program, I have found Source Navigator NG
to be useful in dissecting the code to read and understand it - it's an
open source tool (don't know if there's a Windows or Mac version, but it
probably can be built for those platforms as it is open source itself).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
