When running a standard Windows 7 Installation Disk in recovery mode, if you open up the command line and run a custom-built application you will receive the error 'subsystem not supported'. I have tried linking with /SUBSYSTEM:CONSOLE, WINDOWS and NATIVE, none of these work.
I had a little difficulty with a partition table (and may have found a bug, or at least 'stupid' behaviour from the partition manager included in windows) and so wrote a utility to fix it. My program uses 'Windows.h' to import CreateFile, however if need be I can use only standard C++ (Or even standard C) with no windows specific headers.
What do I need to do to get an application running?
The Windows Recovery Environment is a superset of the Windows Preinstallation Environment.
Windows PE is a stripped down version of windows, lacking many subsystems including WoW (Windows on Windows).
This means that 32bit executables (or anything with a 32bit component) WILL NOT RUN on a 64-bit Windows PE disk. (Note that WinPE 32 cannot install/repair 64 bit systems and vice-versa).
The solution to my problem was to compile to 64 bit code -- a descriptive error message would have been nice Microsoft :|
Found after much searching:
http://technet.microsoft.com/en-us/library/cc766093(v=ws.10).aspx
Are you using the C++ CRT in any way? I don't think that's supported. I'd even doubt that CreateFile is appropriate; and look into NtCreateFile instead.
Related
We have a minimum System requirement of Server 2012 and Windows 8.1.
We have programs written on C++.
Some programs in our Setup still don't use newer DLLs and start on a Windows 7 or Windows 2008 R2. Some use newer DLLs and don't start with a message that such a DLL isn't found.
Is there a way to prevent the start of a program on an old Windows System with a manifest or something similar? I would prefer that the user don't see a "DLL not found message".
The best way: Windows Loader tells the user that the executable doesn't match this OS.
I know that this works for Windows executables of the OS. Copying a newer EXE from Windows 10 to an old Windows version, even if new specific DLLs are not used.
Is it safe to assume that any x86 compiled app would always run under x64 edition of same OS the app was compiled in?
As far as I know, For Windows OS the answer is "Yes". Windows x86 emulation layer is built for the same purpose. But, I just want to reconfirm this from experts here.
What about Unix, Linux? Are there any caveats?
No, for x86 code to run it need to be run in compatibility or legacy mode. If the OS doesn't support running processes in compatibility mode the program would most likely not being able to run.
Linux and IFAIK Windows currently supports compatibility mode and it looks like many more are supporting it too, more or less. My understanding is that NETBSD requires a special module to support this, so it's not necessarily without special care that it will be supported and it shows that it's quite possible that there exists OS'es where the possibility has been dropped completely.
Then in addition there's the possibility of breaking the backwards compatibility in the future, that's already happened on the CPU as virtual x86 mode is no longer available from long mode that is you can't run 16 bits program anymore under 64-bit Windows or Linux.
It could also happen on the OS side, that the developers could decide not to support compatibility mode anymore. Note that this may also have happened as it might be possible to support virtual x86 mode by first switching to legacy mode, but if possible no-one seem to have bothered doing it. Similarly neither Windows or Linux developers seems to have bothered implementing possibility to run kernel code in legacy mode in 64-bit kernel.
The preceding two sections shows that there are future or even present indications on this might not always be possible.
Besides as this is a C++ question you would have to ask yourself the question why you would want to make such a assumption? If well written your code should be able to be compiled for 64-bit mode - for you haven't relied on data types being of specific width, have you?
No. We have a whole bunch of Debian servers which miss the Multi-Arch i386 (32 bits) libraries. On Windows Server Core, WoW64 (the 32 bit subsystem) is optional. So for both Linux and Windows, there are known 64 bit systems that won't run x86 executables.
I've been looking all over google for this but never got a clear answer..
I'm trying to write a simple hello world application and make it run under msdos (which I will be installing on a old rig lying around here).
But first things first, I've been trying to compile a normal console application and drop it in dosbox to test it out which doesn't work, just says it's invalid. So I assume I need something else to compile it with. Does this mean I'm obligated to build my code in a msdos environment? Even if this is the case, I have no clue at all how to do this, kinda a msdos dummy..
If anyone can shed some light on my case I would be very grateful!
P.S: I'm running a 64bit system
You can use the free DJGPP compiler for DOS. And here is the documentation for using DJGPP.
I'm assuming that you mean actual DOS and not a command prompt running in Windows.
DOS is a 16-bit OS, so you will need a compiler capable of generating a 16-bit binary. A Windows console application is 32-bit, so it won't run under DOS. You don't have to build your code in a DOS environment, you will just need the right compiler.
As for compilers, you might want to check out OpenWatcom.
Microsoft Visual C++ 1.52 is the only available version of a Microsoft
C++ compiler that supports compiling 16-bit code.
http://social.msdn.microsoft.com/forums/en-US/Vsexpressvc/thread/cfc848e8-a797-42a5-8537-892cfc234123
You need to find an old compiler that will generate 16bit COM files.
Could running it on a 64bit system be an issue?..
Yes, 64-bit Windows cannot execute a 16-bit program. If you install a virtual PC with MS-DOS or a 32-bit Windows system, the virtual PC will be able to execute a 16-bit program.
Do you need to edit your question to say that you're using 64-bit Windows?
It sounds like you are compiling a console app on a modern version of Windows and trying to simply copy it to an old DOS box. The problem is that DOS is not forwards compatible. You cannot run a program compiled with Windows 7 on pre-Windows versions of DOS. The simplest solution is to compile your programs on the DOS box itself. Alternatively, if you want to develop on a newer machine, you need to get a cross-compiler which targets the OS where you want to run your program.
I have a question about writing programs to be portable between windows and linux.
Recently I have realized that if you write a program that uses any sort of external library, if that library doesn't have a linux version (or a windows version when developing in linux) then you're screwed.
Here then is my question: if I write a program in linux that links to lol.a and then I want to compile and run it on windows without recompiling lol.a into lol.lib, can something like MinGW or Cygwin do this? Link to .a files on a Windows platform to result in an .exe file that can Windows can run?
you will have to recompile all libraries for different operating systems. The binary formats for libraries vary from operating system to operating system. More importantly, even if you aren't using libraries, you need to recompile for the simple reason that the different operating systems have different syscall conventions. The only way to get around this is with a virtualizer.
In particular, CygWin cannot run linux programs. at all. CygWin provides only a posix compatibility layer between your program and the Windows kernel.
The situation is a bit less bleak on linux. Wine can run some native windows code (without the need to recompile anything, including your original code). But Wine also has limitations. It is not a complete Windows API, and anything that the library code requires to run must be available on Wine, or else it won't work either. For many, simple apps, this isn't a major problem, but many newer Windows API's, some dark corners of older ones that don't see much use, and in particular, anything that is hardware specific, probably won't be available.
If you intend to run on multiple platforms, it is urgent that you first verify that the libraries you intend to use are also cross platform, or that there are reasonable equivalents for all of the operating systems you wish to use.
No, Cygwin provides (partial) source portability for *ix programs. Of course, there are higher level toolkits that also provide source portability, like QT and GTK. Either way, you still have to recompile the program and library. For binary portability, you'd need essentially the opposite of wine, a program that understood ELF and mapped Linux system and library calls to Windows ones. As far as I know, that doesn't exist.
No. You have to build it separately for Windows or Linux.
There are couple of suggestions given your situation:
Develop the entire code for Windows, compile and run it.
On Linux, use the WINE emulator http://www.winehq.org/download/
If you choose to develop the code in Linux, look into Windows SFU http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX
If possible post us what kind of s/w you are trying to develop -- 3rd party libraries like boost [http://www.boost.org] have a whole host of functionality that is platform independent. You definitely want to check out the options that boost gives you. Also check out other open source sites like github etc.
Don't get into the habit of using platform specific libraries. I know they make life easier at times, but that is more than compensated when you need the code on a different platform.
I have a small piece of code that works as a plugin for a larger graphics application. The development platform is Qt with c++ code. I've managed to build a .so, .dylib and .dll for linux, MacOS and Windows respectively, but to do so I had to have a machine running each operating system (in my case, running linux [ubuntu] gcc natively, and windows MinGW and MacOS XCode gcc in virtual machines).
Is there a way to build for all 3 platforms from one? I beat my head against this problem a while back, and research to date suggests that it's not easily (or feasibly) done. The code only needs to link against a single header that defines the plugin
API and is built from a fairly basic Makefile (currently with small variations per platform).
You should have a look at crosscompiling.
You basically build a compiler that (on your current plattform) will output binaries for your desired platforms.
Try this link about doing it on linux, for windows, with QT
Better late than never, I just came across IMCROSS
It looks quite promising!
For Linux it is fairly easy to setup or even download a virtual machine using VMWare for instance. Getting OSX to run on VMWare is somewhat tricky but possible.
Running VMWare and sharing a directory on a local drive you can even compile for the different platforms using the same exact files.
There is somewhere a cross-compiler for OSX but I wouldn't trust it to be of great quality.