From:     Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To:       Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date:     Tue, 18 Oct 94 03:13:14 EDT
Subject:  Linux-Development Digest #328

Linux-Development Digest #328, Volume #2         Tue, 18 Oct 94 03:13:14 EDT

Contents:
  Re: ext2fs vs. Berkeley FFS (Bryan Sparks)
  Slackware boot disk with kernel 1.1.52(or up) and ncr 53c8xx driver (Jin Yang)
  programming each pixel of a vga/ega screen in Linux (Pritish Shah)
  Re: A badly missed feature in gcc (Orc)
  Re: 8-bit ASCII for comm. (A.E. Brouwer)
  Re: A badly missed feature in gcc (Grant Edwards)
  Re: We a FAQ: Linux vs. *BSD!!! (Grant Edwards)
  Lies, Damned Lies, and Benchmarks (take two) (Jeff Kuehn)
  Re: ext2fs vs. Berkeley FFS (Joerg Mertin)
  Re: Question about ext2fs (Joerg Mertin)
  wxWindows 1.50k shared lib wanted (Tall Sword)

----------------------------------------------------------------------------

From: bryan@infonaut.com (Bryan Sparks)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 17 Oct 1994 15:14:33 -0600

Matthew Dillon (dillon@apollo.west.oic.com) wrote:
: :In article <199410141322.OAA05432@gblinux.demon.co.uk> pdcawley@ftech.co.uk (Piers Cawley) writes:
: :>
: :>In article <CHRISB.94Oct11174651@stork.cssc-syd.tansu.com.au>
: :
: :   Don't be influenced by the over-featurism that NT offers. There's no need
: :   for this crud.
: :
: :Actually, my model for this sort of thing is the Mac filesystem. I wouldn't
: :call it overfeatured, but it does a lot of stuff very well, and very easily,
: :that is a royal PITA to accomplish with Unix.

:     Frankly, I see nothing here that can't be EASILY implemented with
:     directories and file extensions.  IMHO, Mac resource forks were the 
:     second biggest mistake Apple made after the operating system.

:     It sounds to me that you want a database, not a filesystem.

:                                               -Matt

: -- 

:     Matthew Dillon            dillon@apollo.west.oic.com
:     1005 Apollo Way           ham: KC6LVW (no mail drop)
:     Incline Village, NV. 89451        Obvious Implementations Corporation
:     USA                       Sandel-Avery Engineering
:     [always include a portion of the original email in any response!]

Why not Bento (part of OpenDoc)? It seems that is offers many advantages 
and it is available and it is a standard (debatable, I guess).  Another 
thing, it can all be implemented in user space.

Bryan
---
Bryan Sparks
bryan@infonaut.com, bryan@kachina.orem.ut.us
-- 
---
Bryan Sparks
Phone: 801-226-6056 (home)
E-Mail: bryan@infonaut.com, bryan@kachina.orem.ut.us

------------------------------

From: jinyang@cs.utexas.edu (Jin Yang)
Crossposted-To: comp.os.linux.help
Subject: Slackware boot disk with kernel 1.1.52(or up) and ncr 53c8xx driver
Date: 17 Oct 1994 16:46:00 -0500

I would like to install linux on my Intel Premier/PCI pentinum computer
with a PCI SCSI adapter and a SCSI hard drive. I have downloaded the 
slackware distribution from tsx-11.mit.edu. However, the bootdisk disk 
(ncr.gz, kernel 1.1.19) does not recognize the PCI SCSI adapter (ncr 53c8xx). 
Some very kind people on the net told me that kernel 1.1.52 and up will be
able to recognize the adapter. 

Could some one on the net tell me where I can get a slackware bootdisk with 
kernel 1.1.52 (or up) and ncr 53c8xx driver? 

In fact, I already got a 1.1.56 kernel image file (zImage) from a friend but
I don't know how to make a bootdisk for slackware. I have another DX33 computer 
running an old version of linux (kernel 0.98). I tried to follow the 
instruction in SLAKWARE.FAQ to make a boot disk myself but failed. The
instruction in the faq is as follows:

   ... well you grab an existing one like the "bare.gz", put it on a floppy,
   and do this:

   mount /dev/fd0 /mnt (this mounts it)
   cat zImage > /mnt/vmlinuz (put the new kernel in place)
   rdev -R /mnt/vmlinuz 0    (mount read-write)
   rdev /mnt/vmlinuz /dev/fd0H1440   (use that drive, or /dev/fd0h1200)
   rdev -r /mnt/vmlinuz 1440 (set the ramdisk size, or use 1200 with 1.2 meg)
   lilo -r /mnt  (reinstall lilo)
   umount /mnt   (that's it! you're done! :^)

First, the rdev that I have does not support -R option. Second, when I typed
lilo -r /mnt, I got the following error message:

  /etc/lilo/config: no such file or directory

Could someone tell me what is the correct way to make a boot disk from an
image file?

Thanks in advance,

- Jin Yang
  jinyang@cs.utexas.edu


------------------------------

From: pritish@nic.cic.net (Pritish Shah)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: programming each pixel of a vga/ega screen in Linux
Date: 17 Oct 1994 22:22:08 GMT


Hello all, 

I am trying to write a display system on Linux that will display 
different messages on the vga/ega screen using different fonts and 
different attributes. I was informed that there might be something called 
getpixel/putpixel function that could work for the screen. 

Any help would be appreciated. This is for my project at school.

Pritish

--


**********************************************************************
Pritish M Shah                   * Contact:      Phone 1-313-998-6700
#include <standard_disclaimer.h> *               Fax   1-313-998-6105 
http://www.cic.net/~pritish/     *               email pritish@cic.net


------------------------------

From: orc@pell.com (Orc)
Subject: Re: A badly missed feature in gcc
Date: Thu, 13 Oct 1994 03:19:44 GMT

In article <hpa.45d30000.Heja.Sverige@ahab.eecs.nwu.edu>,
H. Peter Anvin <hpa@nwu.edu> wrote:
>  /* ... */ is supported as backward
>compatibility, but you will be hard-pressed to find a C++ programmer
>who uses them more than once in a blue moon.

   I prefer to use them when writing C++ code. // makes my code
look like assembly language.

                 ____
   david parsons \bi/ followups set out of c.o.l.d
                  \/

------------------------------

From: aeb@wsdw01.win.tue.nl (A.E. Brouwer)
Subject: Re: 8-bit ASCII for comm.
Date: 17 Oct 1994 17:21:04 +0100

gavrie@pesach.jct.ac.il (Prof. Gavrie Philipson) writes:

: Is there any way to display 8-bit ASCII on the Linux console?
: When I call PC-based BBSes from Linux, I just get rubbish
: for >127 characters.

Well, first of all, there is no such thing as 8-bit ASCII,
and if there were, then no doubt it would not be what you need.
You want IBM code page 437 or something similar, I think.
Try to give the command  echo -e '\033(U'  before calling
that BBS.

------------------------------

From: grante@reddwarf.rosemount.com (Grant Edwards)
Subject: Re: A badly missed feature in gcc
Date: Sun, 16 Oct 1994 01:12:48 GMT

H. Peter Anvin (hpa@ahab.eecs.nwu.edu) wrote:
: In newsgroup: comp.os.linux.development
:
: > This is doubtful. The problem is that making this a 'feature' of ANSI c 
: > will all of a sudden make previously syntacticly correct code now fail to 
: > compile or, worse, compile with a different symantic meaning.  This woudl 
: > be DISASTEROUS to the attempt to standardize C.

: It is *already* put into quite a number of compilers (making it a
: portability issue already), and anyone writing code that uses that
: type of constructs should be shot anyway.

True, though I suspect that anybody writing code like that has enough
problems that a bullet wound would go unnoticed.  That aside, it is
fine and proper for you and I to have opinions on what is good style
and what isn't.  I actually enjoy discussing the pro's and con's of
various "style" questions with other people (like whether it's a good
idea to have code/data and a comment on the same line).

However, it is _not_ acceptable for a compiler to have an "opinion"
about style.  Given sytactically valid source code, it shall parse it
and generate correct machine code -- no matter how ugly, stupid,
counter-productive, or obfuscated that source code might be.

: It is true there are such cases, but they are throuroughly and
: completely artificial.

If construct X is legal then rest assured that somebody, somewhere,
has written a real program that relies on that fact.  If you've ever
tried to remove a "useless" feature from a product, you've found this
out.

      Me: "But Mr. Customer, the fact that status bit XYZ did that was
          a _bug_ as you should be able to tell by the documentation,
          and now that bug has been fixed."

Customer: "I don't care.  It used to do that, we depended on it, now
          it doesn't.  Fix it back."

--
Grant Edwards                                 |Yow!  You can't hurt me!!  I
Rosemount Inc.                                |have an ASSUMABLE MORTGAGE!!
                                              |
grante@rosemount.com                          |

------------------------------

Crossposted-To: comp.os.386bsd.development,comp.sys.unix
From: grante@reddwarf.rosemount.com (Grant Edwards)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Sun, 16 Oct 1994 01:21:47 GMT

Jesus Monroy Jr (jmonroy@netcom.com) wrote:

:       Can we get together and write a single FAQ on this?

Probably not...

:       I propose a single FAQ to answer the question:
:
:       Which is better Linux or *BSD?

You'd be better off with the question:

  "What are the similarities/differences between Linux and *BSD?"

:       Do I get a Yeah on this?

I won't say Nay, but I suspect that it would be impossible to keep it
current enough to be useful.

--
Grant Edwards                                 |Yow!  I hope I bought the
Rosemount Inc.                                |right relish...
                                              |zzzzzzzzz...
grante@rosemount.com                          |

------------------------------

From: kuehn@citadel.scd.ucar.edu (Jeff Kuehn)
Subject: Lies, Damned Lies, and Benchmarks (take two)
Date: 17 Oct 1994 21:34:40 GMT

Well, as promised, here's the corrected results for the Byte Magazine UNIX
benchmark comparing Linux versions 1.0.4 through 1.1.54.  As before, I
haven't run every patchlevel (only 21 of them :-) but I'm willing to run 
individual patchlevels on request, and can provide detailed information on
each benchmark result for any patchlevel which has been run.  (see the data
for the 1.1.54 run after the table)  Please don't send me code which hasn't
been thoroughly tested... each benchmark requires a kernel build, a reboot
and an hour to run.  I you have code which has been carefully tested, I'm
willing to benchmark it.  Please, send diffs against PL52 (the most recent
version for which Linus has posted a full source tar).

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The headers in the table below refer to the various tests in the Byte Magazine
UNIX Benchmark as follows.

Versn   linux kernel version            Ar      Arithmetic Test (type = double)
Dr      Dhrystone 2 w/o register vars   Exc     Execl Throughput Test
FC1     File Copy  (10 seconds)         FC3     File Copy  (30 seconds)
FR1     File Read  (10 seconds)         FR3     File Read  (30 seconds)
FW1     File Write (10 seconds)         FW3     File Write (30 seconds)
Pip     Pipe-based Context Switch Test  PCT     Process Creation Test
Sh1     Shell scripts (1 concurrent)    Sh2     Shell scripts (2 concurrent)
Sh4     Shell scripts (4 concurrent)    Sh8     Shell scripts (8 concurrent)
Sys     System Call Overhead Test       PTT     Pipe Throughput Test.
SUM     sum of values in row

The numbers in the table, represent the ratio of test(pl)/test(1.1.0),  Bigger
numbers indicate better performance.  Also note that a pipe throughput test
has been added.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hardware:       iNTEL 66MHz 486DX/2 
                AMI Enterprise III EISA/VLB Motherboard (AMI BIOS/Chipset)
                256K 4-way set associative writeback cache
                16MB 70ns RAM
                AHA-1742 EISA SCSI host adaptor
                Toshiba MK538 1.2GB SCSI drive

Versn |Ar|Dr|Exc|FC1|FC3|FR1|FR3|FW1|FW3|PTT|Pip|PCT|Sh1|Sh2|Sh4|Sh8|Sys|SUM
1.0.04|1.|1.|1. |1. | .9|1. |1. | .9| .9|1. | .9|1. |1. |1. |1. |1. |1. |16.7
1.0.09|1.|1.|1. |1. | .9|1. |1. |1. |1. |1. | .9|1. |1. |1. |1. |1. |1. |16.8
1.1.00|1.|1.|1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |17.0
1.1.01|1.|1.|1. |1. |1. |1. |1. | .9|1. |1. |1. |1. |1. |1. |1. |1. |1. |16.9
1.1.02|1.|1.|1. |1. | .9|1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |1. |16.9
1.1.03|1.|1.| .9| .9|1. |1. |1. | .7| .9|1. | .9|1. |1. |1. |1. |1. |1. |16.1
1.1.04|1.|1.| .9| .9|1. |1. |1. | .7| .9|1. | .9|1. |1. |1. |1. |1. |1. |16.1
1.1.05|1.|1.| .9| .9|1. |1. |1. | .7| .9|1. |1. |1. |1. |1. |1. |1. |1. |16.2
1.1.10|1.|1.| .9|1.3|1.4|1. |1. | .7| .9|1. |1. |1. |1. |1. |1. |1. |1. |17.0
1.1.15|1.|1.| .9|1.3|1.5|1. |1. | .7| .9|1. |1. |1. | .9| .9| .9|1. |1. |17.0
1.1.20|1.|1.| .9|1.2|1.4| .9| .8| .6| .8| .9| .9|1. | .9| .9| .9|1. |1. |16.3
1.1.25|1.|1.| .9|1.2|1.4| .9| .9| .7| .9| .9| .9|1. |1. |1. | .9|1. |1. |16.6
1.1.30|1.|1.| .9|1.2|1.5| .9| .9| .7| .9| .9| .9|1. |1. |1. | .9|1. |1. |16.6
1.1.35|1.|1.| .9|1.2|1.4| .9| .9| .6| .9| .9|1. |1. |1. |1. |1. |1. |1. |16.5
1.1.40|1.|1.|1. |1.2|1.3| .8| .8| .6| .8| .9| .6|1. |1. |1. |1. |1. | .9|16.0
1.1.45|1.|1.|1. |1.2|1.3| .9| .9| .6| .9| .9| .9|1. |1. |1. |1. |1. |1. |16.7
1.1.50|1.|1.|1. |1.2|1.3| .8| .8| .6| .9| .9| .8| .9|1. |1. |1. |1. |1. |16.4
1.1.51|1.|1.|1. |1.2|1.3| .8| .8| .6| .9| .9| .9|1. |1. |1. |1. |1. | .9|16.5
1.1.52|1.|1.|1. |1.3|1.4| .8| .8| .9| .9| .9| .9|1. |1. |1. |1. |1. |1. |16.8
1.1.53|1.|1.|1. |1.1|1.3| .8| .9| .6| .9| .8| .8|1. |1. |1. |1. |1. |1. |16.3
1.1.54|1.|1.|1. |1.1|1.3| .8| .8| .6| .9| .9| .9|1. |1. |1. |1. |1. | .9|16.2

SunOS
4.1.3 |.5|.4| .1| .9|1.0| .1| .1| .1| .1| .1| .2| .4| .2| .2| .2| .2| .2| 5.1
(SPARCstation IPC, 24MB RAM, 200MB SCSI drive)

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Here's the data for Linux 1.1.54 vs. the baseline 1.1.0. 
(note: lps==loops/second and lpm==loops/minute).

  BYTE UNIX Benchmarks (Version 3.11)
  System -- Linux cyberdeck 1.1.54 #5 Sun Oct 16 17:10:43 MDT 1994 i486
  Start Benchmark Run: Sun Oct 16 17:31:47 MDT 1994
   1 interactive users.
Arithmetic Test (type = double)            5069.1 lps   (10 secs, 6 samples)
Dhrystone 2 without register variables    51635.1 lps   (10 secs, 6 samples)
File Read  (10 seconds)                   94368.0 KBps  (10 secs, 6 samples)
File Write (10 seconds)                    7871.0 KBps  (10 secs, 6 samples)
File Copy  (10 seconds)                    1312.0 KBps  (10 secs, 6 samples)
File Read  (30 seconds)                   91781.0 KBps  (30 secs, 6 samples)
File Write (30 seconds)                   11640.0 KBps  (30 secs, 6 samples)
File Copy  (30 seconds)                    1224.0 KBps  (30 secs, 6 samples)
Pipe-based Context Switching Test          6796.6 lps   (10 secs, 6 samples)
Pipe Throughput Test                      18999.9 lps   (10 secs, 6 samples)
Execl Throughput Test                        63.2 lps   (9 secs, 6 samples)
Process Creation Test                       109.0 lps   (10 secs, 6 samples)
System Call Overhead Test                 29827.4 lps   (10 secs, 6 samples)
Shell scripts (1 concurrent)                 98.1 lpm   (60 secs, 3 samples)
Shell scripts (2 concurrent)                 51.3 lpm   (60 secs, 3 samples)
Shell scripts (4 concurrent)                 26.0 lpm   (60 secs, 3 samples)
Shell scripts (8 concurrent)                 13.0 lpm   (60 secs, 3 samples)


                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Arithmetic Test (type = double)               5062.4     5069.1        1.0
Dhrystone 2 without register variables       51685.8    51635.1        1.0
Execl Throughput Test                           64.1       63.2        1.0
File Copy  (10 seconds)                       1172.0     1312.0        1.1
File Copy  (30 seconds)                        951.0     1224.0        1.3
File Read  (10 seconds)                     117544.0    94368.0        0.8
File Read  (30 seconds)                     119451.0    91781.0        0.8
File Write (10 seconds)                      12389.0     7871.0        0.6
File Write (30 seconds)                      13393.0    11640.0        0.9
Pipe Throughput Test                         21779.3    18999.9        0.9
Pipe-based Context Switching Test             7620.8     6796.6        0.9
Process Creation Test                          112.2      109.0        1.0
Shell scripts (1 concurrent)                    97.1       98.1        1.0
Shell scripts (2 concurrent)                    51.0       51.3        1.0
Shell scripts (4 concurrent)                    26.0       26.0        1.0
Shell scripts (8 concurrent)                    12.6       13.0        1.0
System Call Overhead Test                    31504.0    29827.4        0.9
                                                                 =========
     SUM of 17 items                                                  16.2
     AVERAGE                                                           1.0

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Observations:

0) My Linux (home) system soundly stomps the stuffings out of my SunOS
   (work) system in terms of performance... by about a factor of three.

1) The scheduler, while not perfect, is better than first estimated due to
   the awk(1)/time(1) problems in the first benchmark.

2) The I/O performance is pretty touch-and-go with a lot of variation in the
   numbers.  IMHO, since the benchmark ran almost entirely in memory, the
   problem lies above the device drivers,  probably in either the buffer
   cache code or filesystem code.  It has already been suggested (by Eric)
   that the problem could lie in the memory allocation which is heavily used
   by the buffer cache.  Were this the case, I think I would expect to see
   the File Read tests showing more problems than the File Write tests.  The
   opposite was true -- File Write did more poorly than File Read.  I'd like
   to hear more discussion on this.  File Write dropped off at 1.1.3 and
   File Read dropped off between 1.1.15 and 1.1.20 (remember these numbers).

3) Somewhere between 1.1.15 and 1.1.35 the File Copy test did the best and
   since dropped off a bit.  Again, most of this happened in cache on my
   machine, so IMHO this doesn't represent device driver performance, but
   rather reflects the performance of filesystem/buffer cache and associated
   algorithms.

4) Pipes seem to have become more expensive to use (Pipe-based Context
   Switching Test and Pipe Throughput Test) since somewhere between 1.1.15
   and 1.1.20.  Could this be another symptom of whatever happened to File
   Read between 1.1.15 and 1.1.20?

5) System call overhead is up a little as well since somewhere between
   1.1.35 and 1.1.40.


Jeff Kuehn
Scientific Computing Division
National Center For Atmospheric Research
Boulder, Colorado  USA

------------------------------

From: smurphy@stardust.bln.sub.org (Joerg Mertin)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 16 Oct 1994 10:09:38 GMT
Reply-To: smurphy@stardust.bln.sub.org

In comp.os.linux.development Theodore Ts'o (tytso@MIT.EDU) wrote:
:    From: mike@majestix.cs.uoregon.edu (Mike Haertel)
:    Date: 03 Oct 1994 20:46:49 GMT

[...] Stuff deleted

: In any case, it's a good idea to optimize for the common case, not the
: exception case.  Thus, I believe ext2fs made a pretty good tradeoff.
: Not doing syncronous meta-data writes gives the ext2fs a blinding speed
: advantage over the FFS.  From my experience with both FFS and ext2fs,
: ext2fs is just as reliable --- if not more --- than FFS in surviving
: unclean shutdowns.

That's right. I would say, under Xwindows I have better chances of
saving unclosed files than under MSWindog while editing a file and
having a system-Crash (Which happens once all 2 houres).
In fact, I never loosed any file with ext2fs since I use it. And my
first release was 0.2 :-) Just Good. 
Thanks to all developers of this fs !

Just my 2 cents :^)
--
Solong & Happy Hacking
************************************************************************
*   Joerg Mertin          :   smurphy@stardust.bln.sub.org (Home)      *  
* in Berlin Spandau at    :   jorgagif@w203zrz.zrz.tu-berlin.de        *
* Stardust's Linux System :   Data, Fax & Voice 49 30 3615569          *
************************************************************************
`Fatal Error: Found [MS-Windows] System -> Terminating Virus...'

------------------------------

From: smurphy@stardust.bln.sub.org (Joerg Mertin)
Crossposted-To: comp.os.linux.help
Subject: Re: Question about ext2fs
Date: 16 Oct 1994 18:06:37 GMT
Reply-To: smurphy@stardust.bln.sub.org

In article <1994Oct11.150318.28373@news.cs.indiana.edu>, "Eric Jeschke" <jeschke@cs.indiana.edu> writes:
: |> Can someone with some knowledge of the ext2fs internals tell me
: |> how intensive the disk activity is to certain blocks like the
: |> superblock and inode bitmap blocks?  extfs is working fine, but
: |> I'm afraid I have a poor quality disk (Seagate) that is not able
: |> to handle the intense repeated disk activity to these blocks.

: |> I am slowly developing bad blocks on various inode bitmap blocks
: |> (and now the superblock).  The kernel complains about getting a
: |> "short read" on those blocks.  I am able to map them out successfully
: |> using the -L option with ext2fs and the system recovers admirably,
: |> but sooner or later the problem recurs with another block.  The
: |> latest victim is the superblock on the root partition.  I am able
: |> to e2fsck the partition using the -b 8193 option and averything seems
: |> fine, however the system fails to mount it at bootup even though
: |> I added sb=8193 to the mount options in /etc/fstab for /.
: |> 
: |> How can I successfully boot from this partition now?

Well, I've recently made such an experience on my system with an
ST1480A Seagate 420 MB Harddisk. The only thing to do was to make a
backup, getting a low-level Formating & Testing programm from seagate
and test the entire disk so the Disk-Controller could remmap all
bad-Blocks found. After it, all worked well again, but this should't
happen anyway. I noticed it, since I had a bad block on one Startup
File, so I had to fix this problem :^<

cu.
--
Solong & Happy Hacking
************************************************************************
*   Joerg Mertin          :   smurphy@stardust.bln.sub.org (Home)      *  
* in Berlin Spandau at    :   jorgagif@w203zrz.zrz.tu-berlin.de        *
* Stardust's Linux System :   Data, Fax & Voice 49 30 3615569          *
************************************************************************
`Fatal Error: Found [MS-Windows] System -> Terminating Virus...'

------------------------------

From: cs_kokim@dmf123.ust.hk (Tall Sword)
Subject: wxWindows 1.50k shared lib wanted
Date: Thu, 13 Oct 1994 07:48:50 GMT

I have compiled wxWindows 1.50k in my Linux box and found it quite useful
for developing cross platform GUI program. But the wxWindows 1.50k only
generate a static lib for me and it make the executable file quite large 
and the time of compiling is longer too.

Anyone else where got a copy of shared lib of wxWindows 1.50k? I realized
that there is copy in sunsite that support shared lib but that version is 
older that only support XView 3.1. Please direct me to the right site and
directories to get the shared lib. 

--
* Origin: TallSword, Computer Science Year 2, HKUST
          internet: cs_kokim@dmf123.ust.hk, cs_kokim@stu.ust.hk
                root@dmf123.ust.hk, raymond@dmf123.ust.hk
                            Raymond.Ko@f15.n700.z6.ftn.air.org
          fidonet:  Raymond Ko, 6:700/15@fidonet.org
                

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
