For my code, I like to compile in 64 bit, to take advantage of the extra memory afforded, however there are times when I need to call a 32 bit dll. This is so that II don't have to reinvent the wheel, and because there is some great code out there, but a lot of it in 32 bit. My first thought is to write a 32 bit service, where the dll's can be processed, then communicate back to the 64 bit code either thru a pipe, sockets, or some other convention.
I'm sure some of you have run into this before, how have you handled it?
Another question, if I may: Does anyone know of a way to 're-load' if you will, a dll without having to restart the calling process? This is sort of a philosophy preference, is it better to write a series of small PB includes, or dll's?
Thanks for all of your help, the forums here are fantastic at knowledge transferal!
32 and 64 bit dll's
- RichAlgeni
- Addict

- Posts: 935
- Joined: Wed Sep 22, 2010 1:50 am
- Location: Bradenton, FL
Re: 32 and 64 bit dll's
Can't help with the first half...but as far as dll's go, I prefer to avoid them when practical. They are great in several cases:
Sharing dll's without sharing the source;
Very large programs when you don't want to sit and wait for compiling to finish every time;
And when you will use the same set of routines with multiple programs.
On the other hand, most pc's these days have "unlimited" memory and drive space (as far as PB programs go), so unless you are looking at 100's of thousands of lines of code (or very long compile times), it's kind of a hassle.
Sharing dll's without sharing the source;
Very large programs when you don't want to sit and wait for compiling to finish every time;
And when you will use the same set of routines with multiple programs.
On the other hand, most pc's these days have "unlimited" memory and drive space (as far as PB programs go), so unless you are looking at 100's of thousands of lines of code (or very long compile times), it's kind of a hassle.
Re: 32 and 64 bit dll's
Thats how i would do it. Keep it mind that it's much slower than a direct call.RichAlgeni wrote:My first thought is to write a 32 bit service, where the dll's can be processed, then communicate back to the 64 bit code either thru a pipe, sockets, or some other convention.
Thats easy.RichAlgeni wrote: Another question, if I may: Does anyone know of a way to 're-load' if you will, a dll without having to restart the calling process?
Use CloseLibrary or FreeLibrary (Win API) to unload it and then simpley load it again.
I prefer includes. Because they can be ported to other platforms if needed or changed in any other way if needed.RichAlgeni wrote: This is sort of a philosophy preference, is it better to write a series of small PB includes, or dll's?
- RichAlgeni
- Addict

- Posts: 935
- Joined: Wed Sep 22, 2010 1:50 am
- Location: Bradenton, FL
Re: 32 and 64 bit dll's
Thanks folks! I much appreciate your ideas! The madness behind my method is to have a server to interact with the user, then have say 6-8 main procedures as dll's. These would then do the specific tasks needed by the user. If new or changed functionality was needed, I would change or add a dll that was called by one of the main procedures.
Understood about it being much slower, I wasn't sure if there was a Microsoft API that would allow 32 bit dll's to be called from 64 bit software. There is a tone of 32 bit code out there that works correctly now, why not use it?!?!
Understood about it being much slower, I wasn't sure if there was a Microsoft API that would allow 32 bit dll's to be called from 64 bit software. There is a tone of 32 bit code out there that works correctly now, why not use it?!?!