1) Magic at Borland.
To make a compiler you need a lot of experience and knowledge.
To define a language you need still more knowledge. Actually, defining a good language is way difficult than to make a compiler.
Sure the guys at Borland have some black knowledge we have not! And the guys at MS too, and the guys at AQTime too, and the guys who made Indy too, and etc, etc, etc.
Think about a web navigator: making a good navigator is about reading all the due RFCs, right? Wrong. It is about reading the dues RFCs plus knowing a lot of glitches you can find in the servers around the world. And in the pages around the world. Bad server headers, page tags opened but not closed, bad charset definitions, bad stacked tags and, again, etc, etc, etc. That is black knowledge, that is magic, things you can't get from any book, paper or web page. Only the experience can solve those things.
Now think about making a compiler. Believe me, making a compiler is not so difficult. Making a good compiler, able to compile fast and able to optimize code is a very different thing.
Programmers are specialized professionals. For a guy skilled writing compiler code, making a compiler is easy; for a guy skilled in writing web navigators, writing a compiler can be a daunting, almost impossible task. Same for a compiler skilled guy trying to write a good web navigator.
2) Difference between Borland C++ and another compilers.
Little in the language itself, as C++ is a well stablished language. Pure K&R C or C++ code will compile the same in Borland Builder, MS VC++ or any other compiler for the same platform (at least theoretically).
On the other way, the frameworks are different: MS VC++ uses MFC (Microsoft Foundation Classes) and Borland uses VCL (Visual Component Library). The language is the same, but the pre-made classes you use are different. The MFC Rich Edit is different to the VCL Rich Edit; MFC have a lot of classes VCL have not, etc.
The code generated in not the same either, even for simple sentences, as the optimizations are different.
3) Translating to 0&1 (to machine code?)
The platform is the difference. When you try to open a file, your code calls some OS resource (API function) which is laying there to open files.
The way Unixes open a file is not the same the way Windowses open a file, the functions are not the same, the parameters are not the same, the responses the OS produce back are not the same.
Think about writing a string to the CRT. Long gone are the days where the program itself addressed the video hardware to write a string (imagine the nigthmare: machines may and will have very different video hardware).
To write a string you call an OS API function able to call some other low level code (a driver) which in turn knows how to address the video hardware.
Guess what? The API functions used to write strings in Windows are different to the Unix ones.
Same for nearly everything: wanting to start a timer to tick you every 100 mSecs? The OS is managing the timer. Wanting to print a image? The OS will print the image after you calling the due API function. Your program ended and want to be closed and unloaded? It needs to tell the OS it ended.
At anytime you need to call the OS, you are calling an API function, and any OS have his own API, different from the other OSes.
That is why, even for the same language, you need different compilers for different platforms.
HTH.
buho (A).