Can not get Trial Dates from "TrialDaysRemaining" using g++ and g95

First, I want to say that your code is so nice to work with. I have my FORTRAN - C++ program working great with Intel FORTRAN and VS2008 C++.

My issue is when I am using G95 FORTRAN and the g++ (or gcc) compiler for the same code. I see where you have #ifdef statements for GNUC, and my code compiles and starts running GREAT-->> but I can never get a correct value from the following line:

// Get the number of trial days remaining. hr = TrialDaysRemaining(TA_GUID, &trialDays);

I just always get hr=7, which means: "The version GUID doesn't match that of the product details file." BUT, if I move the INTEL/VS2008 executable into the same directory as the G95/G++ executable, then the program correctly uses the TurboActivate.dll and reads the TurboActivate.dat file to give me the correct number of Trial Days remaining (which is 29 as of now).

I have searched on this forum about GNU and that you don't have static libs for GNU yet, but, like I stated, all is compiling and running and seems to be smooth, but it seems that there might be an issue between the exe created and the TurboActivate.dll where some data is not passing correctly and therefore I always get an hr=7 for the above line.

I have give you as much detail as you like, if this is not sufficient.

As always, thank you very much for all your assistance. I really appreciate it.

Oren

From the sounds of it this is the same problem you were having before. Namely, the compiler you're using isn't configured for Unicode (or doesn't support it). On Windows, TurboActivate uses "wide strings" (UTF16: 2-bytes for each character) for all the string values. On all other platforms TurboActivate uses "char *" strings, and assumes the values being passed in are UTF8.

So, explicitly pass in wide strings to the TurboActivate functions on Windows. That is, for the compilers that are giving you troubles, instead of using the _T() macro, use the L"" definition to explicitly label the string as a wide string.

I.e. L"your GUID here" instead of _T("your GUID here").

When you recompile your app in the trouble compilers you'll likely get an error. This will help you track down the appropriate switches to pass to the compiler to support Unicode strings.

Does that make sense?

The shorter advice would be, if it's possible, to avoid g++ on Windows. The support is extremely poor and the executables are slower and bigger compared to VC++ or Intel compilers.

You always make great sense! I am going to try that now.

For some reason...maybe because I had been up for way too long, I figured that I may have done something right with the Unicode, since the code compiled and ran, but I see what you are saying...I NOW about to get some issues (possibly) because of Unicode.

About the compilers: Yes, I agree and that is how I build my release version for NASA and for commercial use, but there are people (and companies) that either do not have money or will not use their money on a MSVC and INTEL FORTRAN. I am trying to see if I can increase the code's user base by giving the free option. --> The reason why the user cares about the compilers is that the users can add their own code to "User Subroutines" and then they have to Compile the User file and link it with the LIBs and OBJs that I have created.

You know what? I just thought of something --- and I would love your opinion (this is slightly off the LM topic, but it may be better across the board for me):Do you think I could have a Static Lib of my subroutines as an "Import Lib" that is always linked to create the EXE and then have the Users create a DLL with the Subroutine code? This would allow my to do all the building the way I want and just let them create the DLL in any other way.

I really appreciate all your help. You are always so insightful. I have a commercial code with a licensing manager thanks to you. Thank you for your help and thank you, in advance, for any insight you can give on my question about the DLL.

Oren

About the compilers: Yes, I agree and that is how I build my release version for NASA and for commercial use, but there are people (and companies) that either do not have money or will not use their money on a MSVC and INTEL FORTRAN.

Microsoft offers a free "Express" edition of it's Visual Studio product. And the commandline MSVC compilers are free. So, building on Windows with Microsoft's compilers doesn't cost anything.

Do you think I could have a Static Lib of my subroutines as an "Import Lib" that is always linked to create the EXE and then have the Users create a DLL with the Subroutine code? This would allow my to do all the building the way I want and just let them create the DLL in any other way.

You mean your app (not TurboActivate)? I'm not sure -- it depends on what your app does, how it integrates with things, how your customers plan to extend it, etc. This is a huge topic. That really depends on what you want to do and what your customers want to do.

Sorry that's not a very good answer.

More specifically about using creating a static library and letting the users use it wherever -- that really doesn't work. For example static libraries built with Visual Studio 2008 can't work with Visual Studio 2010 (and vice versa). Ditto for the GNU compilers.

Dynamic libraries, on the other hand, can be used wherever you want them to be used.

Got it to work!

Just FYI, this is what I did:

1. In the TurboActivate.h and the LMsubs.cpp (which has part from your example.c file) I had to force the compiler to use the all the statements associated with the "_WIN32" #ifdefs.---> so that means that MinGW has windows.h, and tchar.h in the include folder.

2. I had to add #define UNICODE and #define _UNICODE to my .cpp file all the way at the top

3. I had to comment out the following deprecated function (the last one in the .h file) to not get a compiler error (something about an id of some kind)://TA_DEPRECATED(TURBOACTIVATE_API ...blah blah....) ----->> I am glad it is deprecated!!

So here is what I do to make this work with G95 FORTRAN and g++:1. Make import library for your TurboActivate.dll, which means make a .def file from the .dll and then make the static libTurboActivate.a (or TurboActivate.lib) library file.2. Compile LMsubs.cpp which pulls in TurboActivate.h to create LMsubs.o---> g++ -c LMsubs.cpp3. Compile and Link all FORTRAN code files with LMsubs.o and libTurboActivate.a-->-g95 -i8 -r8 -malign-double -fsloppy-char -ftrace=full -fmultiple-save -fno-leading-underscore file1.for file2.for file3.for file4.for LMsubs.o libTurboActivate.a -o program.exe4. Make sure TurboActivate.dll and TurboActivate.dat are in exe folder5. Run Program and BAM! It works!--->> Here is the output:

Y:\Work\program.exe***************************************************Demo Version EnabledTrial days remaining: 29

ENTER INPUT DATA FILENAME

Thank you very much for your insight and always steering me to a solution whether directly or indirectly!

Reply
Discard post