Houdenbako Blog

No Forks For Cygwin?

Here's another technical post - I'll try to make it easy...

I got a copy of Cygwin. It's a program to emulate a Unix shell on a Windows machine. If you want to follow the textbooks on writing and compiling C programs, there are all sorts of difficulties you will encounter. Make files are usually included in an open source software package, and they encode several options for testing and building the C files. Make files are also written with Unix shell commands. So they're useless balls of command console errors if you want to run them in Windows. Somebody has to translate those files to make them compatible with a Windows environment.

Or you can do it all from a Unix emulator. That's Cygwin. I think.

There are some differences. If you want to 'port' code from one operating system to another, you've got a little work to do. And, utilities like Cygwin offer you some assistance. Well written libraries are also helpful. In many respects, the underlying philosophies of Unix and Windows are so different. I didn't think I would be using Windows as much in the future, so I'm not interested in investing a lot of time and energy in learning to compile code the Windows way.

It's one thing to write algorithms, but if you want your program to have input and output, you have to submit to how your particular operating system works. Or, you could borrow/buy/steal someone else's solution. I guess it depends on whether you intend to sell your finished product.

I keyed in a simple program to 'fork'. Programs written in Unix can do this, because 'fork' is a system call to create a new process identical to the original in every way except process id number. Program flow continues from the same point in the program on two copies in memory. It's like twins with the same DNA occupying different living bodies. Systems can economize on multiple copies of the same program - every copy can access one instance of the code and constants, but keep their own area for variables. That's not like twins.

System calls have to be written into the library. The compiler has to recognize that I can use a function called 'fork'. Otherwise it will complain. Unix has the code for 'fork' in a numbered index. The compiler needs to locate the listing by number, and the program has to be able to locate it while running. Each program I compile needs to include extra code to make that work. Windows doesn't have anything called 'fork', but somebody could write a fork routine that achieved the same thing with Windows system calls for process creation. Otherwise, I have to remove the fork calls from my program and insert the corresponding Windows system calls. And who knows what else might break when I do?

Ideally, any system-dependent code ought to be stashed away in a library. A library with the same name for the same functions on different systems. But C isn't always like that. Programmers on one system are not usually worried about portability. It's not really worth their time, just as they wouldn't worry about whether the comments were easy to translate into Swahili, or Nepalese.