OpenSC 32 bit for windows installation does not create file opensc-pkcs11.dll in c:\windows\system32, but the installation document says it does, is this a bug? or am I missing anything? I tried download different versions, none of them created this file.
32 bit installation file is creating pkcs-dll in C:\Windows\SysWOW64 and not in c:\Windows\System32 as the documentation says.
Related
I have downloaded both a .dll and a .lib file compatible for 32-bit Windows from libspotify. The project I am working on requires me to use other libraries that does not work on Windows, but compile and work using Cygwin. I therefore need a way to get the .dll and/or .lib file "converted" into a compatible Cygwin format. Is that possible?
The .dll file does not contain symbols, so the suggested method described in the bottom of the Cygwin doc did not work.
The other libraries that I have, generated the following files:
/usr/local/lib/{libname.la, libname.dll.a and sometimes libname.a}
/usr/local/bin/cyglibname.dll
Where libname is the name of the library correctly compiled and installed. How do I get these files from the native 32-bit Windows .dll and .lib files?
Update:
I tried to include the full path to the .dll file instead of using -l and -L as I am used to linking libraries, and I got the following message:
/usr/bin/ld: i386 architecture of input file `/usr/local/test/libspotify.dll' is
incompatible with i386:x86-64 output
It seems like the problem is the 32-bit vs 64-bit. Anyone know how to fix that?
Another update:
It worked by adding -m32 to CFLAGS and LDFLAGS. I now got a different error that I believe is irrelevant for the original question.
It seems like the problem is the 32-bit vs 64-bit. Anyone know how to fix that?
Yes; use 32 bit Cygwin for a project that depends on third party DLL's only available in 32 bit form. Do not use 64 bit Cygwin.
Cygwin and Cygwin-64 can be installed side by side, by the way. (And it's possible to share the same home folder between them, so you don't have to duplicate your .bashrc and whatnot.)
This is not a Cygwin problem. If you build a 64 bit executable with, say, Microsoft Visual Studio, it also will not load the 32 bit libspotify DLL.
I had to reinstall Windows 7 (x64) due to a crashed disk. When I reopened the project i was working on, and tried to compile it, I got the following error:
Unable to find source file 'C:\Program Files\Microsoft.NET\Primary Interop Assemblies\Microsoft.mshtml.dll' for assembly 'Microsoft.mshtml.dll'
I looked and there is of course no directory by that name on my machine. I found this thread
How to add a reference to mshtml version 9 in .NET
but i am not sure it applies. I cannot find anything using "where tlbimp.exe". I have a backup of mshtml.dll which I recovered from my failed disk. Can I just copy it over and use it? Do I need to register it? Also, if I don't have it, what did I do different on this machine - could I have more/other problems later? Please advise.
I just had this problem, it was caused by changing from windows 32 to windows 64 because the path to the dll files is different. To fix just delete the reference and re-add it and it puts in the right path. Worked for me anyway :-)
ChrisP.
I'm developing a C#/WPF app that talks to a USB device using some custom 32 bit dlls. It's developed as an x86 app, and installed with WIX. When I install the package on a 64-bit machine, the program files get installed to Program Files (x86) as I expect.
The dlls are installed to the SystemFolder using WIX. On 32-bit machines, this means C:\Windows\System32. On 64-bit, they end up in C:\Windows\SysWOW64. This is ok, but when I run my app, it is unable to find the dlls (it uses them via [DllImport...]).
So, what is the right way to make my app find the dlls, whether they are in System32 or SysWOW64?
Thanks
Tom
If it is a default C# app, it will automatically be a 64 bit app on 64 bit Windows (C3 defaults to 32 bit on 32 bit Windows). Go into the project properties in your development app and explicitly set the architecture (I think; I don't have Studio up right now) to 32 bit. If it is running as a 64 bit app, it won't be able to use your 32 bit DLLs.
Please check if the dll in application is of the same version as that in the sys32 or wow64 folder depending on your version of windows.
You can check that from the filesize of the dlls.
Eg: I faced this issue because my libeay.dll file in system32 had a different dll than my libeay.dll file in openssl application. I copied the one in sys32 into openssl and everything worked well.
I have a .NET application that runs on both x86 and x64. I'd like to have a 32 bit WiX installer that will work on both platforms but I'd like it to install to /Program Files/ rather than /Program Files (x86)/ on 64 bit operating systems.
How do you go about doing this?
Update:
My idea was to assign the ProgramFilesFolder or ProgramFiles64Folder value to my own property, depending on whether it was a 64 bit environment or not, and then use that property value on the directory.
I have very little experience with WiX so if this idea is even possible I have no idea. If it is what would you test on to see if it is an x64 environment? Also how would you then assign a property value from ProgramFilesFolder or ProgramFiles64Folder depending on the earlier 64 bit environment test.
Any help is appreciated!
MSI doesn't support 32-bit packages installing to 64-bit directories.
While it's true that MSI's support here is weak, you might want to read the following article and comments then decide for yourself how you want to proceed.
http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html
I just found this, I tried your exact idea and no dice. You can't actually access ProgramFiles64Folder unless you are running a 64-bit installer.
I've given up and am just installing my 64-bit component to ProgramFilesFolder. It's not that nice aesthetically but it works :)
I was able to install a x32 package with WiX into the \program files folder usig the idea from http://blog.deploymentengineering.com/2008/01/even-developers-are-concerned-about.html which is to:
1 - use ProgramFiles64Folder for the directory
2 - change the setup project's settings to add a compiler switch. Its on the 'Tool Settings' tab and you add '-arch x64' to the compiler settings.
I have a solution which contains a project with a reference to a library that creates PDF files. The PDF library has a 32 bit version and a 64 bit version. During development, the project references the 32 bit version.
I am developing on a 32 bit machine. I have Cruise Control triggering a build every time I check something into my source control. The build server is a 32 bit machine.
Unfortunately, the code also has to be deployed to 64 bit machines. All of my code is managed and runs fine on the 64 bit machines, so it is just this PDF library that is causing a problem.
I think I need to create a Cruise Control project, which, on check in, opens the project file, replaces the reference to the 32 bit PDF DLL with a reference to the 64 bit version, then performs a build (Creating a build ready for a 64 bit machine).
Does anyone have any advice on the best way to go about doing this? My initial plan was to create a prebuild step, something like:
[prebuild]
[exec]
[baseDirectory]E:\Dev\CommonCode[/baseDirectory]
[executable]Replace32DllWith64Dll.cmd[/executable]
[/exec]
[/prebuild]
Which runs a .cmd file to do the replace, but I have no idea how to put the cmd file together, and am not sure if this would work anyway... Perhaps there is a more standard way for doing this sort of thing?
Any pointers would be much appreciated...
Thanks,
Paul
Ok, managed to solve this little conundrum:
Basically I created a quick and dirty VBScript which simply opens my project files, and replaces paths to the 32 bit DLL reference with paths to the 64 bit DLLs. I used a batch file to fire the VBScript.
I then updated the Cruise Control config file to tell the build process to execute the batch file, just before MSBuild does it's work.
Seemed to work well for me...
A full write up with further details and the actual scripts is available:
http://webpangea.blogspot.com/2009/09/cruise-control-with-msbuild-switching.html
Hope it helps someone.
Paul