HDTenEightyP/NetNews huggingface dataset:
From: emmerik@utrcu1.civ.utwente.nl (Emmerik P.J.L. van)
Newsgroups: comp.unix.programmer
Subject: Anyone with experience porting from UNIX/X11 to MSDOS??
Date: 8 Nov 92 18:36:28 GMT
Organization: University of Twente

Anyone out there with experience in porting UNIX/X11 applications to
MSDOS?

We are investigating the possibility of porting a rather big UNIX/X11
application (about 25 Mb source) written in FORTRAN and C to MSDOS.
The reason we want to port to MSDOS is that a lot of people have a PC
that is adequate for our application, but the do not want to leave
MSDOS becouse of existing applications, or they do not want to learn
a new OS like for example UNIX.

What dit you do about the following problems:
- Limited file name lengths
  The development will continue on UNIX, so for sources i would not mind
  to convert file names automatically.
- Memory - UNIX has an "unlimited" virtual memory space for every proces
  Are there compilers or other methods to have an "unlimited" address
  space under MSDOS (or maybe Windows NT) ?
- Can linkers under MSDOS handle long routine names
  Our routines are unique within 9 characters.
- Can you combine C and FORTRAN code the same way you do under UNIX
  i.e. trailing underscore and extra parameters for stringlenths for
  FORTRAN routines
  Note: we could prevent the problem of combinig C and FORTRAN by converting
  our FORTRAN code to C using F2C.
- What dit you do about graphics, we currently use X11

Other things I would like to know are:
- What compilers and utilities dit you use
- Where can they be obtained (reps in The Netherlands or elsewhere in Europe)
_ What was the approximate cost

Are there any problems i dit not mention that i should think of?

Please E-mail to emmerik@utwente.nl

-- 
Pieter van Emmerik                    | Phone:  +31-74-464231
HDS info management                   | FAX:    +31-74-464110
P.O.box 23                            | E-mail: emmerik@utwente.nl
7550 AA  Hengelo, The Netherlands     |         hp4nl!utrcu1!emmerik
Xref: sparky comp.unix.programmer:5280 comp.sys.sun.wanted:1793 comp.software-eng:4283 misc.wanted:9691
From: kroczak@knoblake.sybase.com (Barbara Kroczak)
Newsgroups: comp.unix.programmer,comp.sys.sun.wanted,comp.software-eng,misc.wanted
Subject: Re: Tools to automate testing.
Date: 12 Nov 92 03:21:20 GMT

X-runner by Mercury is a good tool for testing bit screen output.
From: jxv3790@hertz.njit.edu (Jake Vogelaar)
Newsgroups: comp.unix.programmer
Subject: Problems redirecting a child's output
Date: 6 Nov 92 23:35:05 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

I have to implement a simple shell for one of my classes, I copied the 
following piece of code from a textbook to do redirection.  Problem is,
it doesn't work.  Two things go wrong.  One: "outfile" stays a file of
lenght zero after the redirect, Two: after one redirect everything is
redirected.  The redirect input does not work either. Can anybody help ??  

//JV

-------------------------------------------
  if ((frk=fork())==0) {
   /*********** CHILD ***********/
   if (/* redirect output */) {
    if ((fd=creat(outfile))==-1) {
     fprintf(stderr,"Error: cannot open %s\n",outfile);
     exit(1);
    }
    close(stdout);  dup(fd);  close(fd);
   }
   if (/* redirect input */) {
    if ((fd=open(infile,O_RDONLY))==-1) {
     fprintf(stderr,"Error: cannot open %s\n",infile);
     exit(1);
    }
    close(stdin); dup(fd); close(fd);
   }
   execlp(cmd,cmd,NULL);
   exit(1);
  }
  parent ...
---------------------------------------
-- 
/////////////////////////////////////////////////////////////////////////
Jake Vogelaar
Computer Vision Research 
Warner-Lambert Manufacturing Development Laboratory
Newsgroups: comp.unix.programmer
From: raistlin@wixer.cactus.org (Eli Boaz)
Subject: fork() -- newbie's questions
Keywords: unix,c,fork,question
Organization: Real/Time Communications
Date: Wed, 11 Nov 92 16:47:34 GMT

What exactly is fork() used for?  And how do you use it properly?

Any info would be greatly appreciated.  Please email.  If you want
info on fork() then email too.  If there's enough interest I'll
summarize, otherwise just email the few that want it ...

Thanks in advance,

-- 
ttyl,     | "My friends, no matter how rough the road maybe, we can and we  |
Eli Boaz  +---------------\ will, never, never surrender to what is right." |
raistlin@wixer.cactus.org  \ -- Former VP Dan Quayle to Christian Coalition |
wixer!raistlin@cs.utexas.edu\-----------------------------------------------+
From: nigeld@natinst.com (Nigel Dsouza)
Newsgroups: comp.unix.programmer
Subject: Standard Method of Handling/Detecting Out of Virtual Memory condition
Date: 9 Nov 1992 13:36:50 -0600
Organization: National Instruments, Austin, TX
NNTP-Posting-Host: eagle.natinst.com
Keywords: virtual memory, stack growth


System: SunOS 4.x

Is there a system call to report on the amount of free Virtual memory?
	
Is there a method to reserve a specific amount of virtual memory for a 
particular process? i.e. guarantee that a process can use a certain amount of
memory without having to worry about running into an out of virtual memory
problem.

I am not worried about dynamic memory (i.e. memory from malloc et all) because
I can allocate that in advance to guarantee that memory; it is the memory 
needed for the automatic growth of the stack that is a problem.  Specifically,
the condition I would like to avoid is that the my process needs to grow its
stack, but cannot because it cannot get another page because the system is out of virtual memory.  I would like to be able to set the "soft" limit, using
setrlimit to (X - EmergencyStackSpace), where X is the amount of stack space
I would like to be guaranteed.  
	
I would appreciate any pointers to methods of handling out of virtual memory
conditions.

Nigel D'Souza
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.programmer
Subject: Re: Named pipes and mknod...
Date: 6 Nov 1992 17:12:06 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com
Keywords: named pipe mknod FIFO

In article <haley.720956802@husc11> haley@husc11.harvard.edu (Elizabeth Haley) writes:
>The man pages suggest how exactly one uses it to make that damned dir
>entry, which tells me nothing of the mechanism for connecting a driver
>to it...

Just open it.  If two processes open a named pipe (aka a FIFO), anything
one writes will be read by the other.  If you want the driver to be a data
sink, it should opening it for reading; if it's a data source it should
open it for writing.  Clients should use the opposite mode; named pipes are
one-way channels.

For more details about using FIFOs, see section 14.5 of "Advanced
Programming in the UNIX Environment", by W. Richard Stevens (if you thought
his "Unix Network Programming" was good, you'll love this).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: kudva@ecn.purdue.edu (Gautham K. Kudva)
Newsgroups: comp.unix.programmer
Subject: SUMMARY: Signal Handlers and malloc()
Date: 13 Nov 92 04:13:18 GMT
Followup-To: comp.unix.programmer
Organization: Purdue University Engineering Computer Network

Hi,
	A few days ago I had posted in this group requesting some
help with signal handlers. My problem was that I was calling malloc
from within a signal handler, and when the signal handler was invoked
while control was within a malloc call, the function had to be re-entered.
Since malloc is not designed to be re-entrant, this trashed the program.
I asked if there were any re-entrant versions of routines like malloc() or
routines that guarded the calls by blocking signals.  Thanks to the following
people for their help:

Rob Sartin
Mitchell Perilstein
Russell Spence
Rob Quinn
Christoph Badura
Steve McPolin
Mark Lawrence

	Everyone who responded to my post informed me that I should
not attempt such stuff from within signal handlers. The suggestion was
that I should restructure my code so that signal handlers would just set
some flags, and the application loop should do work based on these flags. 

	Unfortunately, this is not possible for my program, since what
I was really trying to achieve using signals was a crude form of threads.
I am trying to write a distributed application on a workstation network. 
My program has a computation thread (which will include third party
code such as Linear Programming solvers) and a communication thread
to enable a number of these programs to talk over a network. The 
communication thread acts not only as an interface to the particular 
program, but also as a routing point for messages between other processes.
So it is imperative that the communication thread be invoked at regular
intervals. I cannot depend on the computation thread to co-operate, since
it includes third party code that won't necessarily yield control to the 
communication thread periodically. 

Something like pthreads or cthreads would have been ideal for my 
situation. However I haven't been able to find a single package that will run 
on a mix of Sun SPARCs, HP-7000s and RS-6000s. I thought I might be
able to get the same effect using singals but guess not! For the time being 
I have decided to restrict myself to LWP on Suns and hope that pthreads
will be available on all platforms sometime in the future (with Solaris on
Suns and OSF/1 on HPs and IBMs)

Once again thanks to everyone who responded
Gautham
kudva@ecn.purdue.edu
From: mauriti@cs.tu-berlin.de (Frank Hartlep)
Newsgroups: comp.unix.programmer
Subject: Easy multiplexing with sockets
Date: 9 Nov 1992 14:24:05 GMT
Organization: Technical University of Berlin, Germany
Distribution: world
NNTP-Posting-Host: athene.cs.tu-berlin.de

I'm not very familiar with the socket interface and would like
to know if the following can be done without many problems:
Theres a server process with a socket and a variable number of
client processes, each with its own socket. The access to the
server is via Sun's RPC mechanism; the only purpose of the sockets
mentioned above is to get a notify message to the clients when
there's some important state change in the server (this message
then triggers a RPC to the server on the client side). Now, the
idea is to let the server write the messages to the notify socket
without knowing who's going to receive the message; the client
sockets should be connected to the notify socket without the server
being aware of it (he doesn't care who's connected). Additionaly,
the message, which is only sent once to the notify socket, should
be automagically multiplexed to each of the connected client sockets.
I hope that describes more or less clearly what I mean. I'm not very
confident this can be done, but perhaps somebody has an idea and could
give me a hint.

Thanks,
Frank


Newsgroups: comp.unix.programmer
From: rstevens@noao.edu (W. Richard Stevens)
Subject: Re: TCP, UDP protocols vs. Unix domain protocols
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Fri, 6 Nov 1992 16:44:45 GMT

>When a process communicates with another process on the same host using TCP
>(or UDP), are packets actually put on the network, which then come right back
>to the host?  Or is the communication handled by the kernel (as with the Unix
>domain protocols)?

Glancing through the current BSD sources the data goes through TCP (or UDP)
then through IP before it's detected that it's really for the local host.
Then the packet makes its way back up through IP and TCP.

There are two ways to send it to the local host: to the special IP address
configured for the loopback interface (normally 127.0.0.1) in which case
IP just sends it to that driver.  The loopback driver output routine just
puts the packet onto IP's input queue.  The other way is to send it to
your actual IP address.  In this case it looks like the packet makes it
into the ARP code [arpresolve()] where it's detected that the packet is for
the local host.  There's a flag here "useloopback" that default's to 1.
If this flag is true, the packet is just sent to the loopback driver
(same as for 127.0.0.1).  If the flag is false, however, the packet is
actually put onto the wire.  The comment in the code says that some
boards can't receive packets that they send, which is why it defaults
to 1.  But, someone at Xerox told me last week that this is really
false, and if the board can't receive its own transmissions then either
the board or the driver is broken.  (I don't know how true this is.)
If your kernel defines the variable "useloopback" check what its value
is, and try setting it to 0 and see what happens :-)

So the bottom line is that using TCP causes the packet to go through
TCP and IP, whereas a Unix domain stream socket avoids this.  As to
how much you save by using the Unix domain socket, I've never measured
this.

Realize that other implementations may do things completely differently.

	Rich Stevens  (rstevens@noao.edu)
Newsgroups: comp.unix.programmer
From: kudva@ecn.purdue.edu (Gautham K. Kudva)
Subject: Signal Handlers and malloc()
Followup-To: comp.unix.programmer
Organization: Purdue University Engineering Computer Network
Date: Mon, 9 Nov 1992 06:49:10 GMT


Hi netters,
     I've come across a problem with signal handlers that has me completely
stumped. I'm hoping that someone will be able to help me on this. The
environment I'm using is SunOS 4.1 on a Sparc IPC, but I expect that this
would be a problem on any Unix platform.

     I've written a signal handler for the VTALRM signal. The signal
handler calls another routine which does quite a bit of work. This program
start crashing in an unpredictable fashion. On using purify, it gave me the
following error (that software is simply awesome!!):

Warning: calling malloc(16) while in a call
 to malloc/free/memalign.  Probably from a signal handler.
 malloc/free/memalign are *not* reentrant and this may
 cause a later segv.

I have some malloc calls within the routine called by the signal handler,
and apparently the signal handler was invoked by interrupting a malloc
call.  Did some reading and sure enough, Rich Stevens' excellent book
"Advanced programming in the UNIX environment" warns of exactly this
problem. Now my question is - "Is there a fix?". I could coneivably guard
all my malloc/free calls with sigblocks... but I'm writing something that
will be used by other people. There's no way I can be sure that everyone
else will also guard their malloc/free calls. Besides, there may be other
routines that are non-reentrant in this fashion. I guess what I'm looking
for is a library of reentrant or guarded versions of the standard
non-reentrant calls. With the diverse uses to which signals have been put
over the years, surely something like this exists? Public domain versions
would be great, but commercial ones are ok too.

Please post or e-mail. I will summarize.

Thanks much in advance,
Gautham Kudva
kudva@ecn.purdue.edu
Newsgroups: comp.unix.programmer,comp.sys.sun.misc
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Re: setuid programs and calls...
Followup-To: comp.unix.programmer
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Sat, 7 Nov 1992 15:15:11 GMT

Barry Margolin writes:
>dynamic linker in setuid processes, which are defined to be processes whose
>real and effective uids are not equal.  This is done to prevent users from

I have just a minor question, but how does a Sun executable program
find out its effective uid?  Whenever I trace a program I see that it
make makes a call to getuid but not geteuid.  I have always wondered
about this.

Brian

fitzgb@mml0.meche //tmpfs (253) cat > a.c
main(){;}

fitzgb@mml0.meche //tmpfs (254) cc a.c

fitzgb@mml0.meche //tmpfs (255) trace ./a.out
open ("/usr/lib/ld.so", 0, 021044) = 3
read (3, "".., 32) = 32
mmap (0, 139264, 0x5, 0x80000002, 3, 0) = 0xdddc000
mmap (0xddfc000, 8192, 0x7, 0x80000012, 3, 16384) = 0xddfc000
munmap (0xdde0000, 114688) = 0
open ("/dev/zero", 0, 021152) = 4
getrlimit (3, 0xdfff97c) = 0
mmap (0xde00000, 8192, 0x3, 0x80000012, 4, 0) = 0xde00000
close (3) = 0
getuid () = 15636
getgid () = 4000
open ("/etc/ld.so.cache", 0, 01570000130) = 3
fstat (3, 0xdfff8f0) = 0
mmap (0, 8192, 0x1, 0x80000001, 3, 0) = 0xddf8000
close (3) = 0
open ("/usr/lib/libc.so.0.15", 0, 01567347240) = 3
read (3, "".., 32) = 32
mmap (0, 409600, 0x5, 0x80000002, 3, 0) = 0xdd76000
mmap (0xddd6000, 16384, 0x7, 0x80000012, 3, 385024) = 0xddd6000
close (3) = 0
close (4) = 0
close (0) = 0
close (1) = 0
close (2) = 0
exit (1) = ?

Newsgroups: comp.unix.programmer
From: bad@flatlin.ka.sub.org (Christoph Badura)
Subject: Re: Signal Handlers and malloc()
Organization: Guru Systems/Funware Department
Date: Tue, 10 Nov 1992 19:05:51 GMT

In <1992Nov9.064910.778@noose.ecn.purdue.edu> kudva@ecn.purdue.edu (Gautham K. Kudva) writes:

>     I've written a signal handler for the VTALRM signal. The signal
>handler calls another routine which does quite a bit of work. This program
>start crashing in an unpredictable fashion.

You should rewrite your program so that it only sets a flag variable
in the signal handler and do the "quite a bit of work" out side the
signal handler in the main part of the program.

This is the only way to make the program work reliably.

-- 
				Christoph Badura  ---  bad@flatlin.ka.sub.org

AIX is a better... is a better...  is a better... OpenSystem.
					IBM Rep at GUUG Symposium '92
Newsgroups: comp.unix.programmer
From: pete@arl.wustl.edu (Peter Flugstad,,,)
Subject: Re: SO_REUSEADDR (was: Re: Socket Programm
Reply-To: pete@arl.wustl.edu
Organization: Applied Research Lab, Washington University in St. Louis
Date: Mon, 9 Nov 1992 16:13:26 GMT

In article 101017@bu.edu, tasos@cs.bu.edu (Anastasios Kotsikonas) writes:
>In article <1992Nov7.023043.19007@wuecl.wustl.edu> pete@arl.wustl.edu writes:
   [.. my comment saying SO_REUSEADDR doesn't work as advertised...]
>
>I am sorry but this is nonsense. I have used SO_REUSEADDR on BSD 4.1.1, AIX
>3.1.5 and up, HP UX 8.05 and up, SGI OS 4.0 and up and pure SVR4 systems,
>quite successfully I might add, for both privileged and non-privileged
>ports.
>
>Tasos

hmmm, I think some more detail is needed...  I'm not saying your wrong
(please, no flames :-),  just that I've got conflicting stories...

First, some context... I'm using SunOS 4.1.1, and I believe most of the poeple I 
refer to are using BSD based (SunOS) UNIX as well.

(My appologies if reference someone and I don't give a name,  I didn't keep 
most of the messages).

Someone had posted a message to comp.unix.internals saying that they were 
having problems binding to a port twice in quick succession.   They had started 
their program, killed it, then restarted it quickly again, attempting to bind to 
the same local port both times.  They were getting an error back from the bind 
system call stating "Address in use".   

Someone else posted a message suggesting they try using SO_REUSEADDR.  

I then posted a message saying that it has been my experience that this flag doesn't 
work quite as advertised.  On occassion I have killed (ctrl-c) a running program that 
had a TCP socket open.  Because my program catches ctrl-c and generally cleans up 
after itself, explicitly closing open sockets and such, I assummed that re-starting it 
immediatley would be no problem, and USUALLY THIS IS THE CASE.  But, I have 
found that if there were outstanding messages in the TCP queue, then the socket would 
be stuck in TIME_WAIT for 60 seconds, and so I'd get EADDRINUSE.  This occurred 
despite my setting SO_REUSEADD, and SO_DONTLINGER (yes, I know it's going away).

Then, Chris Torek posted a followup to my message, examining some of the code that 
implements this.  Here's his message:

------ BEGIN included message ------

From torek@horse.ee.lbl.gov (Chris Torek)
From: karl@dixie.com (Karl Klingman)
Subject: Re: Socket Programming Help
Date: Thu, 05 Nov 92 14:20:45 GMT
Organization: Dixie Communications Public Access.  The Mouth of the South.

scstech@solomon.technet.sg (Kenneth Soh) writes:


>I guess the problem is in the use of accept() but I don't
>understand want actually went wrong. Below is my "program":

>------------------------------------------------------
/* OK here you go */
/* I changed your reference to sin to srvaddr for clarity */

struct sockaddr_in srvaddr, cliaddr;

>universal_socket = socket( AF_INET, SOCK_STREAM, 0 );

>srvaddr.sin_family = AF_INET;
>srvaddr.sin_addr.s_addr = htonl(INADDR_ANY);  <- NOTE htonl
>srvaddr.sin_port = htons(atoi(argv[1])); <--  NOTE htons
/* note cast below */
>bind( universal_socket,(struct sockaddr *) &srvaddr, sizeof( srvaddr ) )

>listen( universal_socket, 3 ); <- NOTE: normally one would use 5 (max)

for (;;) {
	/*	>client_socket = accept( universal_socket, 0, 0 ); <- nope */
	clilen = sizeof(cliaddr);   <- you'll need this below 
	/* notice that the 2nd and 3rd arguments must be an addresses */
	client_socket = accept(universal_socket, (struct sockaddr *) &cli_addr, 
					&clilen);
	/* check to see if client_socket is valid */
	/* fork */
	/* check for successful fork */
	if (childpid == 0) {    /* child process */
		close(universal_socket);
		/* do your stuff here */
		close(client_socket);  /* optional since exit will do it */
		exit(0);
	} else {    /* parent */
		close(client_socket);
	}
} /* for */
>------------------------------------------------------

I hope this helps.
-- 
He who would trade his liberty for  |  Karl Klingman
short-term security deserves        |  American Research Group, Inc.
neither...   Ben Franklin           |  emory!slammer!arg!karl
Newsgroups: comp.unix.programmer
From: bjornmu@idt.unit.no (Bj|rn P. Munch)
Subject: Re: How to Detect being fingered on NFS?
Organization: Div. of CS & Telematics, Norwegian Institute of Technology
Date: Fri, 6 Nov 92 15:51:35 GMT

In article <1dc747INNdcu@agate.berkeley.edu>, achoi@soda.berkeley.edu (Andrew Choi) writes:
|> OK, this is not yet another "used a named pipe for your .plan"
|> article, so, please don't jump into conclusion immediately.
|> 
|> Here's the problem.  I can be fingered at one of the serveral
|> machines, i.e. "apple", "orange", "grape" ... etc. for the sake
|> of argument.  Note that everything under my home directory is
|> NFS-mounted (this includes my .plan).
|> 
|> If I have a process running on "apple" writing to my named pipe,
|> it will detect if someone fingers me on "apple".  However, if
|> someone fingers "orange", it will just hang forever because
|> NFS does not really recognize named pipe and so the write from
|> process at "apple" does not respond to a read from "orange".
|> 
|> There are several solutions to this problem:

The solution I use:

My .plan is a softlink to a file under /tmp.  This file will exist on
"my" machine as the famous named pipe, but not on others, since /tmp
is local to each machine.

In case people finger me at another machine, they will see "No Plan.",
but my .project tells them to try another place...

Make sure your file under /tmp is not deleted by periodic cleanups, or
try some other place guaranteed to be "local".

Good luck!

---
Bj|rn P. Munch               | Dept. of Comp. Science & Telematics,
Bjoern.P.Munch@idt.unit.no   | Norwegian Institute of Technology (NTH),
PhD Student                  | N-7034 Trondheim, Norway
Univeristy of Trondheim      | Fingerable addr:  bjornmu@multe.idt.unit.no
Newsgroups: comp.unix.programmer