I'm going to redistribute gsdll32.dll, main library of GhostScript. There are two versions available for download, 32 and 64 bit. Will the first one work on 64-bit systems, or I need package two versions separately?
It depends on how the .exe is built. If you build a .exe for 32 bit, you need the 32 bit dll. It will work on 32 and 64 bit systems.
Related
I have a 32-bit dll that I have gotten from a third party. They have no 64 bit version. I wish to load this dll into 64 bit python. To do this, I need a 64 bit dll. Is there a tool to convert a 32 bit dll to a 64 bit dll or is this impossible? If it impossible then I must use 32 bit python I guess.
Only the vendor can do this, unless you get access to the DLL's source code. It must be recompiled for 64 bit.
I guess you'll have to use 32-bit python...
32 and 64bit DLLS have different ABIs and calling conventions. You just can't load a 32bit DLL into a 64bit process or the other way around.
As mentioned in the comments, you have to recompile from source.
You can't create a 64-bit DLL from 32-bit one without the source code.
But you can create an adapter as a native 32-bit application that loads the 32-bit DLL and provides access to it's functions via some kind of inter-process communications (e.g. named pipes)
Of course, that's may be senseless in some cases and you may prefer to use 32-bit python.
So it depends.
They both install node.exe into C:\Program Files (x86)... so I'm wondering what the actual difference is. I know that there is some because node-sqlserver module is failing on our machine and it does so in different ways for x86 and x64 versions of Node.
Can somebody explain the difference for me? Thanks.
The x64 installer installs the 64 bit version of node which is compiled against the 64 bit version of V8. The node-sqlserver package is a native module which means it needs to be compiled against the matching version of node. IE: It will fail if you are using a pre-compiled, 32 bit version of the module against the 64 bit version of node.
Other than the typical differences between 32 & 64 bit applications (larger address space, use of 8 bytes for addresses instead of 4 bytes), node doesn't differ between the two versions.
If I use a variable of type Int64, will it work on all Windows versions: win95, 98, 2000, nt, xp, vista, win7? No matter what OS it is 32bit or 64bit? And no matter what CPU they are using?
I just want to be sure, that my program will work on all Windows versions.
The size of datatypes provided by a language is not constrained by the operating system or hardware platform. I can have 64-bit integers on 32-bit platforms (or 16- or 8- or 11-bit, for that matter).
Int64 variables are supported by the 32 bit Delphi compiler. All operations on Int64 operands will give identical results no matter what platform (machine, OS etc.) the code executes on.
On 32 bit platforms the compiler has to use special routines to perform 64 bit arithmetic using the 32 bit machine instructions that are available. When targetting a 64 bit machine the compiler can use native 64 bit instructions. No matter, the end result is indistinguishable to you.
Note that if you execute a 32 bit Delphi executable on a 64 bit OS, you will still be using the 32 bit emulator, a.k.a. WOW64. From the perspective of the executable, you are running on a 32 bit machine. Unless you are using the new 64 bit compiler introduced in XE2, you will be producing 32 bit executables.
The 64bit integers will work fine on a 32bit operating system.
Performance gains in using these data types however will only come when using code compiled for a 64bit operating system - for this you would need Delphi XE2.
Meanwhile you have the benefits extra data capacity, but not extra execution speed (although this would not normally be a consideration for most applications).
Under MacOS, you can change a little option for 32-bit executables called "Open in 32-bit mode". Wouldn't it work directly? And it works, but for some applications you had to select this option in order to run without problems. This was frequent in Safari, where some add-ons required a 32-bit environment.
I can't understand what makes an 32-bit executable not able to run directly in 64-bit, so what exactly changes in 32-bit mode?
This is really only of historical interest. In the transition period from 32 bit to 64 bit many apps were built as universal with 3 or sometimes even 4 architectures combined into one fat binary (aka "Universal Binary"), typically ppc, x86 and x86-64. In a 32 bit x86 environment the 32 bit x86 executable would be used. In a 64 bit x86-64 bit environment the 64 bit executable would be used. However in some cases you might want to use the 32 bit x86 executable even in a 64 bit x86-64 environment, e.g. in the case you mentioned where you have older plug-ins which are 32-bit only and can not be used with a 64 bit executable. Hence the option to launch an app in 32 bit mode.
Obviously a 32 bit app uses 32 bit APIs and has a 32 bit address space, whereas a 64 bit app has a 64 bit address space and uses 64 bit APIs.
I'm thinking like Apple did with their universal binaries containing both x86 and ppc code
No. The IMAGE_FILE_HEADER.Machine field determines whether a DLL is x86 or x64. One field cannot hold two different values simultaneously, and there's only one IMAGE_FILE_HEADER in a DLL.
That said, a pure .Net DLL contains IL instructions, and they can be compiled to either 32 bits or 64 bits.
You can build the dll as 32Bit and it can work in both 64 and 32 environment, but it will be 32 bit dll