FAQ

for

Project 2 -- fork, exec, and wait

Q. As I started on my proj2 assignment i realizad that my home PC c compiler from windows dev. studio visual c++ would not eat fork, exec and all other commands from unistd.h header file, i downloaded this .h file from the wed, but then this unistd.h required some other .h file:

error code:
c:\program files\microsoft visual studio\vc98\include\sys\cdefs.h(67) :
fatal error C1083: Cannot open include file: 'sys/cdefs_aout.h': No such
file or directory
.stop. 

I couldnot get the mentioned .h from the web. ? Is there any other way to make my home PC compile those kind of commands such as fork, exec and wait...?

A. Please note that fork, exec, and wait are not C functions, but POSIX system calls. This means that they will not work on non-POSIX systems. As mentioned in a FAQ for the last assignment, most Windows operating systems are not POSIX compliant. (In particular, Windows 95, 98, and Me are not POSIX compliant. Windows NT is supposed to have a POSIX subsystem but I have never tried it, so I can't vouch for it. Similarly, Windows 2000 -- which is NT4 -- should have POSIX subsystem but I haven't tried it either.)

What I would recommend, rather than trying to get a Windows 9x O/S to pretend that it is a POSIX system, is to simply use the UNIX or LINUX machines available on campus, either remotely or directly.


Q. tried to run gimp from home:

bash-2.03$ gimp

Gtk-WARNING **: cannot open display: 
bash-2.03$ 
.stop.

same thing with xv. ?why is that and what do I do with it?

A. Unlike the programs that you have been running previously, which simply used standard in, out, and error to pass around ASCII values that your telnet-like ssh program (running on Windows or Mac) could handle itself, gimp and xv are creating their own windows, for which they need lower-level graphic support. On the UNIX machines in the lab, this support is coming from the X Window server. (Note that UNIX machines had windows before Microsoft had windows.)

You need two things to run gimp and xv remotely from your home machine that runs Windows or Mac:

  1. X Window capabilities. These can come from products like XWin32 (for Windows) or MacX (for Mac OS). I believe that there are free versions of these packages available, often on a trial basis or with some features disabled compared to the versions you have to buy. (E.g., A few years back I tried out a free version of XWin32 that required you to reconnect every hour.)
  2. A high speed connection. While this is not entirely necessary, you will find that running a windowing process remotely has a high communication overhead and your program will run amazingly slowly over an ordinary modem. You may find a cable modem or DSL runs fast enough to make it worth your while to do this from home.


Q. I was just hoping you could help me w/ a simple question. When I was at IBM and wanted to display a GUI over a ssh session I could do some kind of EXPORT command that allowed the GUIs to open on my side of the connection. This would be very helpful for program 2.

A. To remotely run X Window-based programs over ssh when the machine on your end of the connection is a UNIX or LINUX machine running X is much simpler than the case for Windows or Mac users above. All you need to do is enable X forwarding. On most configurations, this should be as simple as using the "-X" flag when invoking ssh. For example, you could type:

% ssh -X user5432@turing.cs.ou.edu
rather than
% ssh user5432@turing.cs.ou.edu

Of course, the speed of your connection will determine whether or not this is worthwhile to do.