- Forum
- Windows Programming
- How to use a static library inside my C+
How to use a static library inside my C++ code??
Hi everyone,
I have an old program written in Basic (compiled using QBasic v4.5 or even PDS v7.1) which has some important procedures that I will need to use in my C++ application. Actually, the C++ application we are building here is some kind of alternative to this old program.
I already tried to use a DLL to do this work, but I wasn't able to create the DLL with the old code because I couldn't find a compiler that was able to do this. But the PDS and QBasic interpreters I mentioned can create static libraries (.lib files) to me.
So, is there a way where I can access the procedures in my C++ code from inside this ".lib" file? And if it does, is it better than use a DLL? I mean, will it work fine in different versions of Windows?
For instance, I am using:
- Windows XP
- g++ compiler under Mingw
- QB4.5 or PDS7.1 for the BASIC code
Our application should work, if possible, under Windows XP, Vista and 7, so it will be useful for a long time.
Thanks in advance,
Leonel
I have an old program written in Basic (compiled using QBasic v4.5 or even PDS v7.1) which has some important procedures that I will need to use in my C++ application. Actually, the C++ application we are building here is some kind of alternative to this old program.
I already tried to use a DLL to do this work, but I wasn't able to create the DLL with the old code because I couldn't find a compiler that was able to do this. But the PDS and QBasic interpreters I mentioned can create static libraries (.lib files) to me.
So, is there a way where I can access the procedures in my C++ code from inside this ".lib" file? And if it does, is it better than use a DLL? I mean, will it work fine in different versions of Windows?
For instance, I am using:
- Windows XP
- g++ compiler under Mingw
- QB4.5 or PDS7.1 for the BASIC code
Our application should work, if possible, under Windows XP, Vista and 7, so it will be useful for a long time.
Thanks in advance,
Leonel
Last edited on
I thought we went over this before. QuickBasic 4.5, PDS 7.1, and VBDOS produce 16 bit binaries, whether they are .lib files or .exe files. So what you are asking is how to link 32 bit binaries with 16 bit binaries written in a different language to boot. Actually, I wondered about that myself at one time, and even looked into it. Let me tell you, it gets real hairy real quick.
The fact of the matter is that even 32 bit compilers of the same exact language but of different manufacturers are not binary compatible. If you create an obj/lib file with the GNU C++ 32 bit compiler I do not believe you will be able to use it with for example, Visual C++ from Microsoft.
This is not the case with exported functions from Dll, but to the best of my knowledge is the case with obj code. Microsoft's Component Object Model ( COM ) went a long way to solving this binary compatibility problem by creating a standard as to what a binary image/interface should look like.
The term used for attempting to connect 32 bit code with 16 bit code is 'thunking'. Here is a Wikipedia link...
http://en.wikipedia.org/wiki/Thunk
Look down towards the bottom of that page for this topic...
Thunk as compatibility mapping
But in terms of your continued attempts to use this old basic code, I do not believe you will succeed by trying to connect somehow to 16 bit lib binaries, nor to 16 bit dlls. Your best bet (and what I thought you were doing with Free Basic) is to compile the old basic code into a 32 bit Dll using a modern 32 bit basic compiler. Why is that not working? You had figured out how to produce one with Free Basic.
The fact of the matter is that even 32 bit compilers of the same exact language but of different manufacturers are not binary compatible. If you create an obj/lib file with the GNU C++ 32 bit compiler I do not believe you will be able to use it with for example, Visual C++ from Microsoft.
This is not the case with exported functions from Dll, but to the best of my knowledge is the case with obj code. Microsoft's Component Object Model ( COM ) went a long way to solving this binary compatibility problem by creating a standard as to what a binary image/interface should look like.
The term used for attempting to connect 32 bit code with 16 bit code is 'thunking'. Here is a Wikipedia link...
http://en.wikipedia.org/wiki/Thunk
Look down towards the bottom of that page for this topic...
Thunk as compatibility mapping
But in terms of your continued attempts to use this old basic code, I do not believe you will succeed by trying to connect somehow to 16 bit lib binaries, nor to 16 bit dlls. Your best bet (and what I thought you were doing with Free Basic) is to compile the old basic code into a 32 bit Dll using a modern 32 bit basic compiler. Why is that not working? You had figured out how to produce one with Free Basic.
Last edited on
Hi freedie1,
Thanks for answering me again.
Yeah, we went over this problem before when I was trying todo it with DLLs.
But at that other topic, as you will remember, I was creating the DLL with some test code (very simple procedure). When I learned how to make the DLL, I tried doing the same with the code I actually have to work with. When I tried this, FBC gave me a looot of errors, because the code was using some features/commands of BASIC language that FBC doesn't support/implement. And this is not restricted to FBC, VB6 and VB2008 complained about most of these features/commands. I also tried with QB64, which also gave me these errors.
And the worse is that these things are all over the code. Trying to fix this converting the commands to something the compiler accepts would be a lot of work and, moreover, we don't intend to change anything in this code because we don't want to compromise the reliability of it. This program is in use for more than 20 years, and changing or translating it could easily introduce errors. So, unless there are no other options, we don't intend to modify or translate it in any way.
I'm not sure if I made ir clear before, but our C++ application is an alternative to what this old program does. We are just trying to use its core (procedures related to route calculations).
If you know some compiler than can produce 32-bit DLLs out from this arcaic code, it will be greatly appreciated. Other solutions are aprreciated as well.
Thanks again for being so supportive.
Leonel
Thanks for answering me again.
Yeah, we went over this problem before when I was trying todo it with DLLs.
But at that other topic, as you will remember, I was creating the DLL with some test code (very simple procedure). When I learned how to make the DLL, I tried doing the same with the code I actually have to work with. When I tried this, FBC gave me a looot of errors, because the code was using some features/commands of BASIC language that FBC doesn't support/implement. And this is not restricted to FBC, VB6 and VB2008 complained about most of these features/commands. I also tried with QB64, which also gave me these errors.
And the worse is that these things are all over the code. Trying to fix this converting the commands to something the compiler accepts would be a lot of work and, moreover, we don't intend to change anything in this code because we don't want to compromise the reliability of it. This program is in use for more than 20 years, and changing or translating it could easily introduce errors. So, unless there are no other options, we don't intend to modify or translate it in any way.
I'm not sure if I made ir clear before, but our C++ application is an alternative to what this old program does. We are just trying to use its core (procedures related to route calculations).
If you know some compiler than can produce 32-bit DLLs out from this arcaic code, it will be greatly appreciated. Other solutions are aprreciated as well.
Thanks again for being so supportive.
Leonel
Here is a link to a post I made in the PowerBASIC forums several years ago that touches on many of the issues concerning communication between 16 and 32 bit code....
http://www.powerbasic.com/support/pbforums/showthread.php?t=22131&highlight=Bit+DOS
I still feel bad about that because one of the members - Mike Doty - put a lot of effort into developing code which I never used. However, what he did might be something you would want to look into, and that is swapping i/o through disk files between the apps.
None of the old DOS basics were perfectly compatible with each other. Some were very close, but small changes were always necessary when taking code from one version and trying to run it in another. I am personally very familiar with QuickBasic 4.5/PDS 7.1/VBDOS, and with PowerBASIC 3.5 (originally Turbo Basic from Borland). These languages were very, very close; but not exact. I'm not very familiar with FreeBasic, but am aware of its existance. I looked at some FreeBasic code once, but didn't like the looks of it. So in terms of your not wanting to change one line of code in the old basic program; that's unfortunately not realistic.
The situation you are in was really common in the past, but becomming less so as time wears on I expect. When Windows 32 bit hit back in the mid nineties, there were lots of companies with old basic code that worked really well and which they had probably spent a lot of money developing, but which they wanted to cheaply port to 32 bit Windows. The PowerBASIC company was and still is very active in that product space as they developed a program known as the console compiler which took vintage DOS code (even GWBASIC) and produced 32 bit console executables. The other program they developed created Dlls out of basic procedures. However, inevitably, there will be small changes needed. I really couldn't say whether you would have had better luck with PowerBASIC; in any case you said buying it wasn't an option.
My guess your only options (unless you want to try some of the things in my link above) are to either do a complete rewrite, or investigate just what the exact issues are between your code and why FreeBasic is throwing syntax errors. I'm sure there is something systematic going on there with variable types, syntax or something.
http://www.powerbasic.com/support/pbforums/showthread.php?t=22131&highlight=Bit+DOS
I still feel bad about that because one of the members - Mike Doty - put a lot of effort into developing code which I never used. However, what he did might be something you would want to look into, and that is swapping i/o through disk files between the apps.
None of the old DOS basics were perfectly compatible with each other. Some were very close, but small changes were always necessary when taking code from one version and trying to run it in another. I am personally very familiar with QuickBasic 4.5/PDS 7.1/VBDOS, and with PowerBASIC 3.5 (originally Turbo Basic from Borland). These languages were very, very close; but not exact. I'm not very familiar with FreeBasic, but am aware of its existance. I looked at some FreeBasic code once, but didn't like the looks of it. So in terms of your not wanting to change one line of code in the old basic program; that's unfortunately not realistic.
The situation you are in was really common in the past, but becomming less so as time wears on I expect. When Windows 32 bit hit back in the mid nineties, there were lots of companies with old basic code that worked really well and which they had probably spent a lot of money developing, but which they wanted to cheaply port to 32 bit Windows. The PowerBASIC company was and still is very active in that product space as they developed a program known as the console compiler which took vintage DOS code (even GWBASIC) and produced 32 bit console executables. The other program they developed created Dlls out of basic procedures. However, inevitably, there will be small changes needed. I really couldn't say whether you would have had better luck with PowerBASIC; in any case you said buying it wasn't an option.
My guess your only options (unless you want to try some of the things in my link above) are to either do a complete rewrite, or investigate just what the exact issues are between your code and why FreeBasic is throwing syntax errors. I'm sure there is something systematic going on there with variable types, syntax or something.
Topic archived. No new replies allowed.