VB Win32 API vs C++ Win32 API

OK, I talked about coming into C++ from VB in another post and it got me thinking about all the times I used API in VB to make it do all the things it can't do (well pre .net VB .net can do allot of those things cause MS was like look at all this code they are making to do cool stuff lets steal it... well except I'm sure they did it in C++) and I was thinking wow I used to spen hrs doing

Code:

---

Declare APIFunc Lib SomeDll () as someType

---

i even bought big expensive books on the subject and learned how to convert C++ data types to VB and how to dig through headerfiles and read C++ code and figure out how to use the API man I should have just been using C++ to start with i mean 5 hrs to make a module and suerclass the api subclass any that need a address of func and in C++ i just go

Code:

---

#include <windows.h>

---

ahhhhhhhhhhhhhhhh who knew

Hehe, I never used VB. I don't want to use it, but this is because I don't like the looks of VB code. Being able to include files would be a good idea for VB, maybe it is possible since every other language can do it! M$ should release a VB header file where all those Declare things are already inside, but they won't do it because they like .net more.

VB Code:

Option Explicit
Option Base 0
Reference "windows.bas"

would be kind of cool. Then they could seperate the language from the object model, and then you could write straight API apps with VB that need no run-time, or choose to use the VB object model, and need the run-time.

Although with .Net MS doesn't seem to want us to use the API at all...

One reason might be that win32API is very much functional programming and .NET aims on object orientation

VB is tightly integrated to it's IDE since there is only one compiler for VB, it's very possible and as M$ want's to avoid disefficiency of unnessesary complication in VB.NET it stays as a RAD tool. You just add the files into the project, add the references and controls, trough the IDE.

However, if you don't want to use the IDE, try opening the vbp file in notepad.

i have found that i like C++ much more than VB. I like that i can easily switch the IDE and the OS, where you can't with VB. I also like the fact that there are no runtimes. I used VB for a week or so, and thats when i found this website. Now i mainly use C++.

If you really wanted all of the Windows functions, structures, and enumerations, you could create a VB .bas file, and insert the text from the Win32API.txt file that is included with the WinAPI text viewer.... Then again, that file is ~650 kb, and it would bloat your app like a mo fo =).

Z.

Quote:

---

If you really wanted all of the Windows functions, structures, and enumerations, you could create a VB .bas file, and insert the text from the Win32API.txt file that is included with the WinAPI text viewer.... Then again, that file is ~650 kb, and it would bloat your app like a mo fo =).

---

That's not really what I meant though.

Quote:

---

I also like the fact that there are no runtimes. I used VB for a week or so, and thats when i found this website. Now i mainly use C++.

---

What's the definition of a run-time? What's interesting is if you look at drivers in dependency walker. It makes it look like Win32 is a run-time, or at least an abstraction layer over the OS kernel.

Win32 is a collection of DLLs that contain all of the functions required for Windows to run. So, yes, technically, it IS a runtime. BUT, you, to programmer, do not have to distribute kernal32.dll, or any of the other base windows dll files with your program, because they are already present. On the other hand, VB runtimes contain functions that some VB programs MIGHT use, but are REQUIRED for the program to run. Here is the problem. You must include 2.something megabytes of functions that you probably dont actually use in your program. Also, VB makes small exe files, but C++ can make even smaller (a simple test with a single module, and no form, sub main msgbox "..." end sub, spits out a 16kb exe, while parksie has shown us a 2kb program that does the same thing). So, the VB runtimes are a huge waste of space. This is the complaint that most everyone has against VB (and that it is slow...)

Z.

Quote:

---

Originally posted by JoshT
What's the definition of a run-time? What's interesting is if you look at drivers in dependency walker. It makes it look like Win32 is a run-time, or at least an abstraction layer over the OS kernel.

---

I guess you could technically say that it requires runtimes, but, as Zaei said, it's not like you have to distribute them with your program You know that they will have to have kernel32.dll or they don't have windows!

Quote:

---

So, the VB runtimes are a huge waste of space

---

I disagree. I think it's more efficient to put all of VB's extra functions into one dll rather than have to compile the functionality into every vb app.

What's interesting is that Kernel32.dll, NTDLL.DLL, MSVCRT.DLL, and NTOSKRNL.EXE all seem to export functions similiar to the ANSI C string functions. And I was under the impression that on NT+, the POSIX, OS2, or 16-bit (WOW?) subsystems are alternatives to Win32, not a part of Win32.

They export things like that so that you can save space by using those rather than linking them in from the standard library.

In a lot of cases you don't need the C(++)RT, you can use the API functions.

I was under the impression that all the standard library does is go and call the respective api calls of the OS its compiled for (and provides a consistent cross-platform C). Also, that under *nix, the standard library pretty much is the OSes API (C was invented to program Unix with).

Another question: if you call, say "lstrlen" from kernel32, does all that do is call the respective function from ntdll, then that calls it from the kernel? (Though there'd be ASCI and Unicode handling in there somewhere).

It can do whatever the library developers want it to do :D

If you call strlen from the library, it'll call a version IN the library in most cases. If you call lstrlen, then it'll either call lstrlenA or lstrlenW from the DLLs depending on your compiler options (look at the headers).

The library is to give a consistent interface, not consistent implementation.

If you want to distribute your app, you have two choices. You can distribute the VB runtimes with your app, to accomodate any users that dont have them already, or crewate two installations, one with runtimes, the other without. The first wastes space, the other wastes time (updating two installations takes more time, obviously).

Z.

Quote:

---

If you call strlen from the library, it'll call a version IN the library in most cases. If you call lstrlen, then it'll either call lstrlenA or lstrlenW from the DLLs depending on your compiler options (look at the headers).

---

Ok, that makes sense. But I'm thinking, for file i/o and such functions, they would have to go thru the OSes API, as per the kernel's security model (NTFS permissions, etc).

I think what's confusing me is that Windows is actually two different base operating systems (NT x or 9x), and the Win32 API is consistent (mostly) between them.

Anyway, I'm thinking too much. My current project I'm working on is in Perl...:D

The CRT will normally pass through to CreateFile which degrades gracefully under 98.

Actualy if you use fusion to inject the runtimes into the exe (recompile it via assembly) the exe is actually smaller than the original exe and needs no runtimes. :) works I have tested it a few times Fusion is about $200 so it sucks if you are just a small time guy but if you work for a company bug your boss right :)

The main diffrence betwen WIN 16 bit /95/98 and NT is that the first 3 re ANSI and use SendMessageA and so on where as NT uses SendMessageW but this is not a real issue unless your API has a problem listed in MSDN or the knowledge base because under NT SendMessageA is a wrapper function that points to SendMessagW. Proccess and Threades require a little bit of

Code:

---

#IF WIN32 THEN
.....
#ELSE
.....
#ENDIF

---

or something like that, I never messed with it always just check the msdn and see if there are any known issues if there are I try an older version of the function our use several other API function to do the job it could have

the main problem I have had is taking a vb string and puting it into a api and getting a big fat GPF ........

Quote:

---

Actualy if you use fusion to inject the runtimes into the exe (recompile it via assembly) the exe is actually smaller than the original exe and needs no runtimes. works I have tested it a few times Fusion is about $200 so it sucks if you are just a small time guy but if you work for a company bug your boss right

---

I tried Fusion once, I couldn't get it to work right.

Anyway, on my intranet that I develop for, I can guarantee that everyone has the VB runtimes installed (all NT/2000, they came with 2000, and one of the NT service packs installs them, and you have to be at a certain NT service pack level to guarantee that all the APIs would work right anyway).

parksie, have you seen this article? Its quite interesting, but probably a source of some of my confusion.
http://www.sysinternals.com/ntw2k/info/ntdll.shtml

Any API function that uses strings SHOULD have an ...A version and a ...W version. The A version is the ASCII char version, which takes in strings in which each character is 1 byte long, while W version take in UNICODE strings, in which each character is 2 bytes long. Then, in C++, microsoft will use a macro to change which function is called depending on whether you are using Unicode or not. VB probably does this too, except that it probably always uses the Unicode versions (VB strings are Unicode).

Z.

Quote:

---

Originally posted by JoshT
parksie, have you seen this article? Its quite interesting, but probably a source of some of my confusion.
http://www.sysinternals.com/ntw2k/info/ntdll.shtml

---

I have seen it before, but didn't pay much attention due to not using NT at home (would have used 2k but no hardware support) and I use Irix at work, so it's marginally irrelevant :D

I remember it looked a bit useful though.

Quote:

---

Originally posted by parksie

In a lot of cases you don't need the C(++)RT, you can use the API functions.

---

How?

For example, malloc can be replaced with a call to HeapAlloc, strlen by lstrlen, and so on.

What provides HeapAlloc, lstrlen.

Why is the msvcrt not now redundent?

They're provided by the API DLLs, like kernel32.dll rather than the runtime DLL (msvcrt.dll).

Just replacing those two won't negate the need for msvcrt, you'd have to replace EVERYTHING in it - although some things in the library aren't directly supported by the API. For example, to remove all the dependencies you wouldn't be able to use much of the STL without defining your own allocator template (fun :D).

Does Visual C++ implement ANSI C++ Standard fully.
If you cannot use STL without accessing the runtime would that not mess up the cross-platform compatibilty.

As soon as you access the API it goes out of the window. The only reason to do it in most cases is to reduce the final .exe size. You can do things with the preprocessor to use a custom allocator (i.e. call HeapAlloc) on Windows, and revert to the default (which probably uses new) on other systems.

I'm not quite sure what you're getting at.

Parksie.

What I am saying is that:
If you build a process that is to ANSI standard (No WinAPI) and you use the STL, Would that then have to reference the MSVCRT and therefore make your process non ANSI.

I expect I am talking crap here but I write in C on NIX don't use the STL.

Could you explain a little on the STL, like why if it is part of the ANSI standard you have to use the MSVCRT.DLL.

Thanks for the help

A process being non-ANSI doesn't make any sense.

Your source code will be standards-compliant if you don't use the API, but obviously once it's compiled all that becomes moot because you're locked to that platform due to it being compiled.

MSVCRT.DLL is part of the implementation. The standard only guarantees the existence of different classes/functions that have defined behaviour. It doesn't define HOW they're implemented.

So, you could have the string class on MSVC, and you compile it using the RTL in a DLL, so it'll get the class code from the DLL. Compile on Irix and it might get it from a DSO, or it might get it from a static library.