Okay, I know that Visual Basic, since version 5.0, has had the option to compile to Native Code? What exactly does this mean... I thought it meant that a build of that type would generate a stand alone executable, rather than the previous method of compiling to P-Code which then required the presence of the Visual Basic runtime libraries to interpret execution. The reason I'm asking is I just compiled a project in Visual Basic 6.0 using the Compile to Native Code option, but running the EXE on my test-bed machine gives me the error "A required .DLL file, MSVBVM60.DLL, was not found". So what's the deal? Why do I still need the runtime libraries? Does compiling to Native Code offer nothing more than back-end optimization? Is the language still interpreted? That particular DLL alone is 1.32MB!?!?!?! I'd really rather not have to jam that into my install and require users to waste time downloading it, my executable is only 32K for Godsake. If anyone can explain this to me please... * Before anyone flames me for using Visual Basic in the first place, for this project I was required to program in VB, if I had a choice I would have stuck with Delphi, but I'm not calling the shots here... Edited by - Xorcist on February 28, 2001 9:00:42 PM

VB is still partially interpreted. You will need the runtimes whatever you do. Also, it''s a bit like MFC, VB is so simplified that the extra code has to go somewhere, so there are a couple of runtime DLLs that it needs.

I think you could probably eliminate the need for the runtimes by subclassing and only using API calls, but then why bother with VB, you might as well use C (or Delphi I guess, I don''t know anything about that though).

You can zip the dll by a fair bit, so it''s not quite as huge as it seems at first. Still a pain in the arse though

Harry.

I heard that the VB runtimes would come preinstalled with Win2k, but I never heard any confirmation. So you may not need to distribute them to Win2k users.

Harry.

Native compile still requires msvbm60. And I may be wrong about this (quite possibly) but I think that code generated by VC++ also requires a dll or two. The difference is that the VC++ dlls are on all Windows machines, so it doesn''t matter.

Win2000 does have the runtimes I think. Actually, I too haven''t got any confirmation, since I have just realised that all the computers I know with Win2000 have VB on them anyway =)

Thanks for the info guys... guess I''m outta luck, oh well... that''s Microshit for ya. Like I said, if it were up to me I''d be using Delphi, unfortunately it''s not.

Sounds kinda like my situation with my IT class. We have to use Delphi, if it were up to me, Id be using C++.

Oh well, Delphi is still a damn lot better than being forced to use VBasic.

Whenever I hear someone mention "VB" I think of beer, its a lot better and has more uses than VBasic.

The difference between DLLs used by VC++ apps and VB apps is that VC++ apps don''t depend on DLLs that are 1.4 Megs in size. The DLLs that VC++ apps depend on are commonly found on any windows system. KERNEL32.dll, ADVAPI32.DLL, MSVCRT.DLL, USER32.DLL, etc. These are common to all Win32 platforms.

So that''s the major difference, IMHO, and that''s why I dropped VB in favour of VC++.

When you write a VC++ program, it links to MSVCRT.DLL and maybe MFCRT42.DLL (or something, but that''s only if you use MFC.) MSVCRT.DLL is microsoft''s implementation of the C runtime (it has the printf, fopen, etc functions)

A VB program links to MSVBVM60.DLL, which is the Visual Basic runtime. So it includes all the functions you call in VB that you haven''t written yourself (I don''t know VB, so I can''t give examples)

The reason it''s 1.4MB and MSVCRT.DLL is only a few KB is that Visual Basic hides a lot of the windows code from you. That code still has to go somewhere, so it''s in the runtime. Also, MSVCRT.DLL is included with windows, since all the apps you get with windows (notepad, paint, etc) use it.

So, even though your VB project *is* compiled to native code, it still needs the runtime DLL - just like a VC program needs its runtime.

Those other DLLs that VC programs link to, KERNEL32.DLL USER32.DLL, GDI32.DLL - those are part of the windows kernel. They handle memory management, window management and passing messages around, and displaying things on the screen. Everything links to them, no matter what they''re written in.

Also, I can confirm that MSVBVM60.DLL is included with win2k, since I have it on my machine, and I don''t have VB installed.

That''s what I meant, what he said *points up*

Harry.

Yeah, I have all of the VB files preinstalled with Win2K (I don''t use VB, either), so I can add another confirmation on that. I highly suggest you use Delphi instead of VB, or C/C++ instead of either of those. Some ASM thrown into the C/C++ code and you''re at the peak . I don''t know too much ASM (for x86 at least, I know some other CPU''s ASM) though, I''m still picking it up.

Anyway, just offer the DLL''s as a seperate download for those non Win2K users and it isn''t so bad.

"Finger to spiritual emptiness underlying everything." -- How a C manual referred to a "pointer to void." --Things People Said

http://www.gdarchive.net/druidgames/