I wanted to know what version of pyodbc dll could be used for
Python 2.6 under Windows Server 2008 R2 Enterprise and appreciate if link for the same will be provided.
Although i got all versions of pyodbc.exe here but i would be needing dlls compatible with above mentioned operating system. Best
Seems pretty straightforward...use either the 32-bit or 64-bit installer based on your server's processor architecture.
Related
Are binaries built on Windows 7 guaranteed to work on 8/Vista, 10, and 11?
Are binaries built on Windows 10 guaranteed to work on Windows 11?
I've seen some things that make me wonder if Windows 11 is still technically Windows 10 in at least some ways that might ensure apps built on Windows 11 be sure to run on Windows 10?
I'm worried not just about the EXE format but for instance the shared library APIs etc. One can build, I'm sure, on a newer Windows and use a DLL, or a function in a DLL, that doesn't exist on the older Windows.
All versions of Windows support the same "Portable Executable" format for EXEs, but it all comes down to (a) the linker settings in the metadata of the binary, (b) the architecture for the processor, and (c) the APIs it needs to import.
If you build a Win32 classic desktop application using _WIN32_WINNT=0x0601, the WINAPI_FAMILY_DESKTOP API partition (the default), and use a recent version of the VC++ toolset, it will set a linker value of "6.00 operating system version". The resulting binary is compatible with Windows 7 SP1, and depending on exactly what APIs you use it might work on Windows Vista SP2 as well. It will also be forward compatible to Windows 8.x, Windows 10, and Windows 11.
Both x86 and x64 Windows support 32-bit applications, although x64 Windows does not support super-old 16-bit Windows programs that technically work on 32-bit Windows.
There are many application compatibility bugs that can make a program that should technically work on a newer version of Windows fail, but these can be avoided by just testing on newer versions of the OS before shipping.
Officially the modern VC++ toolsets, the Visual C/C++ Runtime, and Windows SDKs do not support Windows Vista, Windows 7 RTM, or Windows 8.0 development.
See Microsoft Docs.
Recently i upgraded my visual studio 2008 installer project to InstallShield Limited Edition project into Visual Studio 2013. I was able to build the solution from visual studio and from my Nant build script. My solution build platform is x86/Release and my installshield limited edition project build platform is singleimage without specifying any platform. My computer is Win32 and i installed installshield limited edition for 32 bit.
Now i added one merge module in the InstallShield Limited Edition project which can be run in both Win32 and Win64. The signature of the merge module specifies that it can be executed in both Win32 and Win64.
But as long as i added the merge module and built the solution, i got the following error
ISEXP : error : -5008: This 32-bit package cannot include 64-bit data. The 64-bit data may come from a merge module.
My merge module is developed by other party and they said it should be worked in both Win32 and Win64.
When working with Windows Installer, you have to choose between making a 32-bit or a 64-bit package. The 32-bit package can install on a 64-bit system but can only access 32-bit locations; the 64-bit package cannot install on a 32-bit system, but can access 64-bit locations on a 64-bit system.
The error you quote is to avoid letting a merge module change your whole package from 32-bit to 64-bit, as that can cause you compatibility problems that are difficult to diagnose. If you want to use that merge module as is, you must do something in your project to indicate you want a 64-bit package, such as adding a file or registry key that installs to a 64-bit location. Alternately, if you need to support 32-bit systems, you should request the other party properly separate their 32-bit and 64-bit merge modules.
I want to check whether my pc is 32 bit (or)64 bit operating system using inno setup.
And how can i check whether .net framework 4.5 is installed in my pc? if not installed how to give .net framework 4.5 package from my setup using innosetup?
And how to install .net framework 4.5 from web using innosetup?
Regards,
Lokesh.J
Detect OS is 32/64 Bit look at this.
how to detect 64bit platform by script.
To check what .NET Version is installed try use this script.
http://www.kynosarges.org/DotNetVersion.html
.NET Installer you can look at this.
http://www.codeproject.com/Articles/20868/NET-Framework-1-1-2-0-3-5-Installer-for-InnoSetup
Just search on Google and you will find all the answers you need. Hope this helps.
I am converting some 32-bit .Net apps to x64. Enterprise Library 5 (32-bit) is used in a bunch of our apps, so I am under the impression that when we re-compile those in x64, then we will need to pull in a x64 version of EntLib. Does anyone know if that exists? I keep searching and I can't seem to find a straight answer - I find burbs about x64 configuration manager tool, but no info about a installable 64-bit version of EntLib5.
The entlib assemblies are architecture neutral. They can be loaded by either 32 or 64 bit processes with no changes.
On a 32-bit process, they'll run as 32-bit. On a 64-bit process, they'll run as 64 bits. No changes needed.
Remember, they're IL, not native code, and don't call into anything native, so there's no bitness dependencies.
Is the package type (x86 or x64) dependent on my application type or on the OS type it is installed on?
I.e., if I develop a 32-bit application do I need to
deploy the x86 package only or
deploy both packages and install x86 on 32-bit windows and x64 on 64-bit windows?
The answer to this question 32-bit VC++ redistributable on 64 bit OS? suggests that it's only the x86 package, so it would be dependent on my application but it doesn't give any explanation/links.
The MS download sites are also not specific on this.
When you compile, all use of the standard library creates references that must be resolved at link time. The linker bakes in the import library for the matching runtime DLL(s), which must be matched completely at load time. That means matching the compiler version, service pack, and bitness.
Also remember that a 32-bit process cannot load 64-bit DLLs. Because the 64-bit redist only contains 64-bit DLLs, it is of no help when loading a 32-bit executable.
it depends on the application if you need to maximize the potential of 64-bit OS, you may deploy both for handling 64-bit and 32-bit processing. However, if your application did not exceed the limits of 32-bit, you may deploy the application on x86 only, anyway it should also work on 64-bit OS via 32-bit virtualization.