are there any specifics when developing a device driver (kernel-mode) on Windows 7 32 bit or Windows 7 64 bit? Can I develop on some platform and prepare builds to run on the other one?
Thank you.
You need the Windows Driver Kit. Yes, you should be able to cross-compile.
That's what MSDN is for: 64-bit System Design
http://msdn.microsoft.com/en-us/windows/hardware/gg566940
If you don't do anything funny, producing a 64-bit driver shouldn't require any changes except for a rebuild.
Here are some possible source code bugs, which could arise while going from 32-bit to 64bit versions.
Related
We are moving from CefSharp to WebView2. Because of certain requirements, we are thinking of going ahead with the fixed version where the updates can be controlled by us. Now, on Microsoft's official distribution page we have 3 options available - x86, x64 and ARM64. We have users who use different combinations of OS and CPU architecture. One example is 32 bit Windows 10 Pro running on a 64 bit Intel processor. Here is where I am confused. Which one to ship to agents depending on their combinations of OS and CPU architecture. Can anybody help here? Here are the combinations -
I have not tried out and hence may be a blunt question - can x86 distributable be a safe bait for all these combinations? If yes, then what are the trade-offs?
I think x86 distribution is safe. If 32-bit OS is running, the entire system acts as purely 32-bit. It's impossible to use any 64-bit piece of code, so 64-bit applications won't work. You can also check this thread: If you want to run 64-bit app on 32-bit OS, you have to install a VM or something. I think that's not what you want.
In conclusion, I think you should choose the WebView2 Fixed Version according to the OS version.
I want to create a 16 bit Dos application and want it to run using the NTVDM.exe on my 32bit windows 7 machine. How do I do it?
I basically want my application to do the file operations through the NTVDM and for that I think I'll need a 16 bit application first, Is there any other way?
I don't need an Emulator, I need to create an 16-bit app
A couple free C/C++ compilers that claim 16-bit (MS-DOS and Win16) support are the Digital Mars compiler and the Open Watcom Compiler.
The Open Watcom webpage is unresponsive at the moment... There's a SourceForge download page though.
The last Microsoft Visual C++ compiler for 16-bit was 1.52c, available on MSDN Subscriber Downloads.
For free ones, see Looking for 16-bit x86 compiler.
I am taking a computer architecture class, and we are learning assembly language on 16 bit machines. On-campus department labs have these machines available, but I want to be able to work on labs at home.
Where can I download MASM that can run 16bit code, I,m sure there is a way to do it, i just have to link 16 bit.
You can use dosbox, dosemu, or something similar to emulate an old x86 DOS machine, and run your 16-bit code on that.
I know this is 6 years ago, but to help others. Current MASM on Microsoft website is mainly for 32 and 64bit but you can get old versions here: http://bytepointer.com/masm/index.htm. and another one here http://www.masm32.com/licence.htm
I found that only old versions of MASM with FreeDOS, XP, DosBox etc will enable you to run the 16 bit code. You cant run 16bit executatable in a 64bit System.
Please let me know if it works.
I am developing a 64 bit application. Is it possible to run the 64 bit application on a 32 bit OS?
Please note that the question is generic and not specific to Windows OS. Infact the application in itself is portable across OS.
(We'll assuming your talking about AMD64 (== EM64T == x86_64) and x86 for 64-bit and 32-bit respectively)
You can run AMD64 code on x86 processors only by emulation (e.g. qemu), or some kinds of virtualisation (I believe VMWare might support 64bit guest OS on 32bit host OS on 64
bit capable CPU). However this means running a 64-bit OS as a guest on emulation or virtualisation I believe.
As you're developing the application, it shouldn't be too hard to develop both 32-bit and 64-bit builds of your code.
For Mac you can ship a single binary that has both types of code in it, or Mac OSX can run your 64-bit binary on a 32-bit kernel (only on a x86_64 capable processor though). For Windows and Linux, you'll either have to ship separate installers, or ship some smart installer, that selects the correct binaries at install time. For Linux there is a project for add the ability to run AMD64 code on x86 kernel on AMD64 processor - http://linuxpae64.sourceforge.net/ - but it doesn't look like it's got very far into the mainline kernel.
Is there a particular reason you only want to produce 64-bit binaries?
If it's to access extra memory, then the 32-bit OS wouldn't be able to give you extra memory anyway.
If it's to avoid have to test 2 different versions, then just produce the 32-bit version, it'll work on Windows AMD64, and most Linux AMD64 distributions without problems.
On windows, only using a virtual machine.
On OS X, 64Bit apps run natively (thanks Stephen)
The other way around is fine, bit I dont think you can run a 64bit app on a 32bit OS, you may be able to using a virtual machine or some kind of virtualisation.
There's an easier solution than trying to run a 64-bit program on a 32-bit OS (including executing through an emulated or virtual 64-bit platform on top of the 32-bit OS): recompile it for the 32-bit OS.
When you said it's portable across different OSes, did you also mean non-64-bit OSes? I could not call something portable without qualifying "only 64-bit" if that was the case, and I think many (maybe even most?) programmers also expect that qualification, at least currently.
it is possible using qemu in soft emulation mode
No.
See Microsoft FAQ:
The terms 32-bit and 64-bit refer to
the way a computer's processor (also
called a CPU), handles information.
The 64-bit version of Windows handles
large amounts of random access memory
(RAM) more effectively than a 32-bit
system. For more details, go to A
description of the differences between
32-bit versions of Windows Vista and
64-bit versions of Windows Vista
online.
Understand the difference between 32-bit and 64-bit and you will see why it's not possible.
See this (assuming you're running Windows):
If the program is specifically designed for the 64-bit version of Windows, it won't work on the 32-bit version of Windows. (However, most programs designed for the 32-bit version of Windows will work on the 64-bit version of Windows.)
Device drivers designed for the 64-bit version of Windows won't work on computers running a 32-bit version of Windows. To learn how to check for drivers, see Update a driver for hardware that isn't working properly or go to the device manufacturer's website.
On Windows, no. On OS X, yes. I don't know what the state of affairs is on Linux.
In fact, Snow Leopard boots into a 32-bit kernel, but compiles applications 64-bit by default, so this is quite common on OS X.
A 64 bit application does not run on a 32 bit processor period
A 64 bit application uses a 64 bit wide register. It just plain won't fit.
I have a WPF app that uses Flash10c.ocx developed on a 32 bit machine. I didn't have to register the ocx on my dev machine, I just installed the latest flash, added a reference and started coding. When testing on a 64 bit system I get ye old "Class not registered" which I think mean I need to regsvr the ocx. Is it Ok to just copy the 32 bit ocx (I'm pretty sure its 32 bit as its located in C:\Windows\System32\Macromed on the dev system) to a 64 bit system and register it?
Update: regsvr32 /i flash10c.ocx errors out with "The module flash10c.ocx las loaded but the call to DllRegisterServer failed with error code 0x80004005"
Update 2: I've given up on this and decided to run Flash on 32 bit systems only. If anyone has a better answer I'd like to hear it but I'm marking the current suggestion as answered to give due credit for the effort.
The reason it's not working for you is that your WPF application is running as 64-bit.
A .NET application is able to run as 32-bit or 64-bit; and the CLR is JITing your app to whatever architecture the application is running on - in this case 64-bit.
Except you now want your 64-bit application to load a 32-bit dll. This is not possible. A 64-bit process can only load 64-bit dlls. A 32-bit process can only load 32-bit dlls. No amount of fiddling with COM object registration will change this; it's not a question of missing registry entries.
Adobe Flash only comes as a 32-bit dll. Adobe does not now (and hopefully will never) have a 64-bit version.
In order for your WPF .NET application to load the 32-bit flash dll, it needs to be running as 32-bit process. There is a way, in Visual Studio's build configuration, to force your .NET application to only target x86, rather than Any CPU.
The choices of CPU targets are:
Any CPU
x86
x64
Itanium
Flash, for what it's worth, doesn't have an Itanium version, either.
See StackOverflow: Visual Studio “Any CPU” target for more discussion about target cpus.
May be the flash installer is meant to be only for 32 bit OS. Hence it did not install properly on a 64 bit machine. The error means that you will need to manually register the ocx but will it register successfully that's a totally different question.
Edit 1: here is Adobe's statement of support for 64-bit systems (there is none) (I assume you are using 64 bit browser on a 64 bit machine)
Edit 2: Another forum message about Flash on 64-bit Windows.