Compiling a C dll for 64 bits - c

My problem is about trying to compile a C dll and its dependency to 64bits and to use it in LabVIEW.
To start with the beginning, I'm using a 32 bit LabVIEW toolkit to use XML files (downloaded from here ). This toolkit is using 32 dll dlls that works fine (libxml, libxslt, iconv, zlib, and a wrapper dll IXMLWrap)
Now, I want to use it with 64 bits version of LabVIEW. The LabVIEW part of that migration should not be a problem, but first of all, I have to get 64 bits version of the dlls.
I downloaded the 64 bits versions, except for IXMLWrap (specific one). But I have the .c file of that wrapper.
So I tried to compile it with visual studio, and successed ... almost !
I get a home compiled 64bit IXMLWrap dll, but impossible to load it with LabVIEW 64 bits...
When reading the dll with "Dependency Walker" 64bits, I get some errors about missing export functions.
Indeed, when I compare the 32 and 64 bits dlls with Dependency Walker, I do have the same functions in the dlls, but do not have the same exported functions ... (sorry I'd like to post images of that but not enough reputation...
Does someone have some hint about what is the problem with my IXMLWrap dll : incorrect downloaded dlls, problems in the configuration of my Visual studio project, ... ?

OK, it's all my fault...
I did the link with .lib files ... coming from linux (not windows)!!
No problems then to compile and use the 64bits dll

Related

E2045 Bad object file Format:"XXX.obj"

I am working on one migration project from x32 bit to x64.
Here I am using this code:
{$L com_1.obj}
{$L com_is1.obj}
{$L com_2.obj}
But while compiling code I am getting error as
[dcc64 Error] XXX.dpr(919): E2045 Bad object file format: 'E:\MyProj\com_sha.obj'
I am not able to trace why it is happening.
Is it due to 32 bit obj file used for compiling x64 bit delphi project?
If it is I have also tried to create a obj file with x64 bit environment.
Can anyone please help me on this?
I am using Delphi 10 Seattle.
You cannot use a 32 bit object with the 64 bit compiler. You must recompile your code with a 64 bit compiler.
You can use a number of different compilers to do this. Although I have heard of people succeeding with gcc I have never managed to do that. I believe that the modern Clang based Embarcadero compiler can be used, but I personally have no experience of that. I have always used the Microsoft compiler to create 64 bit objects. And certainly this is how Embarcadero themselves have done it for libraries like zlib that they link to their RTL.
Yes you need to convert those .obj files to 64 bit.
Converting 32-bit Delphi Applications to 64-bit Windows states:
64-bit External .obj Files: If you expect your 64-bit Windows application to link to an external .obj file, keep in mind that you will need a 64-bit version of the .obj file to link with a 64-bit Windows application.

How to switch VS Project from 32bit to 64bit?

I am having trouble moving my WPF project from 32 bit to 64 bit. I recently realized I need my program to be able to use more than 2gb of memory.
What I did was I changed my project's platform target from Any CPU (with preferred 32 bit checked) to x64.
I then got an error stating “XXX” does not exist in the namespace “XXX" and realized it was probably because I did not change the CPU target for my other libraries.
Then when I launched the program in my developer machine, it works perfectly fine using both visual studio and Click Once installing after deploying. However, when I test the deployed executable using a few different 64 bit machine, the program starts behaving erratically with some functions not working properly.
I have no idea how to debug since it works perfectly fine in my developer machine but not on any other computer? Am I not changing the target platform correctly?
The assembly ITSELF built by youself when targeting "Any CPU", but you should check out every third-party assemblies that used in your project if they are targeting "x86". If you change the target of your own project to "x64", make sure all of the dependencies are for "Any CPU" or "x64".

PINTERFACE_REFERENCE and MinGW W64

I'm trying to compile my working 32-Bit DLL project which communicates with USB-Devices to a 64-Bit Windows-DLL.
The sources compile fine with MinGW32 but if I try to build them with MinGW W64 I get an error within hidclass.h:
hidclass.h|132|error: unknown type name ‘PINTERFACE_REFERENCE’
I can't find anything about PINTERFACE_REFERENCE so I'd be glad for every hint about this.
Building it in 32-Bit is not an option because it will be used within Java via JNI and I have to support both 32- and 64-Bit JVMs.
I know that I could do minor changes to my code and switch to Microsofts Visual C++ compiler using VisualDDK and the Windows Driver Kit but I'd love to continue using my free toolchain since it works flawless for 32-Bit builds and I don't have to think about licensing issues.

Any way to decompile binary resource file built with ancient compiler?

I'm trying to resurrect a 1990's application that was built with Borland Turbo C++ (version unknown, maybe 3.0, maybe 4.5?), and apparently targeted for Windows 3.1.
The project contains a single .c file, and a single .res file. Rather than try to locate the ancient compiler, I've tweaked the C source into compatibility with MinGW gcc ver 4.5.2, thinking I could rebuild it for win32. Unfortunately, this is one of those windows programs where the main window is a dialog box, and the dialog specifications are embedded in the .res file. Of course modern MinGW gcc doesn't understand the old .res format.
So is there a way to recover an .rc file from a 1990's vintage Borland .res file? I know there will be other problems compiling old 16 bit windows code like this, but I can deal with that later (it's only 2K loc), right now the stumbling block is this resource file.
somewhat later ..
I have found 'Turbo C 3.1', but this thing is a trip. It can actually compile for 16-bit windows, the resulting executables requiring an NTVDM to run under XP, but the concept is proved. Tried it on a simple windows hello-world, and it worked.
Anyway, the problem is still the .res file! There was a project (.prj) file with the aforementioned material, but it apparently calls out the .rc source file. I know with gcc, I can link an already compiled resource file into an executable, but heck if I can figure out the strange command line for 'bcc' to do it. To get an idea how odd it is, bcc uses -W as a flag to 'create windows application'. It must be possible. Anybody remember?
(fwiw- i think there may be better tags for this. feel free to re-tag.)
Open Watcom C/C++'s Resource Editor (wre.exe) seems to be able to open 16-bit .res files. If the latest version doesn't work fully (which isn't totally unexpected as very few people work with 16-bit resource files), try earlier ones.

How to get xp_pcre to run on a 64 bit system?

For many years we have been using xp_pcre for regular expressions in sql server:
xp_pcre - Regular Expressions in T-SQL
I've just migrated to a new 64 bit vista development machine and have installed xp pcre. Unfortunately when i try to use the sprocs I get the following error: Could not load the DLL xp_pcre.dll, or one of the DLLs it references. Reason: 193(%1 is not a valid Win32 application.).
Has anyone had any success installing xp_pcre on a 64 bit machine running vista? Any advice? Thanks in advance,
Shane
Since it's a compiled DLL, you would probably have to recompile it to get a 64 bit DLL, that could be run on your 64 bit machine. Since nothing at that page has been updated since 2005, it's unlikely there is an already a prebuilt version for 64 bit. However, since the source code is included, you could, if you have VS for C++, with a 64 bit compiler, compile it yourself and try to get it working that way.

Resources