On Unix to Windows Porting Dictionary for HPC page for fork() it's written
There is no equivalent Windows API to
the Unix fork() or vfork(). The
Microsoft Subsystem for Unix-based
Applications (SUA or Interix) is a
Unix environment that has fork() and
vfork() properly implemented.
and further on the page there's example source code which uses... standard Win32 API CreateProcess function.
I'm confused.
Shouldn't the example use fork() to illustrate the statement about fork() being implemented by SUA/Interix?
If fork() is really implemented which header and lib files does it live in?
The page you're looking at is the *nix to Windows porting guide. It doesn't show you how to use fork() but the closest win32 equivialent, CreateProcess. The pages there documents which Win32 function you should use instead of Unix functions.
You'll need the subsystem for Unix and the SUA SDK to use fork(). There you'll get a *nix environment on Windows, fork() will be in the usual unistd.h library, and you'll link to libc.so (using gcc) to use it.
Related
I'm porting a linux app on windows and I need dbus-daemon.exe running on my win session.
My app and dbus-daemon.exe work fine but the latter still opens a default console and, being not familiar with programming on windows, I don't know how to get rid of it.
Maybe by making it invisible ?
Windows, by default, opens a console window for executables compiled for the console subsystem (the "subsystem" being essentially a bit of metadata in the Portable Executable format, aka EXE/DLL). So you have at least two options:
Compile the dbus-daemon for the Windows subsystem, if you're the one doing the compilation. It is a linker option.
Launch the dbus-daemon process passing the CREATE_NO_WINDOW flag to the relevant API function (probably CreateProcess). If you're not using the Windows API directly, look how CreateProcess and CREATE_NO_WINDOW are exposed in the API you are using. In .NET, for example, it's the ProcessStartInfo.CreateNoWindow property.
Is it possible to convert a DOS Application to a Win32 Console Application? I have an old program I wrote a long time ago, lost the source to it and asked myself now if it's possible to convert the DOS Binary to an actual Windows Binary, which runs in Command Line Prompt?
This is not possible. The DOS program will attempt to use DOS system calls that do not exist under Windows. The program will need to be updated and rebuilt for Windows. You might have some success running the original program in a DOS emulator.
See other answers about running a DOS program under Windows.
To convert a DOS program to a Win32 console application, one would have to convert the 16-bit (8086) code within the DOS program to 32-bit (i386) code. This is a very hard task to do right, and probably that's why there is no converter readily available. (Alternatively, an emulator can run 16-bit code without conversion, see the other answers and comments.)
However, not all DOS programs contain 16-bit code, for example programs using DOS extenders built with the Watcom C/C++ compiler (or, equivalently, with OpenWatcom: owcc -bdos4g prog.c) contain only 32-bit code. Windows can run 32-bit code directly, but API calls (e.g. opening and reading a file, allocating memory, getting the current time, writing colorful text to the console) have to be converted from the DOS+DPMI API to the Win32 API. Such a conversion is technically possible and feasible (even on the final .exe file, without access to the source code), and it is much easier to do correctly than the conversion of 16-bit code to 32-bit code. However, I still don't know of a converter readily available.
Please also note that conversion graphics and audio code to the Win32 API is very hard, but that's out of scope in this question.
I have a few things like running SFC, defrag, and reset the page file and so on, things that can be done within windows VBScript, I am just wondering if I can compile that code as a resource and call it as needed. Thanks.
Lee
You can use the Windows Script Host interfaces, IActiveScript and IActiveScriptParse, to execute Javascript/VBScript from memory. You can then compile your Javascript/VBScript into a resource, extract it at runtime, and then execute it when needed.
Update: have a look at this blog article:
Adding Active Scripting to your
Delphi Win32 application
And then look at this discussion to make it work in 64bit:
Writing a scripting host in Delphi XE2 64-bit
Lately I was experimenting on my old VB6, and found there a strange thing.
Using ProcMon I found that while compiling, VB6 runs Link.exe with parameters like this:
LINK "D:\Folder\Form1.OBJ" "D:\Folder\Project1.OBJ"... /SUBSYSTEM:WINDOWS,4.0 ...
I wrote Link.exe /? in cmd and found there
link.exe /?
usage: LINK [options] [files] [#commandfile]
options:
...
/SUBSYSTEM:{NATIVE|WINDOWS|CONSOLE|WINDOWSCE|POSIX}
By default VB6 compiles with parameter /SUBSYSTEM:WINDOWS.
But can I compile my VB6 code to Native or POSIX subsystem application?
This just sets a bit in the resultung exe file. Visual Basic uses Microsoft's standard linker which is also used for C/C++, that's why the flag is there.
So yes, you can compile it with those settings, but I'm certain that the resulting exe won't run in native mode or in the Posix subsystem.
For more information on those settings you might want to check out information about the PE file format and have a look at the DUMPBIN and EDITBIN tools.
VB applications uses Win32 calls, so there is no chance your application will work, even if you uses a console-only application.
Console is the only alternative subsystem that is useful. Posix isn't even present since Win2K and Native is for kernel mode drivers.
If any of this is news to you, I wonder why you are playing with ProcMon? Scary.
I am from Unix programming background and am facing a unique behavior/problem during porting my system from Unix to Windows.
[I am pretty new to development on windows, so the below question may look too obvious.]
I am porting using mingw and the problem in question is regarding "system()" call provided in Unix and the WEXITSTATUS option.
Question
In Unix, to execute any commands/scripts we have code that uses system() call. The same compiles in mingw - but I want to know if there are any change in behavior between the Unix and Windows version of system() call.
The windows version of system() call is provided in stdlib of mingw, but am not able to get the exact behavior.
My second question is regarding WEXITSTATUS. Generally, In Unix this is used along with system() command to get the status of the command executed.
a. Can the same be done with system() of stdlib of mingw?
b. How to achieve it?
Note :
I have read about createProcess and its subsequent usage in the net - But my idea is to continue with existing code (use system() call itself) and find an alternative to WEIXTSTATUS.
Thanks for your help/suggestion in advance.
Look here for Win32 documentation on system: http://msdn.microsoft.com/en-us/library/277bwbdz%28v=VS.100%29.aspx
Note that the system call is subject to the command interpreter on the system, and cmd.exe (Windows command interpreter) works differently than Unix Bash.