Tokenizer Whitepaper Help

[Raven_Writer]

Here's the code I typed into a Win32 Application (not console):

HANDLE myLib = LoadLibrary("tokenizer.dll");

CompileProc Compile;
VerifyProc  TestRecAlignment;
VersionProc Version;
TModuleRec	tModRec;

Compile =          (CompileProc)GetProcAddress(myLib, "Compile");
	Version =		   (VersionProc)GetProcAddress(myLib, "Version");
	TestRecAlignment = (VerifyProc)GetProcAddress(myLib, "TestRecAlignment");

And here's the errors I get:

C:\Program Files\Microsoft Visual Studio\MyProjects\RoboCode\RoboCode.cpp(14) : error C2664: 'GetProcAddress' : cannot convert parameter 1 from 'void *' to 'struct HINSTANCE__ *'
        Conversion from 'void*' to pointer to non-'void' requires an explicit cast
C:\Program Files\Microsoft Visual Studio\MyProjects\RoboCode\RoboCode.cpp(15) : error C2664: 'GetProcAddress' : cannot convert parameter 1 from 'void *' to 'struct HINSTANCE__ *'
        Conversion from 'void*' to pointer to non-'void' requires an explicit cast
C:\Program Files\Microsoft Visual Studio\MyProjects\RoboCode\RoboCode.cpp(16) : error C2664: 'GetProcAddress' : cannot convert parameter 1 from 'void *' to 'struct HINSTANCE__ *'
        Conversion from 'void*' to pointer to non-'void' requires an explicit cast

The code compiled perfect when I did it in a console program, and all I did was copy/paste it (the code is in the "WinMain" thing). I've tried to fix it, but no luck, and I've looked up the errors on MSDN, but it didn't help me at all. Can someone help me please? The tokenizer.dll is in the folder where it's supposed to be (it loads correctly). I'm using MSVC++ 6.0 incase that helps at all.

[rbayer]

Sorry, that's my fault. Instead of declaring myLib as type HANDLE, make it HINSTANCE. Sorry for the confusion.

[Raven_Writer]

Originally posted by rbayer
Sorry, that's my fault. Instead of declaring myLib as type HANDLE, make it HINSTANCE. Sorry for the confusion.

Ok, thank you...It's alright, I knew it was probably that though, but 1 question...why did it when without doing that in a console program?

[rbayer]

It's possible that your Console app was setup to use C, whereas your new one is set for C++. Someone correct me if I'm wrong (which I probably am), but I'm guessing that the C compiler will convert pointer data types without even asking. After all, a pointer is just a pointer until you try to dereference it...

[Raven_Writer]

I'm not sure (I don't work with pointers alot), but you might be right. I don't think pointers work to well in C though (which goes along with my first statement). Is all your programs in MFC?

[Mongoose]

I, too, might be wrong, but I believe C is more lax with pointers than C++. I know C++ *requires* you to type cast void pointers. (Perhaps that's why C is a better language for writing exploits?)
I never knew HANDLE was #define'd or typedef'd as a void*, which certainly adds to the confusion.

[rwaliany]

Microsoft tends to add BS additions to their windows gui to make it look hard and make themselves look original.

LPCSTR

isnt that like

const char*

I prefer const char*, I dont know about you.

[rbayer]

Originally posted by rwaliany
Microsoft tends to add BS additions to their windows gui to make it look hard and make themselves look original.

LPCSTR

isnt that like

const char*

I prefer const char*, I dont know about you.

Take out the const and you're right. LPCSTR is never meant to be used by itself; you are always supposed to use LPCTSTR, so that code will automatically work under either Unicode or Ansi.

Also, using typedef in cases like this adds another layer of abstraction, which is a "good thing" from a software engineering view. Because this is translated directly into char * at compile-time, it's also one of the few abstractions that doesn't detract from performance.

That said, I never touched the MS-specific ones, except when dealing with MFC/API functions, while writing either RoboGUI or RoboEmu. Both use char * and I wouldn't have it any other way.

[jeremy562]

rbayer is right... Microsoft uses a LOT of macros and typedefs to abstract the data types, which is a GOOD thing.

If you look at the declarations, they are usually in some sort of #ifdef condition, so that by simply adding or removing a symbol from the preprocessor, your program can use different data types without changing any code. This is very useful if you want to be able to build your project with Unicode support.

[rwaliany]

Still, but why use LPCTSTR, instead of like mStr, well I guess they do that for MFC. I would still rather do my own unicode support. I haven't found any good documentation with the prototypes for windows GUI and the defines such as HANDLE HINSTANCE. I've been stuck reading their header files. I like Linux GTK better, its so much more common sense to me.

I suppose that is because it takes 5-7 lines to add a toolbar to a window in GTK and 25-30+ in MSVC++ (NON MFC).

[Raven_Writer]

you can do something like:
#define NewName LPSTR

[Ryan Meador]

You're absolutely right in that C doesn't have much in the way of type-safety. Most of the WinAPI weird data types are #define'd void*'s or various species of int's. I use some of them and not others... just whatever fits the bill.

[Raven_Writer]

The only thing I've found you can't use #define on is the comment (I wish I could though), and stuff like void, but I've not tried all of them.