From: H.J. Lu (hlu@eecs.wsu.edu)
Date: 02/22/93


From: hlu@eecs.wsu.edu (H.J. Lu)
Subject: Re: Porting MH-6.8 to Linux....
Date: 22 Feb 1993 22:56:20 GMT

In article <CGD.93Feb22021247@gaia.CS.Berkeley.EDU>, cgd@gaia.CS.Berkeley.EDU (Chris G. Demetriou) writes:
|> In article <1993Feb21.203127.5000@serval.net.wsu.edu> hlu@eecs.wsu.edu (H.J. Lu) writes:
|> =>|>
|> =>|> 1) Has anyone done the said port, or alternatively, were
|> =>|> similar problems faced for other OS's and how they were ironed out.
|>
|> as a suggestion, take a look at the port of MH 6.8 to 386bsd.
|> it's available from agate.berkeley.edu:pub/386BSD/0.1-ports/somethingorother
|>
|> we had to solve the same problems.
|>

Thanks. I will take a look when I get time.

|> >MH-6.8 is unportable. You have to rewrite that part using stdio only.
|> >Not all systems have the same FILE. Take a look at HP-UX 8.0.x.
|>
|> agreed, but it can be solved with a few well-placed #define's, in most
|> places...
|>
|> writing it in straight stdio could slow MH down significantly...

Really?

|>
|> >No. MH-6.8 tries to skip stdio and talk to FILE directly. No way you can
|> >do that on all systems. That part of MH-6.8 is badly coded.
|>
|> to the latter, i say "bullshit," even though i was the first to get
|> an mh 6.7.* port completely working under 386bsd.
|>
|> "badly coded" implies without justification. There's sufficiently
|> good reasoning as to why that chunk of MH is coded that way -- read
|> the comments, and you'll find out...

I don't have the time.

|>
|> VJ might be a speed demon, but he's smart about it; he finds out
|> what needs to be optimized, then does it...
|>

Why not leave that to stdio? Not all stdio's are the same. At least give
an option like

#ifdef USE_STDIO

....

#else

...

#endif

|>
|> chris
|> who thinks the fact that MH uses the internals of FILE is ugly, too
|> --
|> Chris G. Demetriou cgd@cs.berkeley.edu
|>
|> MENTALLY CONTAMINATED and proud of it!

H.J.