I''m currently using VB5, and have several small, relatively simple graphics routines--but they perform millions of operations per call. So, I''m considering putting these routines into a C++ prg for use as a DLL. Thus, my questions: Using a simple compiler, can I make a small C program a DLL, and what makes a C program a DLL? (simply saved with the .dll suffix?) Assuming I can solve the problem above, I''ll want to pass an array to the DLL for processing. I''ve studied enough C to reproduce my VB routines in C, but don''t know what it will take to access or use the passed array. Thanks! Chris

To create a dll you need to specify to your compiler that you want the output as a dll (this works in several free compilers I''ve used, like lcc-win32, if thats what you mean by a ''simple c compiler''), also the main function will be in the order of:

BOOL WINAPI EXPORT LibMain(HINSTANCE dllinst, DWORD action, LPVOID lpvReserved)

This is the entry point, which you use to process whats happening (like so):

    switch(action){    case DLL_PROCESS_ATTACH:        /* The DLL is being loaded, do init here.           Return false (0) if your init fails */        break;    case DLL_PROCESS_DETACH:        /* Unload dll, clean up, etc. */        break;    case DLL_THREAD_ATTACH:	/* dll is already loaded */        break;    case DLL_THREAD_DETACH:        /* NOT exiting; the dll is still in use at this point */        break;}    

Now you create you functions you want to export, like this:

int __declspec(dllexport) MyFunction(int *intarray,int count)
{
//stuff
}

''__declspec(dllexport)'' makes the function exportable, so other programs can use the function; any normal function won''t be accessable outside of the dll.Now in vb, you would declare the function in one of your modules similar to this (I don''t have windows open, so play with it; the directions are in the help file for sure)

Declare Function Lib "mydll.dll" MyFunction(ByRef number() as integer, ByVal number_count as integer) as integer

You have to specify ''ByVal'' when you want the absolute value, by default all functions in vb are passed ''ByRef'' -- a pointer.Vb probably uses some other stupid way of handling arrays, I''m not sure on that.Simple types such as an integer should be easy to move to and from the dll, other complex types (such as an array of integers, or vb''s string type) you''ll have to read the help file about, it''ll tell you about byte sizes and such.
Hope you can get this off the ground, I didn''t have much luck getting the return value in vb 5 (but I didn''t care enough to find out why vb messed up, it was for work.It would enter the dll, run the function, the function returned the value, and other real programs could use the dll no sweat, but vb choked on it), I''ve had success with earlier versions of vb though.

Good Luck



----------
meh

As a side note, the next version of Visual studio will implement a cool cross-language compiler. So that you can just do inline C++ (and maybe ASM) in your VB code, just like how you do ASM in your C/C++ code now.

epolevne

epolevne: seriously? That''s awesome.....



Martee
Magnum Games

Seriously...that''s the buzz around VS7...I''ve heard it from a few sources. I''d love to say I''ve seen it for myself, but I haven''t, so there''s no garuntees.[sic]

If it''s not true, then it''s a damn good rumor and SHOULD be implemented! That really just opens up the doors to picking each language and doing what it''s best at. So you can use inline VB to speed up dev time on your GUI interface, and write your graphics engine in C++/ASM. All in the same project.

epolevne

quote: Original post by Epolevne

Seriously...that''s the buzz around VS7...I''ve heard it from a few sources. I''d love to say I''ve seen it for myself, but I haven''t, so there''s no garuntees.[sic]

If it''s not true, then it''s a damn good rumor and SHOULD be implemented! That really just opens up the doors to picking each language and doing what it''s best at. So you can use inline VB to speed up dev time on your GUI interface, and write your graphics engine in C++/ASM. All in the same project.

epolevne

My understanding is that this IS correct. That''s why the VB engine is being OOP''d up so to speak, with better inheritance, etc... It''s also the first step to the creation of the .NET standard which will then include C# and VB running in their runtime environment.


BeS
It's Da BOMB Baby!!!

Woohoo!!

Martee
Magnum Games

Portability would be lost.
I''m not a fan of any OS really... I use windows but I think its important to keep options open. Then again... that is a VERY nice feature

Protozone

[Please be open-minded as you read this post]

If you looked at the .NET information, you''d know that Microsoft is REALLY making this platform "all that." Technical demonstrations include tablet computers that recognize *hand-writing* as if it was computer typed text.

You could run the SAME .NET platform on your cell-phone, desktop, laptop, tablet computer (which is good for journalists who take notes a lot). And the BEST thing is that you don''t *need* to write any hardware-specific code. What runs on desktop with .NET will run on cell-phone with .NET platform. If this is the truth, then there''ll be a re-birth in "Classic" 2D games like Space Invaders, Tetris, Pac-man which don''t require complex 3D hardware, perfect for Cell-phones, which are small, and have only minimum 2D hardware.

The point now comes that with such market for big game developers and small, business applications (big and small), ease of use, etc., where would Linux or BeOS or whatever else stand? I suspect .NET will be the next big thing from Microsoft Windows''s first release, if not bigger. We don''t need to talk about Business software and people--their favorite OS would *always* be Microsoft''s newest OS. And I think you''d agree with me if I said that where the business people go, there game developers should also go (because the average game-PLAYING-joe cannot go through the trouble of installing Linux on .NET or Windows).

This brings me to my final point... since Linux and BeOS etc., are out of the picture, and the Mac *not* being the favorite, we would want something that brings together the ease-of-use of Visual Basic, with the power of C/C++. Frankly, I don''t think ASM would be needed for even John Carmack due to the speed of modern processors, and video cards. But, C++ has inline ASM for those who find a use for it.

So my suggestions are (1) Either make C# have the GUI power of Visual Basic, or (2) Make C++ have inline Visual Basic support--like __vbasic { }. (?). I would like MFC to be reorganized a LOT. I''m one of those who like what MFC could do, but cannot do it due to the hard, unintuitive design.

What do you think? Remember--no flame wars.
- OldManDave.

C# is supposed to be a cross b/w Visual Basic and C++. It gets its name, general syntax, and power from C++. But it uses a VB-like object model and is a higher level language than C++. It''s supposed to be the RAD tool for people that know C++. It''s anybody''s guess as to what wierd VB/MFC combo they come up with for designing Forms.

As for inline VB, I''ve heard it''s in VS7. You can do a little __vbasic {} if you want, or maybe:

Language msCPP

End Language

in VB...whatever the keywords/syntax I''m sure it''ll be cool.

epolevne