RE: [line-devel] Hrm.

[Michael V. <mv...@qu...>]

Hi Michael,

These fixes you've been doing sound really useful.  If you sent them to me 
in small patches, I'll apply them to the LINE source tree as soon as I can.

Thanks!
Mike


>I've been looking at the following issues:
>
>1. Fixed an apparent bug in exec which meant command line parameters
>weren't being passed properly to exec'd processes.
>
>2. Modified exec to try adding a .exe extension to the filename so that
>Linux programs could call Windows programs (or the Cygwin equivalents of
>Unix utilities).
>
>3. Prevented cygwin from VirtualAllocing in the lower 1.5GB area of
>virtual memory. My executable wouldn't load because it need to mmap at
>an absolute address which was stolen by Cygwin's initial VirtualAllocs.
>The method I used was to call VirtualAlloc to reserve the memory before
>the Cygwin DLL was fully initialized, forcing Cygwin to use a higher
>address. Once in mmap_setup, this reserved memory is freed for use by
>LINE.
>
>4. Tried to maximize the amount of (contiguous) virtual memory space
>available to the Linux programs. This opened up a can of worms - you
>can't really control where cygwin1.dll will get loaded... I tried quite
>a few schemes. Basically, if Cygwin has already been loaded before LINE
>runs, you have to use the address it was already loaded at. Cygwin has
>what appears to be a fairly broken scheme of allocating memory directly
>after the end of where the DLL was loaded, which is very difficult to
>avoid being right on top of another DLL if you try to squeeze the memory
>map.
>
>5. Added support for detecting and utilizing 4GB tuning. This gives the
>Linux program an extra 1GB more virtual address space when running under
>Windows 2000 Advanced Server with the /3GB boot.ini setting enabled.
>
>6. Commented back in a few of the syscalls which #ifdef'ed out in LINE
>0.5 and hacked in support for l_times.
>
>7. Cygwin seems to number some of its signals differently to Linux (e.g
>SIGCHLD). I failed to get a remapping layer in the system call handling
>code to work - I never got one of my programs that relied on SIGCHLD
>working.
>
>8. rt_ signal syscalls aren't fully supported. I didn't get around to
>seeing what changes needed, but I noticed that the Cygwin DLL has a
>compile time option to enable them.
>
>9. Doesn't support IPC... I tried and failed to use some IPC code
>already available for Cygwin.
>
>10. Made a few cosmetic changes to make LINE less verbose.
>
>A bit of background - most of my work involves running Windows programs.
>One of these programs is now only supported under Linux and no longer
>under Windows, so my aim was to get it working under LINE to avoid
>rebooting my computer all day long. In all, I got around 90% of the way
>there - most of the features work perfectly under LINE. In the end, I
>bit the bullet and started running it under Linux itself... I soon
>discovered that Linux's VM was (and pretty much still is) broken (both
>Rik's and Andrea's, both in different ways). Programs that ran perfectly
>well under LINE struggled on the same machine under Linux, taking
>several times longer to execute. In the end I topped up the machine to
>4GB of memory. Now the only problems I'm getting are intermittent kernel
>oopses and strange lockups, which I'm working on. Bring back the BSOD,
>all is forgiven!