Fog Creek Software
Discussion Board




What's the point of run-times?

Hi,

I've always wondered why Visual Basic needed a run-time, even since a compiler was introduced (with release 5?) while PowerBasic or VBC++ offered a way to compile run-time-free EXEs.

Why didn't MS offer a way to compile real EXEs?

Fred.

Frederic Faure
Sunday, September 01, 2002

Probably because they would need to introduce some kind of intelligent link which would cost more in development time for them.

Most VB stuff is for corporates who will have distributed the run time once anyway. In fact I think you'll find you get it with later Windoze or Office installs anyway.

Tony E
Sunday, September 01, 2002

Thx, but the question: what's the advantage of using a run-time-based env't instead of run-time-free tools like PowerBasic or VC++ ?

Fred.

Frederic Faure
Sunday, September 01, 2002

Frederic, neither PowerBasic nor VC++ are runtime-free. Granted, PowerBasic doesn't use an *external* runtime, but it has one just the same. Just watch the compiler output when it tells you how much of the runtime is being linked in. The amount changes based on which language features you use.

Also, ever heard of MSVCRT.DLL? That's the Microsoft Visual C++ Runtime. By default every app you compile with MSVC++ is going to use that runtime. You can avoid it by implementing a couple functions inside your app (such as _WinMainCRTStartup), but then you have to avoid all runtime functions as well. It can be done, but it's generally easier to just use the runtime functions.

The advantage to runtime-required languages is usually the amount of functionality the runtime itself contains. Think about all the window-handling code you *don't* have to write with VB. Could MS make the VB runtime statically linked? Of course they could. I could never figure out why they didn't offer the option either. I know some folks have hooked VB's compile process to alter it; I wonder if a bin2lib converter and an altered VB compile/link would let you do it?

There are a couple tools here and there that claim to do that for you... extract the relevant portions of the runtime and statically link them with your app There are also DLL remapping utilities (like Jeremy Collake's PEBundle) that will combine the DLL with your exe so you can distribute a single file rather than the mess of runtimes and external controls.

I'm one of those people that Joel refers to as a "neat freak." I like small apps with low memory requirements. For that reason, I love PowerBasic. The one thing I *don't* like about PowerBasic is that I have to mentally convert documentation written for C programmers (MSDN, every book ever written) to PowerBasic (and remember the conversion rules) to do anything that's not built in to the language. Given the sheer amount of stuff that's built in to the language, though, I guess it's not as bad as it could be. I generally use PB for quick apps (especially where I need network code in a hurry), but C for my bigger stuff so I get the benefits of all the tools that have been written for C. That's the two big things that keep me from using PB 100% of the time -- the mental gymnastics required for doc converting, and the lack of professional source code utilities. I was a PB nut for about three years, but find I have drifted away from it as I began to value the mental ease of writing in the same language the docs are in.

But in both cases, there is a runtime involved, so your question itself isn't entirely correct.

Troy King
Sunday, September 01, 2002

"Also, ever heard of MSVCRT.DLL? That's the Microsoft Visual C++ Runtime. By default every app you compile with MSVC++ is going to use that runtime. "

Surely you can simply avoid this by using one of the statically linked versions of the RTL? And if, which God forbid, you are using MFC, you have the choice of statically linked or dynamically linked versions of that too.

Isn't the obvious benefit of the run-time option that it makes for smaller executables, and uses less disk space if more than one application uses the same run-time library?

Andrew Simmons
Sunday, September 01, 2002

Well you know computers, another layer always has a use. What about bug fixing - if you botch the compiler (say some security thing) and it goes right to machine code, then you have to patch every program ever made with it. If you botch the runtime, you can just patch it. and then patch it again. and then again. and another patch... Well, better the runtime than all things installed anyway. Or all things that were made with that version of the compiler is more like what it would be -- oh, did you patch that for the 2.0231 compiler??! Oh no, that program was made with the 2.0236 Borland compiler, and that patch gums it up! Quick download the 2.0231 repair patch!

Does that make sense? Or are you not meaning going right down to the machine level?

Robin Debreuil
Sunday, September 01, 2002

Frederic,

http://www.mvps.org/vb/hardcore/html/efficientcode.htm - from http://www.mvps.org/vb/hardcore/ - should get you started. Click on the >> on the top right to read the next few pages as well.

Thanks

Matthew Wills
Sunday, September 01, 2002

Andrew, of course you're right that if you're just trying to avoid shipping the extra files, static linking is the way to go (which is why I mentioned static linking several times, but that wasn't really the point of my excessive rambling, which didn't really have a point). I also wondered how long until someone would bring up the dreaded MFC library :). It makes my skin crawl just thinking about it.

My opinion is that if you're shipping with a runtime or external dependencies, then you might as well use the easist language that gets the job done, which is going to be VB most of the time. When I go to a "more difficult" language, it's usually to be able to ship no- or low-dependency apps.

Frederic, the very question you're asking is the question I started asking a few years ago, and the one that finally got me away from using VB for anything a customer saw. (I still remember them freaking out that a narrow-purpose Windows app I gave them was only 17K complete -- they thought they'd made a mistake and hired someone that didn't know what he was doing since the predecessor app was 16MB.) If you get lucky, you'll work somewhere that you can convince them that small and standalone is beautiful.

Troy King
Monday, September 02, 2002

Robin, it's been a long time since I've heard of a security risk (or any problem for that matter) caused by a Windows compiler. It's usually the code written by the programmer, not the tool he uses to compile it. There are fairly boilerplate methods for writing secure code, and I must admit it's a grunt aspect of coding to follow the list for every function. I could be wrong with this, but I believe most security problems found lately that are vaguely compiler-related have all actually been in the MSVC runtime itself.

Troy King
Monday, September 02, 2002

"I believe most security problems found lately that are vaguely compiler-related have all actually been in the MSVC runtime itself"

Yeah, I was just thinking that if there were no runtime, than that error would be in your program rather than the runtime. I guess I meant compiled into your code - a compiler error would get you either way. I still am probably missing the point though : )

Robin Debreuil
Monday, September 02, 2002

*  Recent Topics

*  Fog Creek Home