Basic code.. Decompiling & Compiling- Little hlp?

[Shorty]

Yo- I got an old Dos program running in a window. It is a VERY SPECIFIC database software. There is a function it doesn't have, that is just a slight modification of one that's already there.

HOW DO I GET INTO THE SOURCE CODE??

I am running XP SP2... and it appears I don't even have "DOS Shell" on here.

Do I need DOS Shell or Basic to open and edit this bad boy?

Years ago in high school and votech I messed around a lot in basic and wrote a couple text based games... even some with some corny text based graphics. So my basic understanding of the code itself is cool.... I just need to get in there.

Any help?

PLEEEEEZ! Much Luv & Thanx

I'll hang here for a few minutes

shorty
612.385.5488 cell
1.877.703.6233 toll free to cell

[Ildûrest]

I don't think there is any source code, sorry. It depends on the program... if it's compiled (.EXE) then you won't ever get the BASIC source back unless you find the person who compiled it and they still have it. That's assuming it was written in BASIC which is not necessarily the case.

So sorry, nope.

Compiling is a bit like translation into a language that has a limited vocabulary. It can do everything, but it lacks things that make it easy to understand. Decompiling gives you a weird mess that is nothing like the original source code, but when recompiled still works. Decompiling into BASIC is for all practical purposes impossible.


In terms of XP SP2 - Windows comes with a DOS emulator (NTVDM - NT Virtual DOS Machine, under Windows NT, 2000 and XP) that lets you run DOS programs. There is a DOS command prompt (command.com) and also a Windows command prompt (cmd.exe); the Windows command prompt is a Windows program which lets you do very Windows things (like starting new independent processes with the START command), but I'm getting sidetracked.

All NTVDM provides is an environment for DOS programs to run in. As your program appears to be a DOS program, it would need a decompiler for DOS programs (which are inherently quite different to Windows programs and programs for other operating systems).

If you have any other questions please ask.

[earlofqb]

Aww, Mik didn't even mention the part about commercial decompilers decompiling the code to Assembly and all that.

Don't trust the "decompile to C" ones either, they rarely work in a way that someone without a PhD in computer science could understand.

[Homeloaf]

I've always been curious about this.

If you write something in Qb and then compile it, what would happen if you used a Microsoft decompiler of the same general time period and version? Or does Microsoft even make decompilers? Hmmm... Could you get even a rough version of the source?

[Mikrondel]

I haven't actually heard of any Microsoft decompilers...

In any case, all programming languages (bar things like assembly and machine code) add layers of abstraction to giving a computer instructions. These layers vanish when compiled.

For instance, to control program flow, machine code mainly uses something much like GOTO. In other words, FOR-NEXTs, DO-LOOPs, and even IF-THENs are all made up of the rough equivalent of "IF xxx THEN GOTO yyy". It's tricky but possible to turn stuff like that into BASIC spaghetti code - but extremely tedious to work through it and find out what all the jumps are for -- don't forget, variable names are lost, and obviously indenting and comments are gone.

You can get (usually for a price) more sophisticated disassemblers that try to recognise control structures for you, but they're not foolproof (the Basic Compiler is an optimising compiler after all, meaning it leaves out and takes shortcuts and simplifies as much as possible and therefore the code generated by a specific command can differ with circumstances, making decompilation MUCH harder). Obviously similar stuff applies to C, but as C isn't as abstract as BASIC it's not as bad to decompile into. And of course because C is so popular, (especially in the open source community), you can get free C decompilers without too much trouble.

Disassembling to assembly language is usually a piece of cake, however, and you more or less get back the original assembly language - of course, bar comments - but obviously assembly language is still terribly tedious to work with.

[buff1]

Closest thing to a decompiler is probably MS debug.