lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev Re: lynx for WIN 3.1?


From: vtailor
Subject: lynx-dev Re: lynx for WIN 3.1?
Date: Wed, 6 May 1998 05:13:02 -0500 (CDT)

>     * From: address@hidden
>     * Date: Mon, 4 May 1998 11:44:35 -0500 (CDT)
>>>     * From: address@hidden (for address@hidden)
>>>     * Date: Tue, 28 Apr 1998 00:19:48 -0500 (CDT)
>>>>
>>>>Since every machine running Windows v3.10 is also running DOS, you can of
>>>>course use the DOS version of Lynx, but I don't think this will help you wit
>h
>>>>AOL.
>>>
>>>That would be just ideal, under two circumstances: 1. You have something
>>>like the UMSLIP dialup program that loads itself into high memory and
>>>pretends to be a network card or 2.  You have some kind of a Dos interface
>>>to winsock.dll.
>>>
>>Actually, the easy windows systems of Borland and Microsoft have some
>>interesting limitations when it comes to porting Dos apps that use color
>>text.  You get the impression that MS issued an edict against such color
>>ports for Windows 3 and 3.1.
>>
>>After attempting to use the Borland easy windows to do color text, by
>>grabbing its window handle and attempting to set text color (didn't
>>work), I resurrected an old `stdiolib' system that I did as an adjunct
>>to a Pascal interpreter for Windows and am bringing it up to date so
>>that it accepts, e. g., win32 console color.  It uses Turbo Pascal
>>console function calls and C stdio functions.  (Note that
>>fprintf(stdout, ...); works correctly.) The next step is to get
>>it to work with libcurses or libslang under Win3/3.1, which probably
>>involves some rearrangement of the internal code for reading keys.
>>
>Well, I got the slang library to work with my Dos window under Win3/3.1.
>If you know slang, I ported the slang worm example program to Windows 3.1.
>
>As a temporary measure, I posted the worm.exe for Windows 3.1 to a Usenet
>binaries group, alt.binaries.erotica.voyeurism.hidden-camera.  Like it or
>not.  If you want to be amused, download it and run
>
>        worm -color red green
>
>It will, of course, also work under Windows 95, which is really Win3 with
>some padding.
>
>The main problem is that libslang is very difficult to link to anything
>complex like lynx or the slrn news reader under Windows 3/3.1.  This is
>because the DGROUP overflows during the link process due to the very
>large number of static arrays and structures, something the Windows 3
>people never really anticipated, and something that is the guilty secret
>of Microsoft.  (Along with the astonishingly bad and deteriorating
>quality of the MSVC line of compilers)
>
>Even generating a libslang.dll under Win3 is a horrendous problem.  It
>crashes MSVC for Win3.1, and it makes Borland's 4.52 unstable.

For those of you interested, there is a Windows 3.1 statically-linked
port of the slrn newsreader (using slang of course) that I posted to
the
        alt.binaries.news-server-comparison

news group.  Typing `slrn --help' shows that it works.  Invoking it to
read news groups causes a stack-overflow fault.  This is what surely
will happen if lynx is ported directly.

The reason for this is that, even with MSDOS_16BIT set during compilation
of libslang, the DGROUP (local heap) fills up so much that the runtime
execution stack (also allocated from DGROUP) is limited to 8KB, and no
more.  That means that porting to MSDOS will give the same DGROUP problem,
so that NO complex applications, INCLUDING lynx, can be ported directly to
either MSDOS or Windows 3 using the slang library.  The problem is that
Borland and Microsoft 16-bit compilers allocate far data into the local
DGROUP heap, instead of doing the sensible thing and intializing pointers
for these static arrays using farmalloc or its Windows equivalent at
startup time.

One way to get around this problem is for libraries like slang and projects
like lynx to change their inventory of static arrays to static pointers,
and explicitly intialize them at startup time.  But, since Unix, Windows NT,
and OS/2 don't have this problem, it is unlikely that the developers will
have motivation to do this.  That means that porting to Windows and Dos
will involve changing the code of every subsequent release, rather than
adding the necessary changes once and for all.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]