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.
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).
I currently have a 32-bit PowerBuilder application that we are trying to port over to a Windows 7 64-bit environment. Realizing the obvious that PowerBuilder 10.5 was built previously before Window7 came out and the big also the obvious fact that this application was built within a Windows XP 32-bit environment.
The 32-bit PowerBuilder application spits out the following error message when deployed on a Windows 7 64-bit machine.
Application Terminated. Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow
The database profile setup points to an OLEDB and the backend database is MSSQL 2008. Currently the application does run on the Windows7 64-bit environment and seems to be working in an inquiry mode only. Meaning we can read some of the records on the datawindow, but as soon as you try to make a transaction it blows up.
My question is - Is it possible to get a 32-bit app working in a 64-bit environment?
So far the client is asking to come up with possible solutions without the idea of upgrading to PowerBuilder 12.5. Essentially they want to stay at 10.5 but yet get the app working from a 32-bit environment to a 64-bit...apples to oranges if you know what I mean. Further investigation is needed into whether the code will not function in 64bit or dll issues with powerbuilder client runtime in 64bit. They are really trying to stay away from any app rewrite since the application is older than when Christ was a carpenter. The app was originally built in PB 6.5 I think.
So far I have the following ideas but I am new to this:
- I understand that Windows 7 comes with a virtual machine IIRC. I think it's called WOW64. Is it possible to create a virtual on a server and have the users run a 32-bit application inside a 64-bit machine? Then create a shortcut of somekind for the user to simply click on?
We do have a virtual XP machine and a virtual Windows7 64 bit machine for testing. PowerBuilder 10.5 actually installed on Windows 7 and seems to be working fine. However running the application in run mode or debug causes many errors as you can imagine.
The application has been built in XP and run on Windows 7, but the results yeild the above error message.
I have not looked yet into the Run under Compatibility mode, but I am told by the team it will not work.
I have not looked at UAC or ALC User management yet. Could that be something affecting the 64-bit system?
I know this is app unrelated but...I have seen in some cases 32-bit applications work in a windows 64-bit environment by simply targeting certain DLL files. An example case is Microsoft Flight Simulator X where the 32-bit game would crash in windows 7 64-bit. The solution for that was to simply go get a Vista 64-bit DLL file called uiautomationcore.dll and copy that into the windows environment. The Games also have to be installed on the root of C: in order to work.
Does anyone have any recommendations on how I can approach this problem?
I apologize If I'm vague in my notes here.
UPDATE: Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine? I am wondering if the powerbuilder client runtime is installing its dlls into the correct location of the application C:\XXX or can't find it? Wondering how to approach this.
Basically nothing should prevent a 10.5 PB app to run on Win7/64. I develop and run several products in PB11.5 (also a 32bit IDE) on a win7/64. And btw, some older PB like 9 still run on Win7, so is likely PB6.5. The problem must be elsewhere, relative to the app design.
WoW64 (and Wow6432Node in the registry) is not a true VM, it's a bunch of services and system API hooked with fallbacks for 32 bit applications (and legacy applications that do not conform to the novelties introduced since Vista)
Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow sounds typically like an incorrectly handled return value (where a computed row number is getting negative or null before trying to access a property or data at that given invalid row), or it could be relative to the way to get back an autoincrement value from the db after an insert
beware of the UAC management that could lead to unexpected behavior with legacy application, especially if the application is using a database: the UAC guidelines tells not to install data managed by the application in the Program Files folder that is now Read only (since Vista - that guideline is since XP). Instead you must put that into a ProgramData sub-directory if it is accessible by everyone and into a user local AppData if the data is just for the current user. Win7/Vista can silently conforms to the standard by duplicating the data locally to the user (in the Users\username\AppData\Local\VirtualStore) while still pretending to the application that it is currently accessing it from Program Files...
you could give a try with Dependency Walker to look for the incorrect dll problems
We moved many of our applications to Windows 7 64bit. The only issue we ran into was with the database connections. You are running a 32bit application so you need to connect to 32bit database. If you bring up "Data Sources (ODBC)" from the control panel, you will be looking at the 64 bit entries. You need to use the 32 bit ODBC found in "C:\Windows\SysWOW64\odbcad32.exe". The Registry entries you need are in the following locations...
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
or
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
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.
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).