Is there any solution to run a Windows XP executable on a Windows CE or Windows Mobile Device? Actually I think it is almost impossible or at least it would be very tricky however, I have a client says that the vendor of his Windows based application declared that the app runs on Windows XP as well as Windows CE.
Is this possible? Is there any way to convert Windows XP executable (native machine code) to Windows CE (running on x86 CPU) executable?
Native code won't work out the box because the Win32 and WinCE API's are similar, but quite different at the same time. Even when they overlap, WinCE expects the API to live in coredll.dll instead of system32.dll and friends.
If it's a simple app, and you know exactly what APIs are being called, you could write a wrapper coredll.dll that exposes the WinCE style APIs. There will be lots of unicode conversion involved!
If it's a .net compact framework application it will run if the app only references the parts of the API that are common to compact framework and the full .net framework.
It's possible to develop a cross-platform .net app that shares the bulk of the code, and has separate pinvoke layers for the CE and XP APIs respectively (if you are using them).
Converting the final executable may be well-nigh impossible in some cases, but if the vendor deliberately designed it to work on both systems, then it probably does (the task would be much easier for someone who possessed the source code).
Related
I Want to know if Windows CE 7.0 has same API and functionality with normal Windows system programming.
For example, i have to deal with serial(RS-232), TCP/IP, select() and so on in Windows CE 7.0.
Can i use all of API same as normal Windows?
Or there are some Difference between them ?
The API are similar, but you should expect some differences.
For example serial port drivers may not support asynchronous read/writes. This is supported in the OS (since ver 7.0), but I have seen no drivers actually using it.
Also socket API is similar but, as you know, evil hides in details.
As a general rule you can't take for granted that software running on Windows desktop (or "normal" if you prefer :)) will just need a rebuild to run on CE.
It will need at least a rebuild (and sometimes this may be clumsy if you are using different releases of Visual Studio).
We currently have a custom board with a microcontroller on it that speaks to a PC/104 windows CE 5.0 board through a dual port ram. Currently we use MmMapIoSpace to map the dual port ram in windows CE so we can read and write directly to it. We are looking to join the modern era of windows CE 6.0 or even windows XP embedded. A big concern of ours is that according to Microsoft's documentation MmMapIoSpace in windows CE 6.0 and in Windows XP Embedded are now driver level functions not accessible to in a user space program which is how we have been using it.
Before we go out and buy a lot of hardware and possibly a copy of platform builder we have been trying to figure out if it will actually be a problem and if so what we can do about it. None of us have experience writing windows drivers so that seems like a large undertaking however we would literally be writing a driver just to handle this one function.
Is it simple to port MmMapIoSpace from Windows CE 5.0 to Windows CE 6.0 or Windows XP Embedded. (links to Microsoft documentation).
Thanks!
MmMapIoSpace really should only be used by a driver in the first place, so earlier CE versions were simply a bit promiscuous in letting you use it from an app. I'd create a simple stream interface driver that interfaces with the RAM using MmMapIoSpace, and then call that driver from you app either using ReadFile or DeviceIoControl.
Stream interface drivers in Windows CE are very simple and straightforward. It's just a DLL with some specific entry points defined, and then registry entries to tell device.exe to load it. MSDN has lots of examples, but if you want even easier, there's a wizard on Codeplex that can generate the files for you too.
Is it possible to manually edit the driver to make it function on windows XP?
I guess there are many differences, but it must be possible for simple drivers, kind of porting the locations / buses they use?
Do you mean without re-compilation? If so its not recommended.
If you are willing to compile then use appropriate WDK and select appropriate build environment and try to build. You may have to change the code depending upon any APIs changed/availability.
Also note that drivers are compiled per OS i.e. there are different build environments for WinXP, Windows 2003, Windows Vista, Windows 7 etc.
I have a program built with VB6 and using some 32-bit DLL's. Will this program run on a 64-bit machine? This page suggests that it should run fine on the Windows on Windows layer, but what about the DLL's?
Yes, both the VB 6 program and the DLLs will work just fine on a 64-bit version of Windows.
Since both are 32-bit, they will run under the Windows-on-Windows 64 (WoW64) subsystem, which effectively emulates a 32-bit operating system on the 64-bit versions of Windows.
I've run many such programs myself with nary a hitch.
Beyond Explorer extensions and kernel mode drivers (neither of which you've written in VB 6), any compatibility problems that you might experience are almost certainly the result of bugs in your own code, which are easily fixed upon detection. Ask more questions about that when you find them.
Are the DLLs built with VB6 as well? Or are they native?
If you are dealing with 100% VB6, then in my experience, yes they tend to run with minimal problems (I maintained a number of plug-ins for another program that were mostly implemented as VB6 COM components, around the time that Windows 7 came out).
It will all of course depend on what libraries your code is using, whether or not you are accessing locations such as %PROGRAMFILES% etc, calling code in native libraries. These things can cause small problems but it is possible to work around them.
Microsoft are still supporting the VB6 runtime on 64-bit windows
Yes, it works, and if you have any problems they will help you.
I've always wanted a minimal windows NT build . Sounds like one's already there : MinWin. Can anyone tell me the exact design or architecture of MinWin and is it used in Windows 7 ? Windows Server 2008 already has a minimal Core build available for deployment . Why not Windows 7?
Windows Server 2008 R2 also has the same core build available for it.
Windows 7 is a client OS and it's highly unlikely that anyone would ever want to use a "core system" version of it. For instance the core server SKU doesn't have the ability to use any video cards beyond the basic VGA driver or have a shell - the only UI is cmd.exe. There's no .Net framework, no multimedia, etc. As I understand it from what I've seen on the web, Minwin has even less functionality than core server does - from what I've seen, it doesn't even support graphics.