I'm studying computer engineering and we have a class called operating systems where they lecture us about how OSes handle stuff etc. This week we were given a homework which requests us to code a shell that works on Linux. The problem is, they tought us literally nothing on how to code a shell so we are supposed to do some research and figure it out.
I found this guide online and it seemed perfect to me: link
Code, with explanations, what else could I ask for.
Now, I'm using a Windows PC and I use Dev-C++ IDE with GCC compiler. Can I code a shell that works on Linux with my current setup or do I have to install Linux? Are there any major differences between how shells run on these OSes?
If you want to write a shell for Linux, you want to target GNU/Linux which is basically POSIX with some extensions.
Dev-C++ by default uses MinGW GCC as its compiler, providing a Win32 API.
Win32 and POSIX are completely and fundamentally different. A shell written for one will not even slightly resemble the other.
Instead, you have several options:
Dev-C++ can optionally use Cygwin GCC, providing a more GNU/Linux-like experience on Windows. You need to take great care not to rely on any Cygwin-specific functionality like how it automatically translates pathnames and line terminators. You'll still need access to a Linux install to verify that it works.
Windows 10 lets you install WSL, a more modern Linux compatibility layer for Windows. Dev-C++ doesn't explicitly states it support it, so you may need to edit and compile separately, and may lose debugging functionality. You'll still need access to a Linux install to verify that it works.
Just run Linux in a VM. The only thing to care about is getting your shell working.
I would suggest saving yourself a ton of trouble right now and just download/install an Ubuntu image in VirtualBox.
Related
I was just wondering, if there is a way, to compile my code, from my windows machine to other os, or do I have to setup everything for the compilation on VMs.
I have already changed up the code, so that it is possible to compile it on diffrent platforms, I'm just wondering if there is a way, to compile it for other operating systems in mingw, or in GNU. (If there is a way to do it in GNU, I'm fine with moving to linux, and compiling everything there)
This is exactly what is done when programming for Arduino, so yes it is possible.
But if you want to do it from Windows you may find it easier with LLVM/Clang than GCC, as it's not so easy to find cross compilers for many platforms that actually run on Windows.
It's a lot easier from Linux.
Or you can use CI tools like GitHub actions to build in the cloud.
I created an example project at https://github.com/brechtsanders/ci-test which uses GitHub actions (https://github.com/brechtsanders/ci-test/actions) to build on Ubuntu Linux, macOS and Windows.
You can use this project as the basis for a new cross-platform project.
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.
A CS course I'm taking online suggests students compile their source code and run tools like valgrind on the OS UNIX. I'm completely new to UNIX, Linux, their tools, and coding in c. I've made some attempts at installing FreeBSD 8.1 on VMWare Player 3.1.3, and even managed to get VMWare Tools running. But the FreeBSD documentation has led me down many dead-ends in accomplishing common tasks i.e. mounting an NFS or USB device. It turns out that the packages I need to make this happen aren't installed or configured, and I don't see any straight answer on how to install them.
So, if I'm using UNIX only as a tool to run gcc, g++, valgrind for this CS course, and these can be run on Linux instead, it seems like I can get the job done faster using Ubuntu Linux.
Can Linux be used to compile and run c code identically on UNIX, if compiled on Linux? Or if not, what are the differences to look for?
Thanks
For the novice-level C programmer such as OP, the difference of environment is negligible. Go ahead with Linux.
I think for purposes of the course you could run your programs and tools on Linux,
but I guess the reason your teacher wants you to use FreeBSD is so that you learn other things besides just coding up your problems
The two should be effectively the same. The only major difference you might see would be due to different versions being used. I would check to see what versions of gcc, g++ and valgrind the teacher is having you use, and make sure that you have the same version running on your install of Linux.
You can also use MinGW or Cygwin. You mentioned VMWare, so I'm guessing you're trying to just get an environment up and running in a windows environment. They both allow you to use the compiler and some of the tools without a full install of a Linux based system. In a CS course they would be more than enough.
The main differences too look for:
Compiling C / C++ is not machine independent. You need to have a small environment to compile on UNIX anyway if you need to submit compiled programs to your professor.
C / C++ is rather portable if you don't use anything that's non-portable. It's very hard to verify that you didn't use something that's different between the two machines, so you may wish to compile on UNIX to verify you didn't let an unavailable library (or an specific to the OS procedure, argument, behavior, bugs, etc.) slip into your code.
The vendor of make between the two machines may differ. This means that while the core of make will operate similarly, certain features might not be available in both. In reality, you probably won't use most of makes extended features, but in a worst case scenario you might opt to maintain multiple Makefiles or limit yourself to a common subset of features.
At the end of the day, it all boils down to what your professor will want. Odds are 95+% that you can do 100% of the work in Linux, but the prof's requirements or grading environment might be such that you will have to copy your code into a UNIX account to build the final "submission" executable. Considering that university UNIX accounts aren't nearly as portable as Linux on a laptop, the cost of the "final verification / porting" to the University computer is likely to be small compared to the convenience of working on your homework more hours than you can manage in a fixed lab.
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.