I want to know how we can check the bitness (32 or 64 bit) of any WIM file programmatically?
I am using VC++ for development, i did enough googling but didn't get anything much about WIM file bitness.
DISM.EXE is your friend. Windows 8 or later...it has all sorts of information. Take a look at this link. One thing you can probably do is enumerate drivers. Look for the existence of x64 (amd64) in the architecture column for a coarse clue.
You could mount the wim (dism does that, too)...and then interrogate the registry. That's going to be definitive, but more of a pita and more time consuming. There's reg.exe...that will let you load a "foreign" registry hive - and you can load a registry hive from a mounted .wim. By all means, don't forget to unload the hive...or you will make the .wim very difficult to unmount.
If need be, you can run newer versions of DISM on older boxes (to get all this cool new functionality). There are architecture-specific versions of DSIM in the Windows ADK.
Related
Very Silly question. can someone quickly share me the Azure download link for 32-bit OS version from microsoft?
Regards,
Viswa V.
https://www.microsoft.com/en-us/download/details.aspx?id=48178
But instead of manually downloading, it is recommended you use the automated one-click install provided by the Web Platform Installer (x86 version here).
I don't think you will find that. I don't know if SDK exists, however Azure doesn't run 32 bit operating systems anyway for obvious reasons. Only 64bit operating systems are supported.
I need to determine whether a particular system has 32-bit Java installed. I'm doing a remote query that only gives me access to the filesystem and registry, so I cannot attempt to run java.exe, or run any Java code.
I also want to make sure I detect both IBM and Sun Java, as well as any other distributions, which seem to put things in different places on the filesystem and in the registry.
The best I've come up with is to check for C:\Windows\SysWOW64\java.exe. Is this a reliable way to test for the presence of 32-bit Java, or are there certain versions that won't put java.exe in that folder?
Update: I'm still looking for a more robust answer to this. Just to be clear, I don't have access to a command prompt. Also, I want to detect Java no matter who the publisher is, what version number is installed, and no matter what path the user chose to install it on.
C:\Windows\SysWOW64\java.exe seems to fit these requirements, but I'd love some confirmation from someone more knowledgeable that every Java installer will indeed put that executable there.
This seems to provide the info on Windows:
1.) Open a windows command prompt.
2.) Key in: java -XshowSettings:all and hit ENTER.
3.) A lot of information will be displayed on the command window. Scroll up until you find the string: sun.arch.data.model.
4.) If it says sun.arch.data.model = 32, your VM is 32 bit. If it says sun.arch.data.model = 64, your VM is 64 bit.
Do you have access to the command prompt ?
Method 1 : Command Prompt
The specifics of the Java installed on the system can be determined by executing the following command
java -version
Method 2 : Folder Structure
In case you do not have access to command prompt then determining the folder where Java.
32 Bit : C:\Program Files (x86)\Java\jdk1.6.0_30
64 Bit : C:\Program Files\Java\jdk1.6.0_25
However during the installation it is possible that the user might change the installation folder.
Method 3 : Registry
You can also see the version installed in registry editor.
Go to registry editor
Edit -> Find
Search for Java. You will get the registry entries for Java.
In the entry with name : DisplayName & DisplayVersion, the installed java version is displayed
Check this key for 32 bits and 64 bits Windows machines.
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
and this for Windows 64 bits with 32 Bits JRE.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Runtime Environment
This will work for the oracle-sun JRE.
just write "java -d64 -version" or d32 and if you have It installed it will give a response with current version installed
If it is not Oracle's Java, you may not be able to tell. When I install Oracle Java 64-bit, the files go into C:\Program Files\Java, but when I install a 32-bit version, they default to C:\Program Files (x86)\Java instead. Of course, the person who installed Java could have overridden those defaults.
I tried both the 32-bit and 64-bit installers of both Oracle and IBM Java on Windows, and the presence of C:\Windows\SysWOW64\java.exe seems to be a reliable way to determine that 32-bit Java is available. I haven't tested older versions of these installers, but this at least looks like it should be a reliable way to test, for the most recent versions of Java.
I want to make a registry filter driver specifically for Windows XP.
I know there is an example in the official WinDDK but it only works
on Windows 7.
Is it even possible to develop a registry filter driver for windows xp ?
Any kind of code/pointers will be highly appreciated.
You can also hook the registry API functions using Microsoft Detours (or similar package). This is no easy task to get correct (still finding the bugs) but if you are up for writing drivers then this is no different in complexity. Just less blue screens. Look at hooking the Nt or Zw functions in ntdll.
No this is not possible. For Windows XP you need to hack the kernel API table. This is not recommended, but for windows XP it is the only option. This is how the Sysinternals RegMon program used to work.
Yes, it is possible altought I would not recommend it.
First, you have to hook SSDT. Please notice that hooking SSDT is not supported in XP 64 bits (Patch Guard), you have to understand what are you doing (BSOD hook), is not portable and your software can be marked as malware.
Second, you need to do reverse engineering of Key Control Blocks. When two different apps open the same key, they get two different handles but they KCB is unique for both threads. KCB is an opaque structure so WinDbg is your friend here.
I made my application as install setup by install shield 5.0 on 32bit machine but before that i migrated my application into 64bit. after installed my application on 64bit machine, my application registry values are gone into under wow6432 node as HKLM\SOFTWARE\Wow6432Node(myapplication) but my application trying to read those values from HKLM\SOFTWARE(myapplication). could you please where is the wrong. what shall i do this case.
thanks,
KAM
Your install is 32-bit and it automatically writes to Wow6432Node on 64-bit system. You need to disable registry reflection or to directly write to 64-bit registry key (I don't know how to do that on install shield, but you should find it in the manual, search for Registry Reflection).
See my answer here on how to explicitly read the 32 or 64-bit 'views' of the registry. You have a few options depending on your situation - you can make the 32-bit version read the 64-bit view (so it'll use HKLM/Software. This means that you won't need to change the installer) or you could force the 64-bit version read the 32-bit view (this may be better if you need different options in the 32 and 64-bit versions)
We are getting new dev machines and moving up to Vista 64 Ultimate to take advantage of our 8gb ram. Our manager wants us to do all dev in 32bit virtual machines to make sure there will be no problems with our code moving into production.
Is there any way to guarantee the resultant programs will work on 32bit os's?
I don't mind using virtual machines, but I don't like how they force you back into a "Single" monitor type view. I like moving my VS toolbars off to my other monitor.
EDIT: We are using Visual Studio 2005 and 2008, VB.NET and/or C#
EDIT: Using Harpreet's answer, these are the steps I used to set my Visual Studio IDE to compile x86 / 32bit:
Click Build and open Configuration Manager
Select Active Solution Platform drop down list
Select x86 if it is in the list and skip to step 5, if not Select <New...>
In the New Solution Platform dialog, select x86 and press OK
Verify the selected platform for all of your projects is x86
Click Close.
Enjoy.
Thank you,
Keith
I do development on 64 bit machines for 32 bit Windows. It's not a problem. You should make sure that your projects are set to compile in x86 mode in order to be conservative. You'll want to go through each project in the solution and double check this. You could also use the AnyCPU setting but that's a little riskier since it will run differently on your dev machine than a 32 bit machine. You want to avoid the 64bit mode, of course.
The problems I've run into are drivers that don't work when the app is compiled for 64 bit (explicitly 64 bit or AnyCPU compiled and running on 64 bit Windows). Those problems are completely avoidable by sticking with x86 compilation. That should reveal all flaws on your dev machines.
Ideally, you could set up a build and test environment that could be executed against frequently on a 32 bit machine. That should reassure your management and let you avoid the VM as your desktop.
As long as you compile your executables as 32 bit, they will run on both 32 bit and 64 Windows machines (guaranteed). Using 64 dev machines has the advantage that you can start testing your code with 64 bit compilation (to check for things like pointers casted to 32 bit integers), this way making the transition to 64 bit easier in the future (should you your company choose to do a 64 bit version).
Compiling for a 64bit OS is an option in the compiler. You can absolutely compile to a 32bit exe from within Vista 64 bit. When you run the app, you can then see in the TaskManager that there is a "*32" next to the process...this means it's 32bit ;)
I believe your managers need some more education on what 64bit OS really means :)
Not an answer to your question, but possibly a solution to your problem: VirtualBox (and probably others) supports "seamless integration" mode, which just gives you a second start bar and lets you drag windows around freely.
Also, and this is an answer to your question, it depends on your compile settings. You can compile for different environments, and you can perfectly compile 32-bit programs on a 64-bit system with Visual Studio. Can't tell you how, but I'm sure some Visual Studio guru could help you out.
We develop a 32-bit application using VS 2005 (2008 soon) and have just purchased some new machines with XP Pro x64 or Vista Business 64-bit on them so that we can take advantage of the extra RAM whilst holding a watching brief on the possibility of doing a 64-bit port if it becomes commercially necessary to do so. We haven't had any problems with doing this other than tweaking some scripts in our development environment etc.
Those developers who weren't included in this upgrade cycle still use 32-bit machines, so these should pick up problems when the unit tests and the application test suite are run as a matter of course before a check-in.
What we also do is to make sure that we have a set of "test build" machines made up of "typical" configurations (XP/Vista, 2/4/8 cores, etc.) that build and test sets of check-ins - we have various different test suites for stability, performance, etc. - before they are added to the integration area proper. Again, these haven't picked up any problems with running a 32-bit application built on a 64-bit OS.
Anyway, as others have already said, I wouldn't expect it to be a problem because it's the compiler that generates the appropriate code for the target OS regardless of the OS that the compiler is actually running on.
yeah, like adam was saying. There's 3 options: MSIL (default), x64, and x86. You can target x64 and it will generate dll's specifically for 64-bit systems, or you can do x86 which will run on 32-bit and 64-bit, but will have the same restrictions as 32-bit on a 64-bit system.
MSIL will basically let the JITer issue the platform specific instruction (at a slight performance penalty compared to a native image)
EDIT: no language, so i'm talking about .net framework languages like vb.net and c#, c++ is a completely different animal.
Found this today:
http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx
x64 Development with .NET
Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact. For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).
In the world of x64 development, there have been a few struggling points that I thought I'd outline here. This list will likely grow, so expect future posts on the matter.
In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms. By default, applications and assemblies are compiled as Any CPU in Visual Studio. In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on. For example, when running an executable on an x64 machine, it will be run as a 64-bit process.
Visual Studio also provides for 3 specific platform targets: x86, x64 and Itanium (IA-64). When building an executable as a specific target, it will be loaded as a process of that type. For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer. When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU. For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.
This has come into play in a few scenarios for me:
XNA - XNA is available as a set of 32-bit assemblies only. Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform. If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller. See above.
Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses. The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only. The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.