I am compiling a DLL that uses ATL to house a com object and targeting X64. Everything seems to be fine but the DLL wont run on the 64 bit machine. I ran depends on it on the target machine and it seems to be dependant on the x86 versions of countless system libraries (kernel32 etc.). Anyone know what i am missing?
I am guessing you are running the x86 version of Dependency Walker, which when analyzing a 64 bit DLL will show that it depends upon several x86 system libraries. You need to download and run the x64 version of Dependency Walker to see what is really causing the problem with your DLL.
http://www.dependencywalker.com
Need more details to be able to help, What are the errors you are getting?
The name of a DLL does not indicate if it's 64 bit or not, in windows there are versions of most system dlls on both 32 & 64 bits and they are named the same but placed in different folders.
The results you got from depends are troubling. Are you sure your DLL is indeed 64 bit? If it is, and it is linked to 32 bit DLLs, it will never work. Go back to your dev env and change those dependencies. If your DLL happens to actually be 32 bit, look for the 64 bit one...
You don't specify how exactly the DLL won't run (does regsvr32 work? if so, what error does creating an instance return?). In case you can indeed register it and you're trying to use it from a 32 bit client, make sure you specify the activation bitness correctly (see CLSCTX_ACTIVATE_32_BIT_SERVER and CLSCTX_ACTIVATE_64_BIT_SERVER). If this is the case, the dependency thing was a red herring, of course.
Related
We have a C++ / Objective C based app.
We use LLVM-GVC compiler to compile our code.
Currently we build 32-bit binaries and deploy them on our customer's machines.
We support SnowLeopard, Lion, Mountain Lion and Mavericks.
I'm aware that all these are 64 bit OS. They can run 32 bit binaries fine.
But i want to know, going forward , is it a better idea to deploy 64bit binaries of my app?
I can compile our code base and build 64 bit binaries, but i will have to link against 3rd party 64bit libraries etc.
I think its do-able.
My question is what are the advantages of deploying 64 bit binaries, provided that 32binaries still work on these OS's?
Also what bout Universal Binary? Do you guys think building a Universal Binary would be a better option? If yes, why?
I'd appreciate any thoughts/suggestions.
If your binaries are standalone apps, as in they're not plugins or dylibs for other programs, then there's nothing wrong with using 32-bit binaries. You're in good company; if you look at Google's Chrome browser, that also uses 32-bit binaries.
The advantage of 64-bit is that you can address more memory, if required and I think there are a few assembler instructions that are faster with 64-bit instructions, but overall, if it works for you, I don't believe it's an issue.
If you find yourself creating a dylib that must work with both 32 and 64 bit applications, that would be a reason for creating a Universal Binary, to save having to create one of each and work out which you need at runtime; with a Universal Binary OSX will take care of that for you.
I have two machines, one running Vista Ultimate 32, the other one running XP SP3. both machines have the same VS2008 version installed.
I built boost 1.50.0 on the first machine (vista), and subsequently libtorrent library, that relies on boost.
I saw in some libtorrent build instructions that the win version is specified within preprocessor, so I did what seemed to make sense at the moment:
#define _WIN32_WINNT=0x0600 // being that the current OS is Vista
The build went successfully, and I was able to run the application on that machine. However, when I tried to run it on the other one (XP), it failed with the message, something like:
Procedure entry point SetFileInformationByHandle could not be located in the dynamic link library KERNEL32.dll
Now, logically, I'm guessing that this has something to do with incompatible versions, and probably different windows headers are included when this variable exists with different values.
The requirement: I'd like to build this on Vista or 7, and still be able to run it on XPs.
The question: Do I need this directive at all, and if I do, what should be the value? What else should I specify, if I'm missing something?
Try to build your program on XP or set _WIN32_WINNT to 0x0501 (as in your comment). The kernel32.dll library is backward binary compatible according to this report, so you can build your program with old version of this library (5.0) and run it with a new one (6.0) without the need to recompile. Vice versa is not possible due to a bunch of added symbols (SetFileInformationByHandle is one of them).
I am trying to install Sheridan controls (ActiveThreed 2.01) on Win7 64-bit, but evidently it is a 16-bit installer so it won't execute.
What would be the best way to get round this problem?
Can anyone comment on whether http://homepage3.nifty.com/takeda-toshiya/msdos/index.html would be helpful?
It took me months of googling to find a solution for this issue. You don't need to install a virtual environment running a 32-bit version of Windows to run a program with a 16-bit installer on 64-bit Windows. If the program itself is 32-bit, and just the installer is 16-bit, here's your answer.
There are ways to modify a 16-bit installation program to make it 32-bit so it will install on 64-bit Windows 7. I found the solution on this site:
http://www.reactos.org/forum/viewtopic.php?f=22&t=10988
In my case, the installation program was InstallShield 5.X. The issue was that the setup.exe program used by InstallShield 5.X is 16-bit. First I extracted the installation program contents (changed the extension from .exe to .zip, opened it and extracted). I then replaced the original 16-bit setup.exe, located in the disk1 folder, with InstallShield's 32-bit version of setup.exe (download this file from the site referenced in the above link). Then I just ran the new 32-bit setup.exe in disk1 to start the installation and my program installed and runs perfectly on 64-bit Windows.
You can also repackage this modified installation, so it can be distributed as an installation program, using a free program like Inno Setup 5.
You can't run 16-bit applications (or components) on 64-bit versions of Windows. That emulation layer no longer exists. The 64-bit versions already have to provide a compatibility layer for 32-bit applications.
Support for 16-bit had to be dropped eventually, even in a culture where backwards-compatibility is of sacred import. The transition to 64-bit seemed like as good a time as any. It's hard to imagine anyone out there in the wild that is still using 16-bit applications and seeking to upgrade to 64-bit OSes.
What would be the best way to get round this problem?
If the component itself is 16-bit, then using a virtual machine running a 32-bit version of Windows is your only real choice. Oracle's VirtualBox is free, and a perennial favorite.
If only the installer is 16-bit (and it installs a 32-bit component), then you might be able to use a program like 7-Zip to extract the contents of the installer and install them manually. Let's just say this "solution" is high-risk and you should have few, if any, expectations.
It's high time to upgrade away from 16-bit stuff, like Turbo C++ and Sheridan controls. I've yet to come across anything that the Sheridan controls can do that the built-in controls can't do and haven't been able to do since Windows 95.
I posted some information on the Infragistics forums for designer widgets that may help you for this. You can view the post with the following link:
http://forums.infragistics.com/forums/p/52530/320151.aspx#320151
Note that the registry keys would be different for the different product and you may need to install on a 32 bit machine to see what keys you need.
I am mostly posting this in case someone comes along and is not aware
that VB2005 and VB2008 have update utilities that convert older
VB versions to it's format. Especially since no one bothered to
point that fact out.
Points taken, but maintenance of this VB6 product is unavoidable. It would also be costly in man-hours to replace the Sheridan controls with native ones. Simply developing on a 32-bit machine would be a better alternative than doing that. I would like to install everything on Win7 64-bit ideally. – CJ7
Have you tried utilizing the code upgrade functionality of VB Express 2005+?
If not,
1. Make a copy of your code - folder and all.
2. Import the project into VB express 2005.
This will activate the update wizard.
3. Debug and get the app running.
4. Create a new installer utilizing MS free tool.
5. You now have a 32 bit application with a 32 bit installer.
Until you do this, you will never know how difficult or hard it
will be to update and modernize the program.
It is quite possible that the wizard will update the Sheridan controls
to the VB 2005 controls. Again, you will not know if it does
and how well it does it until you try it.
Alternatively, stick with the 32 Bit versions of Windows 7 and 8.
I have Windows 7 x64 and a program that will not run. However,
the program will run in Windows 7 32 bit as well as Windows 8 RC 32 bit.
Under Windows 8 RC 32, I was prompted to enable 16 bit emulation
which I did and the program rand quite fine afterwords.
I had 32-bit software with a 16-bit installer that I couldn't unzip. I solved it with otvdm which allows you to run windows 1.x, 2.x, 3 programs on win64. In fact, otvdmw allows you to select the program to run (otvdm is command-line).
16 bit installer will not work on windows 7 it's no longer supported by win 7 the most recent supported version of windows that can run 16 bit installer is vista 32-bit even vista 64-bit doesn't support 16-bit installer....
reference http://support.microsoft.com/kb/946765
Bottom line at the top: Get newer programs or get an older computer.
The solution is simple. It sucks but it's simple. For old programs keep an old computer up and running. Some times you just can't find the same game experience in the new games as the old ones. Sometimes there are programs that have no new counterparts that do the same thing. You basically have 2 choices at that point. On the bright side. Old computers can run $20 -$100 and that can buy you the whole system; monitor, tower, keyboard, mouse and speakers. If you have the patience to run old programs you should have the patience to find what you are looking for in want ads. I have 4 old computers running; 2 windows 98, 2 windows xp. The my wife and I each have win7 computers.
I'm working on my first Mac OS X app. My project was set-up with XCode defaults and I haven't touched any Build Settings. When building for Mac 64-bit, the app runs fine. However, when building for Mac 32-bit, I get a seemingly arbitrary error that says:
Semantic issue: Synthesized property 'myProperty' must either be named the same as a compatible ivar or must explicitly name an ivar.
What kind of things can I check for?
It sounds like you have found the error but I think I can answer your question just in case someone else later finds it.
Apple has made a lot of changes in the 64 bit Objective-C runtime which they couldn't do before since it would break binary compatibility. One of the things that is different is that in the 32 bit runtime synthesized properties have to be backed by instance variables. On the 64-bit runtime synthesized properties sill needs that but they are created automatically for you. By default the name of the instance variable should be the same as the name of the property.
So in case you need to support 32 bit then make sure that you create instance variables for all your properties. If you only support 64 bit then you can still do that so that your code can be built for both 32 bit and 64 bit at the same time but you don't have to.
You can set the NS_BUILD_32_LIKE_64 preprocessor macro in Xcode for the the 32bit build target. This will save you the trouble of maintaining separate code for 32bit and 64bit versions.
We have an application we're trying to deploy on both 64 bit and 32 bit platforms. Is there a way to put both compiled versions of the code in the same binary, a la Apple and NeXT's fat binaries?
Ideally we could ship one .exe that decides upon execution which version of the code to execute. We're targeting Windows XP and later.
Process Explorer (was sysinternals, now owned by Microsoft) does this. It is a 32-bit application that detects a 64-bit environment, writes out another binary and deletes it on exit. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
One approach is perhaps to supply a bootstrapping application that determines the architecture and chooses the appropriate executable to run. So basically the shortcut or what have you to your application simply starts the bootstrapper which in turn starts the appropriate application. This can be a little more tricky if your application is a Windows service.
The simplest approach would be to handle this by the installer - it would have two versions of each binary and copy necessary versions depending on which system bit-ness is at the target machine.