I have a universal app that uses PlayReady DRM protected videos. The problem with PlayReady is that it only work if the application build architecture matches the CPU architecture (e.g: ARM build on ARM, x64 on 64bit CPU, x86 on 32bit CPU). This is by design (for some reason).
So the problem is, if a user has a 64bit CPU and runs a 32bit OS. In this case, he gets the x86 build from the store (because of 32bit OS) but PlayReady will not work because of the 64bit CPI vs X86 build mismatch. In this case, I want to display a message (instead of just failing to play the video).
I can detect easily detect x86 build (by adding a conditional symbol), but how do I detect if the CPU is 64bit? There is nothing like System.Environment.Is64BitOperatingSystem from the full .NET.
You are allowed to P/Invoke Win32's GetNativeSystemInfo in Windows Store apps (more info on the P/Invoke signature here); it returns a structure that includes the processor architecture.
I can't find any information about what it returns in an x86 Windows on x64 machine scenario, and I don't have such a machine on hand to test it, but it's worth a try.
Related
I've studied the information about building apps with a different target platforms options in visual studio, but I still can't understand the following things:
when do we need to set x86 or x64 target?
what advantages gives us setting a specific target platform (x86 or x64) over setting 'any cpu'?
isn't it easier always to set 'any cpu'?
There are three options in the platfrom target as of now. x86, x64, Any CPU. To complicate thing even worse, there is a checkbox called "Prefer 32bit".
When you are developing applications you have to make sure its Any CPU is Enabled and Prefer 32bit is disabled for maximum compatibility.
However some times you will be using native calles to platfrom specific APIs (eg: you are calling a 32bit native dll). Then enabling Any CPU will run your application as 64bit process in a 64bit operating system. This will indroduce exceptions in the runtime. You should be targeted to x86 platform. Same goes for 64 bit native calles, you should target it as x64 only.
Lets see why Prefer 32bit is there. Windows has a new target type called ARM (Windows 8 ARM 32bit as of the date Prefer 32bit is introduced). When this option is enabled and Any CPU is selected. A .NET application compiled to x86 will fail to run on an ARM Windows system, but an “Any CPU 32-bit preferred” application will run successfully.
Going forwards disable Prefer 32bit since nobody used Windows 8 ARM. Windows 10 ARM have resolved this issue.
My application is built as a x64 application. After moving to VS2010 I got some problems which seems to be related to some x64/x86 mismatch in referenced dlls. Now I'm moving to target .NET4, and I get even more similar problems.
My question is: What precautions do I need to take regarding mixing x64 and x86. Can it be done at all? I thought x64 applications should be able to use x86 dlls without problems. No? What about the other way? Can a x86 application reference an x64 dll - as long as it is being run on an x64 platform? What are the pitfalls I need to be aware of?
No, a 64-bit process can only load 64-bit DLLs and a 32-bit process can only load 32-bit DLLs. What you're probably thinking of is that a 64-bit operating system can run 32-bit processes.
The main issue with .NET is that - prior to VS2010 - executable projects defaulted to "AnyCPU" which means it would load in the "native" format of the OS it's running on (so 32-bit for 32-bit versions of Windows and 64-bit for 64-bit versions of Windows). The problem with that is that if you tested your application on 32-bit Windows (say) then it could break if you load 32-bit DLLs and tried to run on 64-bit Windows.
In VS2010, they defaulted all executable projects to be "x86" (that is, 32-bit) by default which (for the most part) mitigates the problem.
You can run x86 apps on a 64 bit OS using WOW32 emulation. Some pitfalls that I have encountered - you can't mix and match 32/64 in the same process. So if you intend to run IIS as 64 all the assemblies need to be 64 otherwise you'll have to run In 32 bit mode. 64 bit helps some apps more than others. Running SQL sever's 64 bit version provides several advantages over the 32 bit version, biggest advantage being that yo can install more than 4 GB of memory on the target server and that SQL will be able to use more than 4 GB of memory. It does not benefit IIS as much because IIS typically can't use more than 3 gb of memory. My advice would be to make sure your SQL server/os/version are 64 if possible. It's not going to make a. Huge dfference if the other servers are 64 but typically it's easier to work with and find 32 bit versions.
Supposing I have a windows app developed based on C#. I want to ensure that it works on 32 bit and 64 bit both. But I don't want to change the config settings or application settings time and again. Is there a way to test both variants?
There are a couple of options.
You can target AnyCPU. If you're program is 100% C#/managed code, with no native dependencies, this will cause it to run 64bit on 64bit Operating systems and 32bit on 32bit Operating systems.
Target x86. This will cause it to run 32bit everywhere, which works properly on 64bit Windows (via WOW64). This works properly if you're using native (32bit) libraries, as well.
Make two builds, and two separate deployments. This allows you to use native code and still run 64bit on 64bit operating systems, but is far more work.
Since 32bit applications run well on 64bit operating systems, there is rarely reason to run the program natively in 64bit. This is typically only really beneficial if you're processing large amounts of data and truly need access to larger memory space than you can get in 32bit processes. In .NET, this typically means you'll want to build 64bit if you're going to use more than 1.2-1.6gb of RAM for your program. Otherwise, 32bit will work fine everywhere.
If you target AnyCPU, most .NET programs will run unaltered on 32-bit or 64-bit machines. The code will be jitted to 32-bit or 64-bit code as appropriate for the target operating system.
The exception where you need to use care is when using interop to unmanaged code.
If you do interop to unmanaged code and require to run as 64-bit on a 64-bit platform, you will have to make two builds.
If you do interop to unmanaged code and can accept running as a 32-bit process, target x86. That avoids two builds, and will run your .NET code as a 32-bit process in 32-bit and 64-bit platforms.
This question relates to these previous question on SO
Any CPU question 1 and Any CPU Question 2
I have a application which was originally built on Win XP using Visual Studio 2005 (don't laugh!). This app calls into our win32 C++ dll. The C# components which call the C++ dlls were built with the "Any CPU" configuration and have been happily working on Win XP without any issue.
We are now moving to Win 7 and the release version of our app (which was built on Win XP with VC 2005) works fine. However with the roll out of win 7 to our users we have now taken the opputunity to move to VS 2010 and I have built the C# components on win 7 with VC 2010 but now when running this version I get lots "unable to load abc.dll" where abc.dll is our win32 c++ components.
I understand that recompiling the C# assemblies with x86 config will solve the problem but what I don't understand is how the release version c# assemblies built with Win-XP/Visual studio 2005 (Any CPU config) are able to run on Win 7 without any issues? Surely these C# assemblies built with "Any CPU" should JIT to 64 bit code when loaded in Win 7 and cause BadImageFormatException or other errors because they call Win32 C++ dlls.
UPDATE : I have Some more information that have been requested in the comments below.
On my Windows 7 box I right click on my computer and look at the properties. The System information says "System Type : 64 bit operating system" confirming this is a Win64 OS.
Opening up the solution in VC2005 on Windows XP When viewing the configuration manager for the solution I can confirm ALL the C# projects are platform type "Any CPU".
When running the release build (which was done on VC2005/win xp) on 64bit Win 7 machine, I task manager shows the image name as "Test.exe *32", this confirms it is jit'd and loaded into 32bit process.
Under Win7, the process is 64-bit. 64-bit processes cannot have 32-bit DLLs in them, that's a pretty fundamental design limitation of Windows.
And the fact that this managed code EXE calls into a 32-bit DLL is not obvious from the get-go - P/Invoke, as well as COM interop, works via late binding. So the EXE is loaded, the loader does not check the dependencies - for one thing, the dependencies might be conditional - then the DLL loading time comes, wackiness ensues.
So yeah, if you have managed code with known 32-bit dependencies, you better specify a 32-bit CPU at compile time. Or recompile the C++ parts to 64 bits, that's also an option.
I can confirm that you should get BadImageFormatException. Is it possible that the compilation on XP was monkeyed with badly enough that it's not actually building AnyCPU but rather builds x86 labelled as AnyCPU. I can also confirm it's possible to monkey with a project file badly enough that it would do that and the project upgrade component chokes on that.
One possible explanation is that one of your projects in the solution on the 32-bit development system had a binary reference to a 32-bit assembly, which would force it to be loaded as a 32-bit process even on 64-bit systems.
I have got a .net application,
Class library (Target Platform set to Any CPU)
Winform Application (Target platform set to Any CPU)
Installer (Target Platform set to X86 and Detected dependencies set for .net framework(x86))
Now when I install this application through setup.exe on a 64-bit machine, it is installed in the Program Files [x86] folder; I guess this is WoW64 feature of emulating 32-bit environment on a 64-bit application.
Now when a client asks to convert it to 64-bit, why does it matter to him if the 32-bit version itself works fine through WoW64? would converting it to 64 bit result in performance benefits?
And when I try to convert it to 64-bit, do I need to change it for all, ie ,
Class Library (change Target platform to 64) (What if I skip this step?)
Winform Application (change target platform to 64) (What if I skip this too?)
Installer (change target platform to 64) [Detected dependencies listing doesn't show any .NET framework x64 option, why?]
Please suggest.
No conversion is necessary, your app already runs as a 64-bit process. Because you used AnyCPU on the EXE project. You installed it to the wrong folder but that doesn't matter much if no other process tries to start yours programmatically. That's exceedingly rare.
Verify this from TaskMgr.exe, Processes tab. A 32-bit process has *32 after its process name.
Make your client happy by changing the Setup project's TargetPlatform setting to x64 so it gets installed in c:\program files. Takes you a few minutes.
You can leave the .NET code projects on AnyCPU, however to install onto 64-bit without hitting the 32-bit WOW stuff you need to change the installer project property that you mention.
If you have custom actions in the installer, these may not work when you change to 64-bit. You might get a BadImageFormatException. To resolve this, you need to faff with the resulting MSI:
http://adamhouldsworth.blogspot.com/2010/10/64bit-custom-actions.html
It won't make much of a difference to the client if your application is standalone. There is no free performance benefit, other than access to more RAM, when going to 64-bit (though the JIT has different types of optimisations available).
The only situation I've seen where 64-bit is required is when you consume that DLL in another application, you cannot mix bit-ness in a single process.
Update: perhaps the lack of a 64-bit framework prerequisite is because you are using VS 2005?
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7b00f4e9-64e3-4fb6-9906-880820ecda92
64 bit may or may not give performance differences. A 64 bit application can also utilize (way) more memory than a 32bit application.
If you launch an AnyCpu exe on a 64bit OS it should launch in 64bit (see in the task manager, 32bit processes are appended with *32 there). If you set the application to x64, the library must be either x64 or AnyCpu.
If you do not have native x64-only references you can leave your exe and dll as AnyCpu, but you will need to modify the setup to x64.
As for the framework, on an x64 machine (which is the only place an x64 app will run anyway), the framework always includes both 32 and 64 bit, found in C:\Windows\Microsoft.NET\Framework and Framework64 respectively.
Now when i install this application through setup.exe on a 64-bit machine, it is installed in the
Program Files [x86] folder; I guess this is WOW feature of emulating 32-bit environment on a 64-
bit application.
No, it has NOTHING to do with the program, only with the installer.
•Installer (Target Platform set to X86 and Detected dependencies set for .net framework(x86))
32 bit installer installes it in the 32 bit folder for programs, regarless whether the program is 32 or 64 bit.
Sadly you can not have one installer doing both - you need an installer for 32 and one for 64 bit in concept, by design.
This is totally a design decision on the MSI part and, again, has nothing to do with the program at all.