I have C program which I wrote in Linux that runs very well. Now I want to run it on Windows.
How do I easily run it on Windows?
Elaborating a bit on the answers from caf and jartieda...
Cygwin is an attempt to emulate a (nearly) complete POSIX execution environment in a native Windows process. It is complete enough that a surprising amount of Unix application code simply compiles and runs using the familiar ./configure && make && make install idiom. This trick was done by supplying a DLL that emulates POSIX system calls using the Windows API. Based on that, you get a complete GCC toolchain, bash, and all the usual command line utilities you are used to. One downside is that the compiled program is dependent on the Cygwin DLL, which makes it tricky to deliver the result to a system that does not already have Cygwin installed and whose user doesn't want to use a Unix shell.
MinGW is a port of the GCC toolchain that generates native Windows applications that depend on the well known (and distributed with Windows itself) MSVCRT.DLL C runtime library. It makes no attempt to emulate a POSIX operating system, but applications that are mostly based on the standard C libraries, will often build essentially unchanged.
MSYS is a compile-time environment that provides enough Unix utilities (including bash) to often allow ./configure to run, and if the project supports the results, finish the build with MinGW's GCC. The result is a native Windows executable that does not depend on any DLLs you don't deliberately use aside from MSVCRT.DLL. Although the MSYS environment itself was a fork of an early version of the Cygwin project, it is primarily intended to be used to provide a unix-like place to compile native Windows applications: one would generally not build new applications based on its runtime environment.
Another approach to compiling for Windows is to use the MinGW cross compiler on linux. A number of MinGW's core developers work that way, testing they product either under Wine, or under Windows running in a VM or a separate PC.
If the program has a GUI component, then you may have additional difficulties. Some GUI frameworks are available for both Linux and Windows. Qt, wxWidgets, and IUP all leap to mind, but there are others out there.
Edit: I've improved the paragraph above about MSYS to emphasize that it is intended to be a compile-time environment for building programs that run as native Windows applications, and not a full POSIX environment like Cygwin.
Note, also, that there is always the option of porting the project to one of the more traditional compilers for Windows development. Open Watcom, the Borland compilers, and Microsoft all have free or inexpensive versions, although often enough not under licenses that make the opens source community entirely happy.
This approach probably requires more effort because the differences between a Linux environment and the Windows environment become more visible when you also switch from one toolchain to another. This is especially true of the Microsoft compilers which are historically not as fully standards compliant as GCC.
The easiest way is to install the Cygwin environment, and compile it under that.
best way recompile it all using mingw compiler.
easy way recompile it under cygwin environment.
The answers you got so far, focus on installing the GNU operating system on the Windows kernel; but you could also use freeware tools from Microsoft. This solution is probably most attractive if you want to continue to develop on Linux, and only do a little work for porting on Windows:
Microsoft offers a simplified version of their development environment as freeware: Visual Studio Express (download). If your program does only file IO it will probably compile unmodified, because Microsoft supplies the C standard library too.
For GUI I also wholeheartedly recommend the Qt framework. It is very well written and documented; it is now licensed under the LGPL, so you can link it to proprietary applications without any cost. However it is written in C++ so you would need to change the programing language. For integration of QT with Visual Studio Express: I believe it works, but you need to try it out. About five years ago I tested the integration of (proprietary) QT and (professional) Visual Studio for my employer, and it worked perfectly.
Related
I'm an avid Python user and it seems that I require MinGW to be installed on my Windows machine to compile some libraries. I'm a little confused about MinGW and GCC. Here's my question (from a real dummy point of view):
So Python is language which both interpreted and compiled. There are Linux and Windows implementations of Python which one simply installs and used the binary to a execute his code. They come bundled with a bunch of built-in libraries that you can use. It's the same with Ruby from what I've read.
Now, I've done a tiny bit a of C and I know that one has a to compile it. It has its built-in libraries which seem to be called header files which you can use. Now, back in the school day's, C, was writing code in a vi-like IDE called Turbo-C and then hitting F9 to compile it. That's pretty much where my C education ends.
What is MinGW and what is GCC? I've been mainly working on Windows systems and have even recently begun using Cygwin. Aren't they the same?
A simple explanation hitting these areas would be helpful.
(My apologies if this post sounds silly/stupid. I thought I'd ask here. Ignoring these core bits never made anyone a better programmer.)
Thanks everyone.
MinGW is a complete GCC toolchain (including half a dozen frontends, such as C, C++, Ada, Go, and whatnot) for the Windows platform which compiles for and links to the Windows OS component C Runtime Library in msvcrt.dll. Rather it tries to be minimal (hence the name).
This means, unlike Cygwin, MinGW does not attempt to offer a complete POSIX layer on top of Windows, but on the other hand it does not require you to link with a special compatibility library.
It therefore also does not have any GPL-license implications for the programs you write (notable exception: profiling libraries, but you will not normally distribute those so that does not matter).
The newer MinGW-w64 comes with a roughly 99% complete Windows API binding (excluding ATL and such) including x64 support and experimental ARM implementations. You may occasionally find some exotic constant undefined, but for what 99% of the people use 99% of the time, it just works perfectly well.
You can also use the bigger part of what's in POSIX, as long as it is implemented in some form under Windows. The one major POSIX thing that does not work with MinGW is fork, simply because there is no such thing under Windows (Cygwin goes through a lot of pain to implement it).
There are a few other minor things, but all in all, most things kind of work anyway.
So, in a very very simplified sentence: MinGW(-w64) is a "no-frills compiler thingie" that lets you write native binary executables for Windows, not only in C and C++, but also other languages.
To compile C program you need a C implementation for your specific computer.
C implementations consist, basically, of a compiler (its preprocesser and headers) and a library (the ready-made executable code).
On a computer with Windows installed, the library that contains most ready-made executable code is not compatible with gcc compiler ... so to use this compiler in Windows you need a different library: that's where MinGW enters. MinGW provides, among other things, the library(ies) needed for making a C implementation together with gcc.
The Windows library and MSVC together make a different implementation.
MinGW is a suite of development tools that contains GCC (among others), and GCC is a C compiler within that suite.
MinGW is an implementation of most of the GNU building utilities, like gcc and make on windows, while gcc is only the compiler. Cygwin is a lot bigger and sophisticated package, wich installs a lot more than MinGW.
The only reason for existence of MinGW is to provide linux-like environment for developers not capable of using native windows tools. It is inferior in almost every respect to Microsoft tooolchains on Win32/Win64 platforms, BUT it provides environment where linux developer does not have to learn anything new AND he/she can compile linux code almost without modifications. It is a questionable approach , but many people find that convenience more important than other aspects of the development .
It has nothing to do with C or C++ as was indicated in earlier answers, it has everything to do with the environment developer wants. Argument about GNU toolchains on windows and its nessessety, is just that - an argument
GCC - unix/linux compiler,
MinGW - approximation of GCC on Windows environment,
Microsoft compiler and Intel compiler - more of the same as names suggest(both produce much , much better programs on Windows then MinGW, btw)
i want to write code use notepad and compile the c code use cmd on windows (like java),
what software should i use ,
gcc for windows
cygwin
Turbo C
gvim
thanks
An excellent option for Windows is the Visual C++ Express Edition (which is free). This is a full IDE, compiler, and debugger and is a great way to get started.
GCC is also a good option if for some reason you wish to avoid an IDE. I wouldn't recommend this for a beginner, though.
Please don't use Turbo C, it's very old and you will have problems with it.
Cygwin is a popular linux environment for Windows.
Gvim is an editor and (in my opinion) has a very high learning curve. You could use Notepad++ or Code::Blocks to develop your code in.
mingw is also a good option to start with.
IMO you should avoid IDEs: a beginner needs to actually see and feel the whole process of compiling by invoking the compiler from a terminal, not by simply pressing some keys and bang! Also most of the IDEs have code completion facilities which is not good for beginners (especially for C). So I would go with vim (or gvim) and cygwin.
PS: Give Linux a try, you might actually like it; then vim and gcc.
Use cygwin. It's just about the only way to get a C environment on Windows that's both modern (i.e. not 16-bit, DOS-based) and conformant to the standards, and with it you get a fairly-complete POSIX environment, which allows you to actually do interesting things with C.
The classics would be Cygwin and MSYS/MinGW.
Cygwin provides a Linux API compatibility layer and includes a package manager which provides access to many well-known Linux applications (ie batteries included).
MSYS/MinGW only provides a minimal userland to get the GNU build system working.
Both come with their own shell environment, but can be used from Windows' command line as well.
Binaries created with Cygwin-gcc won't work without cygwin1.dll, but you get all the benefits of a mostly-POSIX environment. You can also use Cygwin's MinGW package for cross-compilation and thus create stand-alone binaries.
Other solutions are possible: Currently, I'm using the MinGW compiler together with the Cygwin userland from the Windows command line...
I think cygwin itself named as gcc for windows.
also gvim is not a compiler , It is a very nice and powerful tool for code editing.Also you can try emacs and kwrite
Some suggestions from my side:
In windows, you need to install a third party software to try all programming stuffs(c,c++ etc) ,Most of the times it is having GUI implementations and you didn't get any exact idea behind the code execution flow.also the command prompt of windows not at all efficient as linux shell.
But if you install a good linux distro (ubuntu/fedora/cent os/debian/pardus/suse/arch linux),all default compilers,debuggers and editors are installed within the OS and you can try the basic and all advanced programs by just opening the terminal(shell).Also the shell is a more powerful tool and you can enjoy all kind of automation comamnds(I mean scripting).
Also: for your added information, most of the embedded programmers in the industry prefer command line execution unlike GUI implementation because it is too fast than GUI.
So, I have a large C project that was built entirely on Unix (SPARC Solaris). me and several others have begun to revisit it because their was some interest in a windows build.
none of us have done this with a project of such size, so for starters, has anyone ported something from unix to windows and could maybe give me some pointers or how they did it.
our first step on our plan was to decide on a compiler/dev environment.
it seems that our options are MS Visual Studio, Cygwin, mingw/gcc, and Windows Services for UNIX (SFU).
we are on a fairly short timetable so we want to rewrite as little code as possible.
so, Deciding on a compiler.
Another issue is that the code does use POSIX thread commands (pthread, etc)
we would prefer to compile natively, not using some sort of layer between the executable and the OS. unfortunatly with the pthread calls in our code, this may not be possible.
I believe both Cygwin and SFU do just that. Cygwin has a .dll that must be included in compiled code to work. I am not sure about SFU, any information about that would be greatly appreciated. It seems like it would be a good option but was developed to allow for UNIX compiled software to run on a windows machine with SFU, not any old windows box.
mingw does have the ability to create native exes, but lacks the POSIX support.
So, can anyone give me any more information, suggestions, knowledge on any of these compilers in this context. or any experience they have with this sort of thing, it is greatly appreciated.
Short timetable? CygWin, plain and simple.
Despite your preference to not use a layer, that's going to provide the fastest path and you don't seem to indicate that the timeframe requirement is flexible.
We've ported both command-line and X-based UNIX programs to Windows using CygWin with minimal hassle.
Cygwin is likely the fastest path to a working executable. However it will leave you with some interesting distribution choices. Most obviously, cygwin.dll becomes a dependency. Its licensed GPL, unless you pay money to buy commercial use rights.
Cygwin is not particularly friendly to an ordinary Windows user. Its goal is to provide a full POSIX experience on Windows, supplying a shell, all the familiar *nix utilities, and even a port of X. However, it also remaps the Windows disk drive naming into a POSIX-like file system. I've never attempted to distribute an application built for Cygwin to machines that don't already have a full Cygwin installation. I will note that to my knowledge none of the big well-known open-source applications with Windows ports are based on Cygwin.
If the only hard POSIX dependency you have is pthreads, then that is solvable. There is a pthreads port built on native Windows threads that works well with MinGW. IIRC, it is even distributed along with MinGW, or at least is one of their core supported packages.
If the rest of your handling of file names is largely as opaque strings, you may not even need to care about changing / to \. The Windows API is generally happy to treat either character as a path separator, even mixed in the same name. It is the CMD.EXE and early DOS convention of using / for command line options that prevents the use of / for pathnames at the command prompt, not the underlying Windows API.
For tools that might make porting your build process easier, check out the MSYS component of MinGW. It provides a lightweigh fork from the Cygwin environment in which enough *nix utilities are available to generally run ./configure and similar processes.
In addition, the GnuWin32 project has ports of a large number of utilities and libraries that are all built to run as native Windows applications without unusual dependencies.
If the code is (at least mostly) portable and the only major issue is the use of pthreads, you might want to use the Pthreads Win32 library. While incomplete, it's sufficiently complete and accurate to deal with most pthreads code I've tried it with. While normally built as a DLL, this can also be built as a static library to avoid creating an extra dependencies in your executable.
That, of course, leaves everything else to port -- but you haven't said enough to even guess whether porting the rest within your timeframe is at all reasonable.
I would like to port a few applications that I use on Linux to Windows. In particular I have been working on wdiff. A program that compares the differences word by word of two files.
Currently I have been able to successfully compile the program on windows through Cygwin. However, I would like to run the program natively on Windows similar to the Project: UnixUtils.
How would I go about porting unix utilities on a windows environment?
My possible guess it to manually create the ./configure file so that I can create a proper makefile. Am I on the right track? Has anyone had experience porting GNU software to windows?
Update:
I've compiled it on Code::Blocks and I get two errors:
wdiff.c|226|error: `SIGPIPE'
undeclared (first use in this
function)
readpipe.c:71: undefined reference to `_pipe'
readpipe.c:74: undefined reference to `_fork
This is a linux signal that is not supported by windows... equvilancy?
wdiff.c|1198|error: `PRODUCT'
undeclared (first use in this
function)|
this is in the configure.in file... hardcode would probably be the fastest solution...
Outcome:
MSYS took care of the configure problems, however MinGW couldnt solve the posix issues. I attempt to utilize pthreads as recommended by mrjoltcola. However, after several hours I couldnt get it to compile nor link using the provided libraries. I think if this had worked it would have been the solution I was after.
Special mention to Michael Madsen for MSYS.
Yes. If you stick to the standard C library, and POSIX functions, most is available on Windows. You may just have to find the implementations. There are implementations of things that do not require Cywgin or MinGW (such as a pthreads package, etc.)
Also, there is a great book that is written in the style of W. Richard Steven's Advanced Proramming in the UNIX Environment, and the book is Windows System Programming, author Johnson Hart. He has a 4th edition. It focuses on System Programming, there is no GUI treatment whatsoever.
http://www.amazon.com/Windows-Programming-Addison-Wesley-Microsoft-Technology/dp/0321657748
It is the best book I know of for a UNIX programming moving to Windows.
You can have a look at MinGW (and MSYS), which are similar to cygwin, but gcc produce native Windows executables. However, since the Unix emulation is not as good as cygwin, you may have to adjust your code.
Always try to following standarts even when porting applications. POSIX compliant compilers exist on windows/Linux. You can try mingw. It has full toolchain required to build standart POSIX application (GNU Linux as well). Check out Dev-Cpp it eases the work.
MinGW is about the easiest way to get gcc and associated binary utilities (including gdb) on a Windows PC. It includes header files and import libraries so that you can call native Windows APIs. If you want more of an integrated IDE development environment you could download Microsoft's free Visual Studio Express C++.
Either way you'll likely have to convert some of the function calls to use Windows specific APIs (if you want a book I'd also recommend the Hart book mentioned in mrjoltcola's answer). For simple command line tools this conversion is usually not a huge deal, the big porting nightmares tend to involve tools with GUIs which have deep embedded dependencies on the GUI framework provided by the OS.
I am in a big problem ..i have compiled my c files using linux make file in Linux OS.
I want to compile the same files in Windows using the same make file by command prompt. For that i have nmake utility and Cygwin utility too.
I have done that successfully with simple programs with simple make file ..
But it is not possible to compile when i was using the complex C files with complex make file.
I have changed the '/' in linux make file to '\' in windows? Anyother changes?
I want to know 'Is there any special make file formats in windows?'
also the difference between them..
I am really in need of that...
Unfortunately, nmake was only loosly inspired by make, and they didn't get many important things right. By far the easiest thing to do is to start by having the same flavor of make on both platforms.
On linux, Gnu make is the default and best option.
On Windows, there are several sources for Gnu make, with some quirks to choose among. Personally, I mostly use the native win32 build of Gnu make from the GnuWin32 project. You might want to poke around at the rest of the project's packages because some of the others will be useful to have as well.
Alternative sources are Cygwin and MinGW32/MSYS.
Cygwin is a credible attempt at providing a *nix compatibility environment on top of the Windows kernel. It consists of a DLL that exports a huge percentage of *nix (especially POSIX) system calls implemented via the Windows API. That DLL also has its own idea about disk mounts and prefers *nix-style path names. The DLL itself is licensed GPL (although a commercial-use license is available for a fee), and programs built in the Cygwin environment require it by default, so that can be a factor to consider. Another factor is that Cygwin is not friendly to normal Windows users, so development projects based on it usually end up difficult for non-unix users to deal with. For a cross-platform developer, however, Cygwin can be really useful as it gets you all of the usual suspect utility programs required by your Makefile, and it includes the MinGW32 native Windows targeted GCC as well as a GCC targeting the Cygwin environment.
MinGW32 is a porting project that did a really good job of porting the GCC compilers to run as native Windows executables. If used along with the header files they supply, it is possible to use nearly all of the Windows API via a C runtime DLL that ships with modern Windows installations.
MSYS is a lightweight fork of Cygwin that contains a minimal set of utilities (starting with a *nix shell) that are usually assumed to exist by a typical *nix Makefile. Unlike Cygwin, MSYS is configured such that the default target is the native Windows API.
What I'm trying to hint at here, and probably should just state flat out, is that your compatibility issues don't end with the dialect of make you use.
The Makefile language itself is highly dependent on the command shell available, and most serious project Makefiles end up using many of the *nix the core utilities such as cp and rm.
I would strongly recommend starting with the GnuWin32 build of make, and also installing MinGW32 and MSYS. It is then relatively easy to write a Makefile that works under both MSYS and linux, and needs only a small amount of platform-specific logic.
You should consider CMake for cross-platform make but your real problem is you shouldn't have to change the '/' to '\'. If you run under cygwin or msys (recommended) this should be handled for you.
NMake is a windows tool and will parse only windows-style paths, i.e. paths with drive letters and backslashes. Therefore you should use GNU Make installed with cygwin.
nmake should read your makefiles okay, the differences are generally between versions of make rather than OSs.
The big question is what your target platform actually is, are you trying to make this code operate in Windows natively or are you looking to run it under Cygwin?
Use gnumake on both platforms. I do. I haven't touched Visual C in years.
nmake got it's own format rather than windows itself, so makefile format is related to make tool rather than os. For simple things format is similar for g(nu)make and nmake, as people suggested before consider using gmake only.