CompuServe Thread

#Help with DLL's!!!!!

13 messages in this thread
#1121From: Mark Novisoff/MicroHelpOct 3, 1991 7:25 AM
John, You must *export* the procedure (make it public) before it can be used from another program. Mark There is 1 Reply.
#1162From: John RuzickaOct 3, 1991 9:57 AM
Does that mean that all I have to do is put the _export keyword in front of all the function names? Do I have to use _export with WinMain? Thanks, John There is 1 Reply.
#1183From: Mark Novisoff/MicroHelpOct 3, 1991 12:26 PM
John, I don't know if the _export keyword will do that, but I suspect it will. Why don't you try it? Ditto for WinMain! Mark There is 1 Reply.
#1214From: John RuzickaOct 3, 1991 4:28 PM
Tried it…it didn't work. Set the compiler for "all functions external." That didn't work either. Any other suggestions? Will leave a message for Borland to see if there's something I'm forgetting to do. Thanks, John
#1282From: John RuzickaOct 3, 1991 11:52 PM
I also tried using Alias "_chowmain" since that seemed to be the name in the DLL. John
#1316From: Mark Novisoff/MicroHelpOct 4, 1991 5:31 AM
John, I don't know what else it could be. I suggest you take Jonathan up on his very generous offer. Mark There is 1 Reply.
#1353From: John RuzickaOct 4, 1991 10:43 AM
Mark, Thanks for your help…I did that. This type of thing is the WORST part of the learning code. It seems that I was breezing along, learning VB and C++, and now I've ended up spending several days on what is probably a really simple mistake on my part. Oh well, Thanks again for your help John
#1324From: Vincent ChenOct 4, 1991 5:36 AM
John, I believe you also need the FAR PASCAL keywords for Chowmain. Try: int FAR PASCAL _export Chowmain (void) { return 10; } -vince P.S. The PASCAL will prevent the prepending of the underscore. If you have arguments, it will also shove them onto the stack in PASCAL order. P.P.S. You don't need the _export on LibMain, but it can't hurt. There are 2 Replies.
#1354From: John RuzickaOct 4, 1991 10:44 AM
Thanks for the help…will give it a try! John
#1406From: John RuzickaOct 4, 1991 4:06 PM
THANKS! It worked! Now, one last question and I should be well on my way to Windows Programming 🙂 — How do I return a string to VB from C when C has no String data type? I tried returning a char *, but this resulted in an unrecoverable application error. Thanks again for your help, John There is 1 Reply.
#1475From: Vincent ChenOct 5, 1991 3:56 AM
John, Apparently, without the Controls Development Kit (CDK), the DLL function cannot return a string as the function return value, but you can return strings through the function's arguments. That is: int FAR PASCAL _export foo (LPSTR s) { lstrcpy(s, "Returned string"); return 0; } In VBasic: Declare Function foo Lib "foolib" (ByVal s As String) As Integer The LPSTR is defined in WINDOWS.H as far char * lstrcpy is strcpy that works for long char pointers. I think that's all there is to it. By the way, Petzold's "Programming Windows" book recommends *not* using "compact" or "large" model. -vince There is 1 Reply.
#1510From: John RuzickaOct 5, 1991 12:12 PM
Thanks for the help! Strange about the recommendation not to use "COMPACT" model as that is what BC++ defaults to when creating DLL's! John There is 1 Reply.
#1558From: dwallenOct 5, 1991 8:26 PM
I _think_ that BC++ 2.0 defaults to compact ONLY because they assume you're writing in C++, rather than C. In C++ you must use a large memory model to do DLL's with Borland. There is no restriction on memory model if you are using C. At least that's the way I think it works. I haven't yet tested my BC dll's in small model, yet, so you should probably verify for yourself.