Dec 262017
 
Linux news from the net.
File INTLX018.ZIP from The Programmer’s Corner in
Category UNIX Files
Linux news from the net.
File Name File Size Zip Size Zip Type
INTLX018.TXT 227462 64368 deflated

Download File INTLX018.ZIP Here

Contents of the INTLX018.TXT file


From: [email protected] (Paul Brant)

Subject: Raytracers !!
Message-ID: <[email protected]>
Date: 1 May 92 11:14:21 GMT
Sender: [email protected] (GNEWS Version 2.0 news poster.)
Organization: THEO - A comms persons sanctuary(Its Not much but its my own!)
Lines: 21

Hi,

I obtained the sources for the raytracer DKB. Within in that there are
files for UNIX. The only changes I had to make where to MATH.H
they were :
to DEFINE DOMAIN,SING,OVERFLOW and UNDERFLOW
and
to create struct exception { ... }

I am running LINUX 0.95C+. I do not know what the values should be for
LINUX. I got mine from somwhere else..
With those additions it compiles error free. I used GCC 1.40 to compile.

Within the sources there is also some code for X Windows.. How close are
we to having a implemention of X?

On another note and the continuation of the MGR debate. Surely it would
be in the best interest of the LINUX OS if as much as possible was ported
to it.There.. thats my bit said.. ๐Ÿ™‚

Paul


[next article]
From: [email protected] (Joel M. Hoffman)

Subject: GNU Emacs memory problems: solution!
Message-ID: <[email protected]>
Date: 2 May 92 18:40:37 GMT
Sender: [email protected] (USENET News system)
Organization: University of Maryland, College Park
Lines: 11
Nntp-Posting-Host: next.wam.umd.edu

I reported a few days ago that GNU Emacs or the kernel seemed to have
a memory le}k. [email protected] pointed out that the problem
lies with the emacs binary, not with the kernel. There's a new emacs
binary on tsx-11 (emacs.Z) and also a new etc.tar.Z file. I just got
the new emacs.Z, and emacs can run (the memory-intensive) getris.el.
If you're having problems with emacs and OOM errors, get the new
binary. (I haven't tried the new etc.tar yet; don't know what's
different in it.)

-Joel
([email protected])


[next article]
From: [email protected] (Willem Kasdorp)

Subject: new SVGA patch. Realtek card added
Message-ID: <[email protected]>
Date: 2 May 92 19:11:06 GMT
Organization: NIKHEFK
Lines: 214

I have a SVGA card from Realtek. Since this card is not recognized
by the startup code, I made a patch to detect it. I append it below.
Some remarks:

- This patch is relative to Linux 0.95c+, and needs to have the
Dennis Flaherty SVGA patch (version 3, 24th April) applied first.
Look in tsx-11.mit.edu in the pub/linux/patches directory for this.

- The detection is really simpleminded. I check for the string
'REALTEK VGA' in the SVGA ROM. If there is another version of the
REALTEK card that does not support the SVGA text modes, the patch
needs patching ๐Ÿ™‚

- I added an option to select the usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
le usual 80x50 VGA mode as well. Just
press enter at the list of available text modes.

- Someone mentioned some days ago that his machine would hang upon entering
the SVGA selection menu. I noticed that the code in boot/setup.S directly
reads the keyboard. That code might well hang the computer if it encounters
some outlandish keyboard. Maybe a keyboard specialist can have a look at it.

- If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
lati: .word 0x8419, 0x842c
! dscahead: .word 0x842c, 0x8419, 0x841c, 0xa032, 0x5042
! dsccandt: .word 0x8419, 0x8432
! dsccirrus: .word 0x8419, 0x842c, 0x841e, 0x6425
! dsceverex: .word 0x5022, 0x503c, 0x642b, 0x644b, 0x8419, 0x842c, 0x501e,
0x641b, 0xa040, 0x841e
! dscgenoa: .word 0x5020, 0x642a, 0x8419, 0x841d, 0x8420, 0x842c, 0x843c,
0x503c, 0x5042, 0x644b
! dscparadise: .word 0x8419, 0x842b
! dsctrident: .word 0x501e, 0x502b, 0x503c, 0x8419,ati: .word 0x8419, 0x842c
! dscahead: .word 0x842c, 0x8419, 0x841c, 0xa032, 0x5042
! dsccandt: .word 0x8419, 0x8432
! dsccirrus: .word 0x8419, 0x842c, 0x841e, 0x6425
! dsceverex: .word 0x5022, 0x503c, 0x642b, 0x644b, 0x8419, 0x842c, 0x501e,
0x641b, 0xa040, 0x841e
! dscgenoa: .word 0x5020, 0x642a, 0x8419, 0x841d, 0x8420, 0x842c, 0x843c,
0x503c, 0x5042, 0x644b
! dscparadise: .word 0x8419, 0x842b
! dsctrident: .word 0x501e, 0x502b, 0x503c, 0x8419, msb = Cols lsb = Rows:

! dscati: .word 0x8419, 0x842c
! dscahead: .word 0x842c, 0x8419, 0x841c, 0xa032, 0x5042
! dsccandt: .word 0x8419, 0x8432
! dsccirrus: .word 0x8419, 0x842c, 0x841e, 0x6425
! dsceverex: .word 0x5022, 0x503c, 0x642b, 0x644b, 0x8419, 0x842c,
0x501e, 0x641b, 0xa040, 0x841e
! dscgenoa: .word 0x5020, 0x642a, 0x8419, 0x841d, 0x8420, 0x842c,
0x843c, 0x503c, 0x5042, 0x644b
! dscparadise: .word 0x8419, 0x842b
! dsctrident: .word 0x501e, 0x502b, 0x503c, 0x8419, 0x841e, 0x842b,
0x843c
! dsctseng: .word 0x503c, 0x6428, 0x8419, 0x841c, 0x842c
! dscvideo7: .word 0x502b, 0x503c, 0x643c, 0x8419, 0x842c, 0x841c
! dscrealtek: .word 0x501e, 0x502b, 0x503c, 0x8419, 0x841e, 0x842b,
0x843c

.text
endtext:


[next article]
From: [email protected] (Drew Eckhardt)

Subject: Re: Non-destructive repartitioning?
Message-ID: <[email protected]>
Date: 2 May 92 19:45:54 GMT
References: <[email protected]> <[email protected]
du>
Sender: [email protected] (The Daily Planet)
Organization: University of Colorado at Boulder
Lines: 480
Nntp-Posting-Host: hamlet.cs.colorado.edu

In article <[email protected]> [email protected] (Wen-Chun Ni) w
rites:
>In article <[email protected]> [email protected] (Daniel B
rahneborg) writes:
>>I heard something a while ago about some program that could
>>repartition your hard disk without deleting everything on it,
>>but just writing a new smaller FAT. Of course the files had to
>>be on the lower part of the disk. As I have ~160 megs on my HD,

>I want it too, please. I've tried partit and edpart, but they all
>have their limitations.
>
>


It's not a program, but a manual procedure requiring
a. a partitioning program
b. a sector editor

Here it is :


Reformatting your hard disk, and reinstalling all your DOS programs from
scratch can be a real nuissance, and is unecessary.

Breathe a sigh of relief : it is possible to non-destructively repartition
hard disks.

Notes : Before continuing, make sure you have a RECENT BACKUP.

I assume that you understand hex arithmatic, and are not
afraid of a little assembler or DEBUG.

Actually, a decent partition and disk editor will get you around
this - NU works gret.

Of course, the modern programmer doesn't use anything but a
source level debugger - so I've included some helpful hints
and the command syntaxes. However, there is no room for
handholding here : if you screw up, you might have to use
that backup. Don't do it unless you are confident in your
abilities.

Also, this procedure only works with NON-EXTENDED DOS partitions,
< 64K logical sectors, (DOS 4 large partitions add additional BPB
fields that I am unsure of - roughly the same procedure applies there
though. According to Townsend' Advanced MS DOS : Expert Techniques
for programmers

offset 26h will have the signature byte 29h if this is
the case, 20h a dword containing the number of sectors if
volume size > 64K sectors

I still use MS-Loss 3.3, with an ~82M partition under disk mangler
and fall into the tested category)

Large partitions, handled by a third party partition manager
and handled so that there are < 64K logical sectors
work - this was the case with my SCSI disk.

I will lay down what general procedures you need to know (
required to read / write the raw disk), as well as the
data structures we are dealing with. Then I will proceed
with the entire procedure, which applies the general procedures
in reading and modifying the data structures. If it looks like
a tech manual - it is. If you don't grok non-destructive
repartitioning, you shouldn't be doing it.

DEBUG has a Hexaritmatic command, h which will add and
subtract the two operands. You may find this useful.

IE : I have loaded sector 0 into memory at 0200, and wish to know
the address of the partition table at 1be.

-h 200 1be
03BE 0042

Where 03BE is the sum, and 042 the difference.

DEBUG prints a segment before the offset : note that your segments
will probably not match. The offset is what's important.

The 80x86 family is LITTLE ENDIAN. This means least significant
byte first - ie the internal representation of 0x12345678 would be
78 56 34 12. When dealing with multi-byte quantities, keep this
in mind.

When I say word, I mean word as in the Intel documentation :
16 bits. dword is 32 bits.

DISK BIOS addresses cylinder, head as zero based, sector
as 1 based. Same thing for the partition table.

DOS addresses sectors as 0 based, from the start of the
logical partition, and as logical sectors which may
consist of multiple physical sectors.

Unless otherwise noted, all numbers are hex.

You're better off using Norton Utilities - but Debug works fine
too.

This document is sort of a quick hack 8^)

Tools :

Required : DEBUG, and a disk defragmenter

Optional : partition editors (NOTE!!!! Make sure these DO NOT perform
any formatting, and allow you to edit partitions in the
REAL order they appear on the disk.), the Linux FDISK program,
utilities that save an image of the boot sector FATs, and
directory (IE Norton's Format Recover), a raw disk editor
(Norton Utilities NU)..

Procedures :
Editing memory with debug :

d ADDRESS l LENGTH

will dump memory

f ADDRESS l LENGTH values

will fill memory.


Reading and writing DOS logical sectors (using debug):

Reading is accomplished using the debug l command.

l ADDRESS DRIVE SECTOR COUNT

Where ADDRESS is the hex address of where to put the data,

DRIVE is a 0 based drive number (IE A:=0, B:=1, C:=2, etc. If there
is only one floppy drive, it is considered both A: and B: as it is
in DOS)

SECTOR is a zero based sector number. Of interest to us are
sector 0, the boot sector, and the sectors immediately following it -
the FAT's.


COUNT is the number of sectors to read.


So, to read in the first 10 sectors of the FAT on my E: partition (the
FAT starts at sector 1), storing them at 0200, I would enter

l 0200 4 0 A

Writing is done with the W command, which takes the same
parameters. Assuming I had edited the boot sector of E: at 0200 in memory,
and wanted to write it back to disk, I would type in

w 0200 4 0 1


Using Norton Utilities NU:

xplore disk, hoose Item, ector, dit/display

Unfortunately, absolute sector 0 falls outside of all partitions (this
is where the partition table is), and we need to use a different
procedure for it.

Reading / Writing absolute sector 0:
The following debug / assembler interaction shows how to read absolute disk
sector 0 , replace xx with 80 for hard disk 0, 81 for hard disk 1:

-a 0100
1984:0100 mov ax, 0201
1984:0103 mov bx, 0200
1984:0106 mov cx, 0001
1984:0109 mov dx, 00xx
1984:010C int 13
1984:010E int 20
1984:0110 ^C

-


-g = 0100

This will read sector 0 into DS:0200. To write it back,

-a 0100
1984:0100 mov ax, 0301
1984:0103 ^C


-g = 0100.


Using Norton Utilities NU :
Under xplore disk, choose hoose item, bsolute sector, dit / display



Structures :

1. The Partition table

The partition table resides at absolute sector 0 (ie
cylinder 0, head 0, sector 1) on all harddisks. It is accessed
by a short bootstrap loader on that sector, which reads the partition
table and then picks a partition from which to load the boot sector for
the operating system.


The partition table itself resides at offset 1be. It is 64 bytes (decimal)
in length, plus the two byte signature 55 AA. When dealing with the
partition table, make sure byte 40 (offset 1fe of the sector) is 55 and
byte 41 (offset 1ff of the sector) is
of the sector




The partition table is subdivided into FOUR 16 byte entries, fielded
as follows :
offset length field
0 byte bootable 80h = bootable, 0 = not
1 byte starting head number
2 word starting cylinder (and sector - sector is 1 based
high byte is low byte of cylinder, low byte low 6 bits is
sector, high 2 bits of low byte high 2 bits of cylinder)


typically, sector = 0.

4 byte system 1 = primary DOS, 12 bit, 4 = primary DOS 16 bit,
5 = extended DOS, 8 = NON-DOS (might be usable)
5 byte ending head number


6 word ending cylinder / sector

8 dword starting sector (relative to begining of disk - THIS IS ZERO
based)

C dword number of sectors



My partition table on drive 0 looks like :

-d 3be
1984:03BE 80 01 ..
1984:03C0 01 00 01 05 22 08 22 00-00 00 0A 07 00 00 00 00 ....".".........
1984:03D0 01 09 51 05 E2 2B 2C 07-00 00 E4 7F 02 00 00 00 ..Q.b+,...d.....
1984:03E0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
1984:03F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 55 AA ..............U*

Interpreting this, we can see that I have two partitions in use -
partition 1 and 2, the rest being blank.


My first partition is bootable (80)
FAT size is 12 bits (type = 01)
It starts at head 1, cylinder 0, sector 1, which is sector 22
(34 decimal) relative to the start of the disk.
It is 0000070a sectors in length (1802 decimal), and ends on
head 5, cylinder 8, sector 22 (34 decimal).


My second partition is non-bootable (00).
It is type 51 (Disk Mangler) meaning I need to
find out fat size some other way.

It starts at Head 0, cylinder 9, sector 1, which is sector 72c
(1836 decimal) relative to the start of the disk.
It is 27FE4 (163812 decimal) sectors in length, and ends on
head 5, cylinder 32b (811 decimal), sector 22 (34 decimal)..

See how I got ending cylinder? In Hex, each digit is a nibble. You can
easily convert to binary a nibble at a time. IE E2 becomes 1110 0010


The low 6 bits (sector) are 10 0010 = 22
The high 2 bits are 11 = 3

So high byte cylinder is 03, low byte is 2B so cylinder = 032b

Got it?



2. The Boot sector

The second important piece of data is the bootsector. There are a number
of fields we are interested in. I have ommitted the DOS 5 extended fields

(Can't give you an answer I'm 100% sure on), as well as fields unecessary
to our procedure.

Fields we are interested in :
Offset Size Field
b word bytes per LOGICAL sector - divide by 512 to get physical
to logical mapping

d byte sectors per cluster. Multiply by logical sector size and
divide by 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 y 1024 (decimal) to get K / cluster

13 word total number of LOGICAL sectors. This is one field
extended by DOS5.

18 word sectors per track

1a word heads

Clusters = sectors / sectors per cluster.

Since my first partition on drive 1 is fairly boring, we'll look at
partition 2 - E:

-l 0200 4 0 1
-d 0200
1984:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1984:0210 02 00 02 F9 9F F8 0A 00-22 00 06 00 2C 07 ed from the
word size field at offset b divided by a 200 hex (512 decimal) byte
sector size)

After image for my example :
-l 0200 4 0 1
-d 0200
1563:0200 EB FE 90 4E 4F 53 59 53-54 45 4D 00 08 04 01 00 k~.NOSYSTEM.....
1563:0210 02 00 02 FB 9D F8 0A 00-22 00 06 00 2C 07 80 00 ...{.x.."...,...

6. Adjust partition table. Change ending head, cylinder, sector
field of old partition, total sectors of old partition,
add new partition.

Avoid overlap. Note that new partition table becomes active
on reboot.

After image for our example:
-d 03be
1563:03BE 80 01 ..
1563:03C0 01 00 01 05 22 08 22 00-00 00 0A 07 00 00 00 00 ....".".........
1563:03D0 01 09 51 05 E2 21 2C 07-00 00 EC 77 02 00 00 00 ..Q.b!,...lw....
1563:03E0 C1 22 FF 05 E2 2B 18 7F-02 00 F8 07 00 00 00 00 A"..b+....x.....
1563:03F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 55 AA ..............U*

Yes, I know 0xff is a bizarre identifier for the linux partition. That's
how I did my first one, that's how I did this one.

References :
Norton, Peter Norton's Programmer's Guide to the IBM PC
Townsend, Advanced MS-DOS Expert Techniques for Programmers

Hopefully this has been enlightening, and possibly even useful to some.

Mail comments to [email protected]


[next article]
From: [email protected](97%)
Yes, I know 0xff is a bizarre identifier for the linux partition. That's
how I did my first one, that's how I did this one.

References :
Norton, Peter Norton's Programmer's Guide to the IBM PC
Townsend, Advanced MS-DOS Expert Techniques for Programmers

Hopefully this has been enlightening, and possibly even useful to some.

Mail comments to [email protected]



[next article]
From: [email protected]>, [email protected]
(Hallvard Paulsen) says:
>
>> The part of editing the bootimage disk I just cant get. I've
>> got the pboot.exe dos program and it keeps asking for a filename? On my
>> bootdisk there *are* *no* filenames that dos can recognize. I've no dowloaded
>
>It's a lot easier if you modify the bootimage *before* you rawrite it to
>disk. If that is not possible, use debug to edit the boot sector (Warning:
>some versions of MSDOS will not edit a disk if it does not.no>, [email protected]
(Hallvard Paulsen) says:
>
>> The part of editing the bootimage disk I just cant get. I've
>> got the pboot.exe dos program and it keeps asking for a filename? On my
>> bootdisk there *are* *no* filenames that dos can recognize. I've no dowloaded
>
>It's a lot easier if you modify the bootimage *before* you rawrite it to
>disk. If that is not possible, use debug to edit the boot sector (Warning:
>some versions of MSDOS will not edit a disk if it does noat next? [npq] Article 1177 (37 more) in comp.os.linux:
From: [email protected] (Drew Eckhardt)

Subject: Dynamic linking
Summary: It works for some definition of the word works
Message-ID: <[email protected]>
Date: 2 May 92 20:29:56 GMT
Sender: [email protected] (The Daily Planet)
Organization: University of Colorado at Boulder
Lines: 61
Nntp-Posting-Host: hamlet.cs.colorado.edu


I patched my kernel to do dynamic linking of any OMAGIC a.out files, instead of
returning -ENOEXEC.

Right now, I have a program /lib/dld which makes the appropriate calls to
ld to get it linked if it isn't already linked, and executes the right
linked image in anycase - but that will find its way into the kernel if
any one can convince me that dynamic linking is a Good Thing (tm).

When an OMAGIC file is encountered, it's file name is
passed as argv[argc] to /lib/dld. /lib/dld decides on a temporary filename
for it, equivalent to /exec/%04x/%04x:%08x, where the directory under
/exec is the device number, and filename device number : inode number,
providing a unique name for every executable. If this file exists,
it is run, otherwise ld is called with the right strings and drops a copy there,
which is then run.

The performance impact is negligible iff copies of the shared library stubs,
linker stub (crt0.o), /lib/dld and ld are in buffer cache for unlinked programs,
/lib/dld for linked programs.

Advantages :
- You don't have to get new binaries to fix any corrected library bugs.

- People can safely distributed everything as an OMAGIC file, which can
be run "out of the box" or statically linked to shared library stubs.

Disadvantages :
- If the shared library stubs, etc are not in buffer cache (this will be
rectified if we get an MFS) performance will be slow.

- You need disk to keep a linked version of the program around so you
can swap to it. Again, an MFS could rectify this,
but you are still using 100% extra disk / swap / memory someplace.

- If interfaces change to any library function, you are toasted.

- If the loaded copy isn't still around, everytime the program is run
you have the ld delay...

A MFS (memory based filesystem, as used in post Reno 4.3 BSD, like a ramdisk,
only it is pageable) on which /exec is mounted would increase swap requirements,
but eliminate the /exec disk space requirement, and a mfs file system sort of
acts like it has its own buffer cache - so your chances of having library
stubs, etc in core are greater and you don't have the performance problems
that come from loading those.

Any comments as to an MFS, how long to keep the linked image around for,
etc are welcome, as comments on weather the disk space needed for the
linked image of every program running (each program, not each instance)
around is worth it - this is what determines if I clean up the code and
make it public.

Bugs :
fork'ing and exec'ing a second OMAGIC program
from an OMAGIC program dumps core for some reason, should be easy to fix.

I have find | perl run every five minutes to clean up /exec,
and that needs to change to the kernel keeping track of activity in omagic
files, and deleting the linked version X minutes after the inode i_count
field reaches 0.....


[next article]
From: [email protected] (James Henrickson)

Subject: Re: gdb fails on ioctl??
Keywords: gdb ioctl
Message-ID: <[email protected]>
Date: 30 Apr 92 23:51:03 GMT
References: <[email protected]> <[email protected]
pool.info.sunyit.edu> <[email protected]>
Organization: State University of New York -- Institute of Technology
Lines: 27

In <[email protected]> [email protected] (Rob Hooft) writes:

>James: you were not running top at the same time in another session, were you?

Nope. I was using a version of ps/free/top that I had compiled under Linux
version 0.95a, I believe. After building pre-0.96, none of those three
programs ran properly. I tried updating the psdatabase file with no luck,
because /usr/src/linux/tools/system was missing. That was because I did a
"make clean" after compiling the kernel. Recompiling ps/free under pre-0.96
was easier, too, because I didn't have to patch the kernel. Everything works
OK now.

I learned a couple important lessons from that mess. First, don't do a
"make clean" after recompiling the kernel unless you really need to. Second,
after booting a new kernel, run "ps U" to update the psdatabase file. If
all else fails, THEN try recompiling ps/free.

Thanks to all that helped me with this matter. I've done system programming
and administration in the past, but I've never had to do installations like
this. The scary part is that I'm enjoying it! ๐Ÿ™‚


--
James L. Henrickson, Software Engineer * "machine learning for
Critical Technologies Inc. * autonomous vehicles, digital
311 Turner St Suite 303 * signal processing & parallel
Utica, NY 13501 [email protected] * computing"


[next article]
From: [email protected] (Douglas E. Quale)

Subject: fputs bug
Message-ID: <[email protected]>
Date: 3 May 92 00:07:54 GMT
Sender: [email protected] (The News)
Organization: Undergraduate Projects Lab, UW Madison
Lines: 15

I think this may have already been reported and I apologize if it has,
but I figured better safe than sorry.

fputs returns the number of characters written. It should return 0 on
success.

i.e.

fputs("foo", stdout)

returns 3 (should be 0).

--
Doug Quale
[email protected]


[next article]
From: [email protected] (david nugent)

Subject: Re: Suspending emacs and bringing it back
Message-ID: <[email protected]>
Date: 2 May 92 22:50:42 GMT
References: <[email protected]>
Reply-To: [email protected]
Organization: Unique Computing Pty Ltd, Melbourne, Australia
Lines: 28

[email protected] (Rajat Datta) writes:

> I'm not sure how this is a bash problem. What I think is happening is
> that when a process is woken up, the terminal is not being reset fully
> for that process group. Shells that support job control start off
> each new job as a new process group with a new control terminal (at
> least that's what the BSD internals books says). I presume, when you
> suspend the current job, you are setting the control terminal back for
> the shell, and therefore the terminal is the line discipline of the
> shell.

Gosh, this sounds familiar. I'm willing to bet that this is fixed
at the same time as the gdb TIOCSPGRP ioctl warning goes away. ๐Ÿ™‚


> What I'm going to try tonight is to (finally) look at the source code
> for Linux, and see if the line discipline is being saved at suspension
> and if it's being reset when bringing the job back to the foreground.
> If not, I'll write the code to do that and see what happens.

It might pay to wait for 0.96 to see if the problem persists.


..............................................................................
david nugent Public Access Usenet "Only Nixon could go to China"
[email protected] +61-3-792-3507 - old Vulcan proverb
3:632/[email protected], 58:4100/[email protected], 199:4242/[email protected], 33:300/[email protected]
PO Box 260, Endeavour Hills, Victoria, Australia, 3802.


[next article]
From: [email protected] (david nugent)

Subject: Re: linux mail
Message-ID:
Date: 2 May 92 22:58:17 GMT
References: <[email protected]>
Reply-To: [email protected]
Organization: Unique Computing Pty Ltd, Melbourne, Australia
Lines: 60

[email protected] writes:

> Did you have problems with the MAIL environment variable being set to
> /var/spool/mail/... rather than /usr/spool/mail/... I get this using bash &
> ash, think it must be set in the login stuff somewhere ??? ... hmmmm

I simply set it explicitly using /etc/profile, which I did when I first
noticed this long before I had a mail system installed.

i.e. (in "/etc/profile")

MAIL=/usr/spool/mail/$LOGNAME
.
.
export MAIL


> Do you have your /etc/passwd entries set to give the "real" name ? I set min
> to :& Kew, ... : but my username is not substituted for the &. I thought elm
> would do this ?

I used standard SYSV conventions and configured everything to use that.
Many programs have other methods of doing this including looking at
~/.fullname, a /usr/lib/fullnames database and a FULLNAME environment
variable, but I prefer getting it from /etc/passwd, even if it does
limit the amount of fun users tend to play. ๐Ÿ™‚


> ... I used the suggested lmail sh script from the uucp stuff
> the problem may be that. hmmm... perhapse I'm just showing my ignorance here
> ๐Ÿ™ I also find I get the message header dilivered (minus subject field) & n
> message !

I didn't feel comfortable with a script either.


> I'm currently using ka9q to talk to the world via SLIP & can recieve smtp mai
> but with no sendmail I can't get mail out (ie I need something to take an elm
> message & sling the requisite stuff round it for ka9q to send) I've seen man
> requests for a sendmail port - has anyone done this ?

smail 3.1.25 works just fine for me and does this just fine. I haven't
yet done a lot of work with the ported uucp package yet (not after I found
that it falls over dismally at PEP speeds due to driver/kernel problems)
but it gets into the uucp queue just fine.

> The code (BSD) is real designed for use with an ethernet connection +
> sockets as far as I can tell, maybee I really need something else ?

Sendmail is pretty much transport independant. It is less intuitive to
configure and run than is smail, and although my experience with smail
3.1 is limited to working under Linux, I'm pretty impressed by it so
far and I haven't begun to explore the possibilities (yet).


..............................................................................
david nugent Public Access Usenet "Only Nixon could go to China"
[email protected] +61-3-792-3507 - old Vulcan proverb
3:632/[email protected], 58:4100/[email protected], 199:4242/[email protected], 33:300/[email protected]
PO Box 260, Endeavour Hills, Victoria, Australia, 3802.


[next article]
From: [email protected]

Subject: I need a little help with color.
Message-ID: <[email protected]>
Date Public Access Usenet "Only Nixon could go to China"
[email protected] +61-3-792-3507 - old Vulcan proverb
3:632/[email protected], 58:4100/[email protected], 199:4242/[email protected], 33:300/[email protected]
PO Box 260, Endeavour Hills, Victoria, Australia, 3802.


[next article]
From: [email protected]

Subject: I need a little help with color.
Message-ID: <[email protected]>
Datehe codes to use for the
colors. If you can help me I would appreciate it. Please e-mail. ๐Ÿ™‚
Thanks in advance,
Jim gifford [email protected]


[next article]
From: [email protected] (Rik Faith)
Newsgroups: comp.os.linux,alt.os.linux

Subject: Re: schedule for upgrades and the Summer [was Re: Upgrades to OS]
Message-ID: <[email protected]>
Date: 1 May 92 11:57:25 GMT
References: <[email protected]>he codes to use for the
colors. If you can help me I would appreciate it. Please e-mail. ๐Ÿ™‚
Thanks in advance,
Jim gifford [email protected]


[next article]
From: [email protected] (Rik Faith)
Newsgroups: comp.os.linux,alt.os.linux

Subject: Re: schedule for upgrades and the Summer [was Re: Upgrades to OS]
Message-ID: <[email protected]>
Date: 1 May 92 11:57:25 GMT
References: <[email protected]>r since I expect to have more time to hack on linux (just
research, no classes, and a full connection to the internet). I've been
looking at the situation in a totally different way: I expect a *great*
deal of work to be accomplished during the summer ๐Ÿ™‚

--
Rik Faith: [email protected]
Paradox is the question of Chaos.


[next article]
From: [email protected] (Default Account)

Subject: Software index -- r since I expect to have more time to hack on linux (just
research, no classes, and a full connection to the internet). I've been
looking at the situation in a totally different way: I expect a *great*
deal of work to be accomplished during the summer ๐Ÿ™‚

--
Rik Faith: [email protected]
Paradox is the question of Chaos.


[next article]
From: [email protected] (Default Account)

Subject: Software index -- r since I expect to have more time to hack on linux (just
research, no classes, and a full connection to the internet). I've been
looking at the situation in a totally different way: I expect a *great*
deal of work to be accomplished during the summer ๐Ÿ™‚

--
Rik Faith: [email protected]
Paradox is the question of Chaos.


[next article]
From: [email protected] (Default Account)

Subject: Software index -- ul (my opinions only since I can't
imagine not having a full emacs installation) should be out by
midweek, next weekend (May 9) at the latest.

Bill


[next article]
From: [email protected] (Giles D Malet)

Subject: Re: uucico death
Message-ID: <[email protected]>
Date: 30 Apr 92 10:56:35 GMT
References: <[email protected]>
Reply-To: [email protected] (Giles D Malet)
Organization: You gotta be kidding !
Lines: 73

In article <[email protected]>
[email protected] (Steve Robbins) writes:

>I thought I had Taylor uucp working [...]
>suddenly it didn't work anymore, uucico would die horribly with
>the dreaded general protection 0000 message right after completing the
>handshake.

>Has anyone else noticed (or more importantly corrected) this behaviour?

Um, yes. Um, no.

>The problem seems to be when I have more than one work file waiting to
>go. One at a time is no problem.

You got it. Problem manifests itself in `sys4.c', which comes from
`sys4.unx'. If there is more than one file queued to go out for a
particular site, a list is built of the file names, and qsort()ed,
to get highest grade (priority) stuff to the top.
Then, sometime later......bsearch() is used to hunt around the list,
and therein lies the fault; and it's a beauty.

qsort & bsearch require passing a pointer to a function that does the
comparison part, and in this file it is a function 1 line long (can't
remember the name, but it ends in ..compar or comp) that uses strcmp().
I suspected strcmp was failing, so split up that line & put printf's
above & below the strcmp. Sure enough, *sometimes* strlen did not
return due to GP fault. I checked the source to strlen, looked okay,
& checked the parms passed to strlen - okay.

I then backed up a bit, as qsort does not fail, & began to suspect
bsearch(). In the source to bsearch I put a printf of the address
of the compare function just before it is called, and another printf
right after the return, also leaving a printf as the 1st & last lines
of the compare function.

So, if you are still with me, a typical sequence should output something
like the following :

qsort: calling 0x1234
compare: comparing 4,5 bytes
compare: done
qsort: compare returned

and so on. Now the thot plickens. I get the above sequence correctly twice,
and then :

qsort: calling 0x1234

and a GP exception.

This is odd - it looks as though the compare function was never called,
(no printf), although the address is the same as the previous 2 invocations.

As I write this, one thought occurs to me - perhaps the printf (or strcmp
if printf not there) is getting passed a duff pointer to a string.
I will go and check just now - perhaps you could try the same.
If that is what is happening, this smacks of a fencepost error.
Actually, the more I think of this, the more I am convinced that is the
problem - unfortunately I am running another os at the moment, so need
to reboot etc to check. More later.

I have compiled this with & without -O, with & without -static.
No change. GCC 2.1, linux 0.95c.

What is a `0000' GP ? Hopefully it is a read of mem with no permission.
That would confirm my musings. If it's a write...

BTW, you can test this by making tstuu & running that. Does not need
a connection, so won't upset your upstream site. Just remove /tmp/tstuu
when done - it leaves lots of rubbish in there after a bomb.

[ Many hours later :
[ Forget this - this is caused by a bug in bsearch() - s


[next article]
From: [email protected] (Giles D Malet)

Subject: Bug in bsearch()
Message-ID: <[email protected]>
Date: 30 Apr 92 14:40:29 GMT
Reply-To: [email protected] (Giles D Malet)
Organization: You gotta be kidding !
Lines: 31

Checking the source code for bsearch() reveals that is accepts a parm
giving the length of the list to be searched as a `size_t' item.
It then promptly subtracts 1 from that, to be used as a counter to
limit a loop.

However, size_t is unsigned, and we all know what happens when you
subtract 1 from 0 in an unsigned int. So passing an empty list to
bsearch causes it to go wild - this is what is causing Taylor uucico
to crash when there is a queue of jobs to go out.

Fix below :

-----cut-----
*** bsearch.c.BUG Thu Apr 30 05:10:31 1992
--- bsearch.c Thu Apr 30 05:12:39 1992
***************
*** 32,37 ****
--- 32,39 ----
register CONST PTR p;
register int comparison;

+ if (!nmemb) return NULL;
+
l = 0;
u = nmemb - 1;
while (l <= u)
-----cut-----

BTW, I check the related qsort() - it is okay.
--
Giles D Malet [email protected] Waterloo, Ont, Canada +1 519 725 5726


[next article]
From: [email protected] (Matt Mosley)

Subject: UUCP
Message-ID:
Date: 2 May 92 21:43:34 GMT
Organization: Starnet BBS
Lines: 10

Hey all. I downloaded Taylor UUCP 1.03 from tsx-11, and installed it. I
am having a problem, though. When I type 'uucp system~/files files', it
says "cannot write to /whatever" no matter what directory I am in. I
setup the Systems file (system is the name of the host I use) and Devices,
is the line uucp system~file localfile right? This error is making no
sense whatsoever to me...

-----------------------------------------------------------------------------
Matt Mosley (Shadow) | Systems manager of Starnet BBS and
[email protected] | programmer for Starcom Software


[next article]
From: [email protected] (lhanson)

Subject: Questions from a novice
Message-ID: <[email protected]>
Date: 3 May 92 13:00:24 GMT
Sender: [email protected]
Organization: University of Vermont -- Division of EMBA Computer Facility
Lines: 38


I'm very new (circa 1 week) to the Unix OS and have Linux running on
my 386sx 20 (2 MB + w/4 MB swap file). Due to the 2 MB RAM limitation I
couldn't use the MCC release and installed the 0.95c+ rootimage. Once I
had the system running I used the MCC releases comp.image and comp2.image
install files to install GCC 2.1. Now my questions:

1) When I trie to run kermit everything appears fine but the dial command
won't work (times out) and if I 'connect' and issue the AT commands directly
they work (I can here the modem dial) but I don't get a screen display of
the incomming (or outgoing for that matter) characters.

2) All my attempts to complie "Hello world." result in a segmentation
error. When I attempt to compile the port : ps095c+ it results in a
memory fault; However, the compilation process appears to abort.

3) I am using microEMACS and have had no trouble getting it to run. How
do I tell it where I have the *.cmd files located? I don't have any idea
how to set and/or use environmental variables.

4) What's the secret to allow users access to files? I would like to
keep some commands restricted to root but how, for example, can I fix
it so users can use mtools? I followed the example in passwd and set
the group and user numbers to 8 and 3 (as shown for ast).

I hope I got most of the details right in my questions. I have to
keep reverting to DOS to access kermit for communications and by the
time I've made the switch my memory has gone fuzzy.

Thanks for any help. BTW I have read the FAQ and Chuck Boyer's guide
which is why I've gotten as far as I have. Kudo's to all who have
devoted their time to this effort.

Lee Hanson
University of Vermont
[email protected]
.
k


[next article]
From: [email protected] (Joel M. Hoffman)

Subject: communications only work up to 4800 baud. Why?
Message-ID: <[email protected]>
Date: 3 May 92 14:08:44 GMT
Sender: [email protected] (USENET News system)
Organization: University of Maryland at College Park
Lines: 13
Nntp-Posting-Host: rac2.wam.umd.edu

I'm using kermit on an old 286 to connect to Linux via a serial line.
The Linux machine is a 386 with 6M and nothing else running (except
several getty's). But as soon as I go above 4800 baud (9600, e.g.), I
start getting transmission errors? Has anyone else had this problem,
or, better yet, solved it?

The problem does NOT lie in the comm ports or the cable. I use the
same setup with Laplink which runs MUCH MUCH faster (112,000 ish?).

Suggestions? Please!

-Joel
([email protected])


[next article]
From: [email protected] (Werner Almesberger)

Subject: Experimental polling serial lines driver
Message-ID: <[email protected]>
Date: 3 May 92 16:39:11 GMT
Sender: [email protected] (USENET News System)
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Lines: 136

I've written a little experimental serial lines driver that solves
the interrupt sharing problem when using more than two ports. It
does this by polling the UARTs at a regular interval instead of
waiting for interrupts.

How it works: additional timer interrupts are generated and on
each interrupt all active serial ports are checked for new data
or whether more data can be sent on them. All other routines that
depend on timer interrupts are called at the usual rate (HZ).

This approch has the following advantages:
- UARTs don't have to generate interrupts.
- the interrupt rate is limited.
- the code is much simpler.
- hardware-handshake is trivial to implement.

Unfortunately, there are some disadvantages:
- some CPU time (usually > 5%, depending on CPU type, clock,
etc.) is wasted.
- turn-around times are slightly increased.

The current implementation adds some additional disadvantages,
like hard-coding of the highest baud rate in the kernel.

Modified files:

kernel/chr_drv/serial.c new polling driver
kernel/sched.c support for sub-jiffies
kernel/sys_call.S removed counting of jiffies

The number of additional timer interrupts is controlled by SPEED_UP
in sched.c. The minimum value of SPEED_UP is max_bps/1000, where
max_bps is the highest baud rate that has to be supported.

Increasing the value of SPEED_UP makes the driver less sensitive to
interrupt latency but makes the entire system slower and may cause
interrupt latency problems for other devices.

I'm using a value of 6 for reliable operation at 4800 bps on a loaded
386DX/25 and a value of 10 for sometimes unreliable operation at 9600
bps on an otherwise idle system. A 386DX/33 or a 486 may have enough
power to achieve reliable operation at 9600 bps (or maybe even 19200
bps) with higher speed-up values.

A possible source of problems might be the choice of UART base addres-
ses. The kernel uses 3f8,2f8,3e8,2e8. My PC has them at 3f8,2f8,2e8,
2e0. Others may use yet another set of addresses. They're defined in
kernel/chr_drv/tty_io.c.

This driver is experimental and hasn't been tuned for performance. I
wouldn't recommend it for regular use. However, if the UARTs support
hardware queues (e.g. 16550A), the SPEED_UP value might be lowered
so much that the waste of CPU time becomes neglegible. Using such
features will require some changes to the driver.

Known problems:

Setting big SPEED_UP values will crash the system.

Accessing non-existent serial devices may create endless streams
of pseudo data and slow the system. (The driver tries to detect
this.)

DSR detection may hang a serial line if it fails.

There have been occasional lockups. Don't know whether they are
still there. Opening the same port from another process seems to
resolve the problem.

A uuencoded tar.Z file with the necessary changes to the pre-0.96
kernel source is appended to this message.

- Werner

------------------------------ cut here ------------------------------

begin 644 serial.n.tar.Z
M'YV0<\K(21.&C8LQ`!(J7,BPH<.'$"-*[email protected]`(B+-FC0`&'QXD48'#U^#"GR
MXHP;,VQ4,G
MZ$.E3)U*G4JUJM6K6'F^4*$`A(J+;-*XJ8/GQ1J!;LJP>1%P8,EZO2BE
M#!PV8<:4F0-"+!V![email protected](18L>PJ4.F#`@>F,F^H$,GCPLT/CR#=B.:M&D>8>:T89N':)DVKV//KEWZ
M=.[=:=X$]_RYM!FQIHTDD3*%RIMRQLXB4'T``&#Q="]7\C,[email protected][F=KR1!AGIN<6&>_"[email protected](=;LR1QAEI$>@7
M")B5D8(">W3ET81BY%;&?QI>U&%`\H'`6AY?%"4&&V5L4>$*TE%G'7;:<=>%
M"W*4$0897\[email protected]@]DB!?&?R*E808(*(@EQA=PH#!B&2O4D()\_>%AAAE3YDA'
M'7*X0:1'[email protected]?7O1&'70LV>0,+#[email protected]@C"F6DRB<(-;7JX`@UQ%NF&
MFDYZV*='][6G'W](%IK??B"8`((?*-#$`P\40I?"E'[email protected]:2=;MHPI:,PX-$2
M"#^`("FE%8*@@YP?#7H146*Z6N!Z[;T7'Q_SG5II6O_U`:"`!#)6$).6L8%"
[email protected]`->F*%(1`4V!GHG]EA'&=-ZE>..TE);[email protected]#'07]E.6Z9YT+;&0ANYK9%G
M0"R$M^4<+)@QVAQHL'!'&&>-.P8:[email protected]'&B7&,*X9;QR%PHDEQEC=
M==EMQ\0.)[email protected]@[email protected]=RLX(07$-3(Q!<4GKK#"E!DF8"22;=&*8'R."KP&
[email protected](-*U/,8Q;;7S1:LBBUN<>"/./?YGLT?>[email protected]&NSMJ6Z',8*[8HM`M)+VVT
M2$^62#33T_X89%%7>R3O4&B4>.]9)?I7LTA;^1O6F!2KT-G1%]V!1AHL(HF"
[email protected]`45Y::.FTIR`RD>B8$053#"!PM8[6SBE&->N870"4%1!Q1!()/DG
MIX*R`+FV<1X^-KT%AWV1KW2#8#?>INU=U+N$A][email protected]*3/ABAYZX>%%)AZ"
MYX!V^BE]HL(P..4Z6EYS[[email protected]&2!0M5EA"MY9)5??D01FW>.O?8L[%MZ
M`G0"NN^Z%EY^MFFY7LXW7_/][::4JH/`>O!(OM^[email protected]&H<+UO98]K%@*!
M#T`@@QIXZGGO^X)@4&""\2'P1W!0RAB^$!:BE(Y_*#@=&G!'A>I]00I%"`(1
MOF`$)E1A"IU[6M16<*+SA0EN:_/(_CS2-EC!S2MS8]WN5C`?F8W+5[[R#+((
M)(?VB$5IQP*6LN0TH1.Q#V!B2QB2&#:?C(%,8B2S&*6\2".)=>QC9>3.R"J6
M!Y--"00IRUK/6I,BJ`%M:EOSFI",[email protected]@)!"*IT)<.))'UV"A4.ZN,F
M..4/D4T*U0P8*:A'[email protected]`Q<##[[email protected]$V-Y*29+IE(]NU)E',B921-NMO2YO?FS2_8ZW220M<4J;DF4E:^8KD2#Q5P,"[email protected]#W9.:M<*&I6'9[EE1IB
M2$XWE%4?I4<]ZYWH1Q8<7`0G:()K^L""[email protected]!]E#!UGY,$Z^[email protected]#YK"O,I#!
M!60PDAG42<^L>"0C&^F(1T"BSY'TTR,QH`$,5`("[email protected]$)C(AZ$MND!&=U/.A
M$!5*>(["$:@TY2H6C:A&-\K1CEI%!2`%P0O,0(87I*8L9^F26MC2SG>.(0%-
M>([email protected]!!!H(DH#JH`0YT,!-3Y2`',E!`"X8JTJ'(P:1B44U*T[(6=J+!G0=)
MP!08!((FA&$R()@!?6"@`Y=TM08^!:H"0$K6LIJ5*V0M*`U88`.0E%5#ATL`
MO=YPASH.+$DL*,K`MI"[email protected]!00`A`,`+G0`<$3`A"^)`TDQS,(`:+?`$2
MM'"ABVBH#'CX2Y=`[email protected](%)/U):$2M09KM0%-ACI4N!YNKG75ZQKP
M*EN^^[email protected]!4L80V;%A!,`0I%*,(*JP`%[^BVL&5X3F\3N]A(Q<"QD(6!9+7P
[email protected]\&=[[email protected]+X)9S2JFLY]M0VC+,%HR#&JL9TTO6D,[email protected]@@`4SH`%8W\K:
MK,[email protected]!_!%+0A8VP(-::BS9'A#[email protected]@`TR/8._[J+=#D!&=U/.A
M$!5*>(["$:@TY2H6C:A&-\K1CEI%!2`%P0O,0(87I*8L9^F26MC2SG>.(0%-
M>([email protected]!!!H(DH#JH`0YT,!-3Y2`',E!`"X8JTJ'(P:1B44U*T[(6=J+!G0=)
MP!08!((FA&$R()@!?6"@`Y=TM08^!:H"0$K6LIJ5*V0M*`U88`.0E%5#ATL`
MO=YPASH.+$DL*,K`MI"[email protected]!00`A`,`+G0`<$3`A"^)`TDQS,(`:+?`$2
MM'"ABVBH#'CX2Y=`[email protected](%)/U):$2M09KM0%-ACI4N!YNKG75ZQKP
M*EN^^[email protected]!4L80V;%A!,`0I%*,(*JP`%[^BVL&5X3F\3N]A(Q<"QD(6!9+7P
[email protected]\&=[[email protected]+X)9S2JFLY]M0VC+,%HR#&JL9TTO6D,[email protected]@@`4SH`%8W\K:
MK,[email protected]!_!%+0A8VP(-::BS9'A#[email protected]@`TR/8._[J+=#D!&=U/.A
M$!5*>(["$:@TY2H6C:A&-\K1CEI%!2`%P0O,0(87I*8L9^F26MC2SG>.(0%-
M>([email protected]!!!H(DH#JH`0YT,!-3Y2`',E!`"X8JTJ'(P:1B44U*T[(6=J+!G0=)
MP!08!((FA&$R()@!?6"@`Y=TM08^!:H"0$K6LIJ5*V0M*`U88`.0E%5#ATL`
MO=YPASH.+$DL*,K`MI"[email protected]!00`A`,`+G0`<$3`A"^)`TDQS,(`:+?`$2
MM'"ABVBH#'CX2Y=`[email protected](%)/U):$2M09KM0%-ACI4N!YNKG75ZQKP
M*EN^^[email protected]!4L80V;%A!,`0I%*,(*JP`%[^BVL&5X3F\3N]A(Q<"QD(6!9+7P
[email protected]\&=[[email protected]+X)9S2JFLY]M0VC+,%HR#&JL9TTO6D,[email protected][email protected]@`4SH`%8W\K:
MK,[email protected]!_!%+0A8VP(-::BS9'A#[email protected]@`TR/8._[J+=#D!&=U/.A
M$!5*>(["$:@TY2H6C:A&-\K1CEI%!2`%P0O,0(87I*8L9^F26MC2SG>.(0%-
M>([email protected]!!!H(DH#JH`0YT,!-3Y2`',E!`"X8JTJ'(P:1B44U*T[(6=J+!G0=)
MP!08!((FA&$R()@!?6"@`Y=TM08^!:H"0$K6LIJ5*V0M*`U88`.0E%5#ATL`
MO=YPASH.+$DL*,K`MI"[email protected]!00`A`,`+G0`<$3`A"^)`TDQS,(`:+?`$2
MM'"ABVBH#'CX2Y=`[email protected](%)/U):$2M09KM0%-ACI4N!YNKG75ZQKP
M*EN^^[email protected]!4L80V;%A!,`0I%*,(*JP`%[^BVL&5X3F\3N]A(Q<"QD(6!9+7P
[email protected]\&=[[email protected]+X)9S2JFLY]M0VC+,%HR#&JL9TTO6D,[email protected]@@`4SH`%8W\K:
MK,[email protected]!_!%+0A8VP(-::BS9'A#[email protected]@`TR/8._[J+=#D!&=U/.A
M$!5*>(["$:@TY2H6C:A&-\K1CEI%!2`%P0O,0(87I*8L9^F26MC2SG>.(0%-
M>([email protected]!!!H(DH#JH`0YT,!-3Y2`',E!`"X8JTJ'(P:1B44U*T[(6=J+!G0=)
MP!08!((FA&$R()@!?6"@`Y=TM08^!:H"0$K6LIJ5*V0M*`U88`.0E%5#ATL`
MO=YPASH.+$DL*,K`MI"[email protected]!00`A`,`+G0`<$3`A"^)`TDQS,(`:+?`$2
MM'"ABVBH#'CX2Y=`[email protected](%)/U):$2M09KM0%-ACI4N!YNKG75ZQKP
M*EN^^[email protected]!4L80V;%A!,`0I%*,(*JP`%[^BVL&5X3F\3N]A(Q<"QD(6!9+7P
[email protected]\&=[[email protected]+X)9S2JFLY]M0VC+,%HR#&JL9TTO6D,[email protected]@@`4SH`%8W\K:
MK,[email protected]!_!%+0A8VP(-::BS9'A#[email protected]@`TR/8._[J+=#;
> timeout.tv_usec = usec - 1000000 * timeout.tv_sec;
> select(1, NULL, NULL, NULL, &timeout);
>}


[next article]
From: [email protected] (H. Peter Anvin N9ITP)

Subject: Re: tar, compress, or just my system?
Message-ID: <[email protected]>
Date: 3 May 92 19:22:59 GMT
References: <[email protected]>
Reply-To: [email protected] (Peter Anvin)
Organization: Northwest;
> timeout.tv_usec = usec - 1000000 * timeout.tv_sec;
> select(1, NULL, NULL, NULL, &timeout);
>}


[next article]
From: [email protected] (H. Peter Anvin N9ITP)

Subject: Re: tar, compress, or just my system?
Message-ID: <[email protected]>
Date: 3 May 92 19:22:59 GMT
References: <[email protected]>
Reply-To: [email protected] (Peter Anvin)
Organization: Northwest;
> timeout.tv_usec = usec - 1000000 * timeout.tv_sec;
> select(1, NULL, NULL, NULL, &timeout);
>}


[next article]
From: [email protected] (H. Peter Anvin N9ITP)

Subject: Re: tar, compress, or just my system?
Message-ID: <[email protected]>
Date: 3 May 92 19:22:59 GMT
References: <[email protected]>
Reply-To: [email protected] (Peter Anvin)
Organization: Northwest;
> timeout.tv_usec = usec - 1000000 * timeout.tv_sec;
> select(1, NULL, NULL, NULL, &timeout);
>}


[next article]
From: [email protected] (H. Peter Anvin N9ITP)

Subject: Re: tar, compress, or just my system?
Message-ID: <[email protected]>
Date: 3 May 92 19:22:59 GMT
References: <[email protected]>
Reply-To: [email protected] (Peter Anvin)
Organization: NorthwestFrom: [email protected] (A. V. Le Blanc)

Subject: Re: termcap/gcc2.1-problems
Keywords: termcap gcc2.1 libs libraries undefined symbol
Message-ID: <[email protected]>
Date: 3 May 92 14:28:25 GMT
References: <[email protected]>
Followup-To: [email protected]
Organization: Computing Centre, University of Manchester
Lines: 25

In article <[email protected]> [email protected] (Michael Lipka) writes:
>I'm trying to get Linux 0.95c+ running on a 25MHz 386DX using the
>Manchester-release (very easy to install and small because of
>``shared-libs'' binaries) with gcc2.1.
....
>But when all should be linked together
>gcc complains about undefined symbols of termcap (tput, tget-
>str...)
....
>Could someone please give me a hint what I'm doing wrong?
>
>This comes out of make:
....
>cc -lcurses -ltermcap -o ../bin/elm addr_util.o alias.o aliasdb.o
....

I think the problem is the way -ltermcap is specified in the Makefile.
Usually gcc seems to require something like this:

cc -o ../bin/elm addr_util.o alias.o aliasdb.o .... -lcurses -ltermcap

Does the problem persist if you change it this way?

-- Owen
[email protected]


[next article]
From: [email protected] (A. V. Le Blanc)

Subject: Re: Questions from a novice
Message-ID: <[email protected]>
Date: 3 May 92 17:46:02 GMT
References: <[email protected]>
Followup-To: [email protected]
Organization: Computing Centre, University of Manchester
Lines: 34

In article <[email protected]> [email protected] (lhanson) write
s:
>I'm very new (circa 1 week) to the Unix OS and have Linux running on
>my 386sx 20 (2 MB + w/4 MB swap file). Due to the 2 MB RAM limitation I
>couldn't use the MCC release and installed the 0.95c+ rootimage. Once I
>had the system running I used the MCC releases comp.image and comp2.image
>install files to install GCC 2.1.

It is for this reason that I provided the image xdisk.Z in
mcc-interim/0.95c+/images (available by anonymous ftp from either
ftp.mcc.ac.uk or banjo.concert.net). This image together with a
conventional boot image for 0.95c+ (not the mcc-interim boot) can be used
to install the MCC 'interim' version. Instructions for doing this can be
found in the README file in the images directory. Incidentally, the
'standard' MCC version has been installed (with some problems) on some
2mb systems; this suggests that the size of RAMDISK used brings memory
usage to very near the limit. Perhaps next time I'll be able to get the
root ramdisk a little smaller.

>2) All my attempts to complie "Hello world." result in a segmentation
>error. When I attempt to compile the port : ps095c+ it results in a
>memory fault; However, the compilation process appears to abort.

This is probably because compilation by default links with the shared
library. These files cannot execute without the /lib/lib92.04.06 file,
which is installed from the MCC 'interim' root disk (ramdisk). The
'interim' version of Linux is not designed for this kind of use; if
you have not installed Linux using its boot and utilities disk, you
are likely to have trouble with the software on its other disks.
The utilities currently available on the comp and comp2 disks are all
taken from elsewhere (and the sources acknowledged in various README
files).

-- Owen
[email protected]


[next article]
From: [email protected] (Hien Luu)

Subject: Help Installing GCC 2.1
Message-ID: <[email protected]>
Date: 3 May 92 17:33:12 GMT
Distribution: usa
Organization: Station Zebra Corp, Sunnyvale CA Ph:408-739-1520
Lines: 6


After I successfully tarred file 2.1misc, and 2.1lib, then I am
supposed to run the inst2.x script. However when I type inst2.x,
I got an erro message saying inst2.x:file not found.

Did I miss something...please help...


[next article]
From: [email protected] (Allan Adler)

Subject: volunteers wanted
Message-ID:
Date: 4 May 92 05:16:57 GMT
Sender: [email protected]
Distribution: comp
Organization: M.I.T. Artificial Intelligence Lab.
Lines: 810


I do not have Linux on my machine and cannot install it in the near future.

I am interested in knowing whether a certain piece of public domain software
will run on Linux. It seems to take up about 20 MB when it is installed,
if one includes all of the libraries and tables and documentation,
but that can probably be cut down substantially for testing purposes.

I think the distributors of this software would like to know the answer
too. There is an electronic mailing list for it that one could announce
the results on, as well as on sci.math.symbolic.

The software is a certain computer algebra package called GAP.

If you would like to try this out, please let me know. GAP is distributed
by a research group in Aachen, Germany and is available for free
by anonymous ftp. I enclose the original announcement I received from
the distributors of GAP. It has a lot of information about the package,
including where to get it by anonymous ftp.


Allan Adler
[email protected]

===========================================================================

Subject: Announcement of GAP 3.1

Introduction
============

GAP is a system for computational discrete algebra, which we have
developed with particular emphasis on computational group theory, but
which has already proved useful also in other areas. The name GAP is an
acronym for *Groups, Algorithms, and Programming*. This (long) document
announces the availability of GAP version 3 release 1, GAP 3.1 for short.
It is an *advertisement* for GAP, but not a *commercial*, since we give
GAP away for free.
GAP is a system for computational discrete algebra, which we have
developed with particular emphasis on computational group theory, but
which has already proved useful also in other areas. The name GAP is an
acronym for *Groups, Algorithms, and Programming*. This (long) document
announces the availability of GAP version 3 release 1, GAP 3.1 for short.
It is an *advertisement* for GAP, but not a *commercial*, since we give
GAP away for free.
GAP is a system for computational discrete algebra, which we have
developed with particular emphasis on computational group theory, but
which has already proved useful also in other areas. The name GAP is an
acronym for *Groups, Algorithms, and Programming*. This (long) document
announces the availability of GAP version 3 release 1, GAP 3.1 for short.
It is an *advertisement* for GAP, but not a *commercial*, since we give
GAP away for free. Heureusement!
(A. Camus, La chute)


######## Lehrstuhl D fuer Mathematik
### #### RWTH Aachen
## ##
## # ####### #########
## # ## ## # ##
## # # ## # ##
#### ## ## # # ##
##### ### ## ## ## ##
######### # ######### #######
# #
## Version 3 #
### Release 1 #
## # 7 Apr 92 #
## #
## # #### ## ## # # ##
##### ### ## ## ## ##
######### # ######### #######
# #
## Version 3 #
### Release 1 #
## # 7 Apr 92 #
## #
## # #### ## ## # # ##
##### ### ## ## ## ##
######### # ######### #######
# #
## Version 3 #
### Release 1 #
## # 7 Apr 92 #
## #
## #s proudly announcing
that they've sold more than 120 hamburgers.
(J. A. Paulos, Innumeracy)

To show you what GAP can do a short example is probably best. If you are
not interested in this example skip to the section "An Overview of GAP".

For the example we consider the group of transformations of Rubik's magic
cube. If we number the faces of this cube as follows

+--------------+
| 1 2 3 |
| 4 top 5 |
| 6 7 8 |
+--------------+--------------+--------------+--------------+
| 9 10 11 | 17 18 19 | 25 26 27 | 33 34 35 |
| 12 left 13 | 20 front 21 | 28 right 29 | 36 rear 37 |
| 14 15 16 | 22 23 24 | 30 31 32 | 38 39 40 |
+--------------+--------------+--------------+--------------+
| 41 42 43 |
| 44 bottom 45 |
| 46 47 48 |
+--------------+

then the group is generated by the following generators, corresponding
to the six faces of the cube (the two semicolons tell GAP not to print
the result, which is identical to the input here).

gap> cube := Group(
> ( 1, 3, 8, 6)( 2, 5, 7, 4)( 9,33,25,17)(10,34,26,18)(11,35,27,19),
> ( 9,11,16,14)(10,13,15,12)( 1,17,41,40)( 4,20,44,37)( 6,22,46,35),
> (17,19,24,22)(18,21,23,20)( 6,25,43,16)( 7,28,42,13)( 8,30,41,11),
> (25,27,32,30)(26,29,31,28)( 3,38,43,19)( 5,36,45,21)( 8,33,48,24),
> (33,35,40,38)(34,37,39,36)( 3, 9,46,32)( 2,12,47,29)( 1,14,48,27),
> (41,43,48,46)(42,45,47,44)(14,22,30,38)(15,23,31,39)(16,24,32,40)
> );;

First we want to know the size of this group.

gap> Size( cube );
43252003274489856000

Since this is a little bit unhandy, let us factorize this number.

gap> Collected( Factors( last ) );
[ [ 2, 27 ], [ 3, 14 ], [ 5, 3 ], [ 7, 2 ], [ 11, 1 ] ]

(The result tells us that the size is 2^27 3^14 5^3 7^2 11.)

Next let us investigate the operation of the group on the 48 points.

gap> orbits := Orbits( cube, [1..48] );
[ [ 1, 3, 17, 14, 8, 38, 9, 41, 19, 48, 22, 6, 30, 33, 43, 11, 46,
40, 24, 27, 25, 35, 16, 32 ],
[ 2, 5, 12, 7, 36, 10, 47, 4, 28, 45, 34, 13, 29, 44, 20, 42,
26, 21, 37, 15, 31, 18, 23, 39 ] ]

The first orbit contains the points at the corners, the second those at
the edges; clearly the group cannot move a point at a corner onto a point
at an edge.

So to investigate the cube group we first investigate the operation on
the corner points. Note that the constructed group that describes this
operation will operate on the set [1..24], not on the original set
[1,3,17,14,8,38,9,41,19,48,22,6,30,33,43,11,46,40,24,27,25,35,16,32].

gap> cube1 := Operation( cube, orbits[1] );
Group( ( 1, 2, 5,12)( 3, 7,14,21)( 9,16,22,20),
( 1, 3, 8,18)( 4, 7,16,23)(11,17,22,12),
( 3, 9,19,11)( 5,13, 8,16)(12,21,15,23),
( 2, 6,15, 9)( 5,14,10,19)(13,21,20,24),
( 1, 4,10,20)( 2, 7,17,24)( 6,14,22,18),
( 4,11,13, 6)( 8,15,10,17)(18,23,19,24) )
gap> Size( cube1 );
88179840

Now this group obviously operates transitively, but let us test whether
it is also primitive.

gap> corners := Blocks( cube1, [1..24] );
[ [ 1, 7, 22 ], [ 2, 14, 20 ], [ 3, 12, 16 ], [ 4, 17, 18 ],
[ 5, 9, 21 ], [ 6, 10, 24 ], [ 8, 11, 23 ], [ 13, 15, 19 ] ]

Those eight blocks correspond to the eight corners of the cube; on the
one hand the group permutes those and on the other hand it permutes the
three points at each corner cyclically.

So the obvious thing to do is to investigate the operation of the group
on the eight corners.

gap> cube1b := Operation( cube1, corners, OnSets );
Group( (1,2,5,3), (1,3,7,4), (3,5,8,7),
(2,6,8,5), (1,4,6,2), (4,7,8,6) )
gap> Size( cube1b );
40320

Now a permutation group of degree 8 that has order 40320 must be the full
symmetric group S(8) on eight points.

The next thing then is to investigate the kernel of this operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
s operation on
blocks, i.e., the subgroup of 'cube1' of those elements that fix the
blocks setwise.

gap> blockhom1 := OperationHomomorphism( cube1, cube1b );;
gap> Factors( Size( Kernel( blockhom1 ) ) );
[ 3, 3, 3, 3, 3, 3, 3 ]
gap> IsElementaryAbelian( Kernel( blockhom1 ) );
true

We can show that the product of this elementary abelian group 3^7 with
the S(8) is semidirect by finding a complement, i.e., a subgroup that has
ows away objects that are no longer accessible.

The GAP programming language supports a number of datatypes for elements
of fields. *Integers* can be arbitrarily large, and are implemented in
such a way that operations with small integers are reasonably fast.
Building on this large-integer arithmetic GAP supports *rationals* and
elements from *cyclotomic fields*. Also GAP allows one to work with
elements from *finite fields* of size (at present) at most 2^16.

The special datatypes of group elements are *permutations* (currently
operating on at most 2^16 points, but we are going to remove this
restriction soon), *matrices* over the rationals, cyclotomic fields, and
finite fields, *words in abstract generators*, and *words in solvable
groups*.

GAP also contains a very flexible *list* datatype. A list is simply a
collection of objects that allows you to access the components using an
integer position. Lists grow automatically when you add new elements to
them. Lists are used to represent sets, vectors, and matrices. A *set*
is represented by a sorted list without duplicates. A list whose
elements all lie in a common field is a *vector*. A list of vectors of
the same length over a common field is a *matrix*. Since sets, vectors,
and matrices are lists, all list operations and functions are applicable.
You can, for example, find a certain element in a vector with the general
function 'Position'. There are also *ranges*, i.e., lists of
consecutive integers, and *boolean lists*, i.e., lists containing only
'true' and 'false'. Vectors, ranges, and boolean lists have special
internal representations to ensure efficient operations and memory usage.
For example, a boolean list requires only one bit per element.

*Records* in GAP are similar to lists, except that accessing the
components of a record is done using a name instead of an index. Records
are used to collect objects of different types, while lists usually only
contain elements of one type. Records are for example used to represent
groups and other domains; there is *no* group datatype in the GAP
language . Because of this all information that GAP knows about a group
is also accessible to you by simply investigating the record.

The control structures of GAP are PASCAL-like. GAP has *if* statements,
*while*, *repeat*, and *for* loops. The for loop is a little bit
uncommon in that it always loops over the elements of a list. The usual
semantics can be obtained by looping over the elements of a range. Using
those building blocks you can write *functions*. Functions can be
recursive, and are first class objects in the sense that you can collect
functions in lists, pass them as arguments to other functions and also
return them.

It is important to note that GAP has dynamic typing instead of static
typing. That means that the datatype is a property of the object, not of
the variable. This allows you to write general functions. For example
the generic function that computes an orbit can be used to compute the
orbit of an integer under a permutation group, the orbit of a vector
under a matrix group, the conjugacy class of a group element, and many
more.

The kernel also implements an *interactive environment* that allows you
to use GAP. This environment supports debugging; in case of an error a
break loop is entered in which you can investigate the problem, and maybe
correct it and continue. You also have online access to the manual,
though sections that contain larger formulas do not look nice on the
screen.

The *library of functions*, simply called library in the following,
contains implementations of various group theoretical algorithms written
in the GAP language. Because all the group theoretical functions are in
this library it is easy for you to look at them to find out how they
work, and change them if they do almost, but not quite, what you want.

The whole library is centered around the concept of domains and
categories. A *domain* is a structured set, e.g., a group is a domain as
is the ring of Gaussian integers. Each domain in GAP belongs to one or
more *categories*, which are simply sets of domains, e.g., the set of all
groups forms a category. The categories in which a domain lies determine
the functions that are applicable to this domain and its elements.

To each domain belongs a set of functions, in a so called operations
record, that are called by dispatchers like 'Size'. For example, for a
permutation group , '.operations.Size' is a function implementing
the Schreier Sims algorithm. Thus if you have any domain , simply
calling 'Size( )' will return the size of the domain , computed by
an appropriate function. Domains *inherit* such functions from their
category, unless they redefine them. For example, for a permutation
group , the derived subgroup will be computed by the generic group
function, which computes the normal closure of the subgroup generated by
the commutators of the generators.

Of course the most important category is the category of *groups*. There
are about 100 functions applicable to groups. These include general
functions such as 'Centralizer' and 'SylowSubgroup', functions that
compute series of subgroups such as 'LowerCentralSeries', a function that
computes the whole lattice of subgroups, functions that test predicates
such as 'IsSimple', functions that are related to the operations of
groups such as 'Stabilizer', and many more. Most of these functions are
applicable to all groups, e.g., permutation groups, finite polycyclic
groups, factor groups, direct products of arbitrary groups, and even new
types of groups that you create by simply specifying how the elements are
multiplied and inverted (actually it is not quite so simple, but you can
do it).

Where the general functions that are applicable to all groups are not
efficient enough, we have tried to overlay them by more efficient
functions for special types of groups. The prime example is the category
of *permutation groups*, which overlays 'Size', 'Elements',
'Centralizer', 'Normalizer', 'SylowSubgroup', and a few more functions by
functions that employ stabilizer chains and backtracking algorithms.
Also many of the functions that deal with operations of groups are
overlayed for permutation groups for the operation of a permutation group
on integers or lists of integers.

For *finitely presented groups* only some functions are as yet
implemented. They include finding the index of a subgroup via a
Todd-Coxeter coset enumeration, computing the abelian invariants of the
commutator factor group, intersecting two subgroups, finding the
normalizer of a subgroup, and finding all subgroups of small index. Of
course it is possible to go to a permutation group operating on the
cosets of a subgroup and then to work with this permutation group.
Clearly there is still much to be done in this area, most notably
computing presentations for subgroups and simplifying presentations. We
hope to be able to add such functions in the near future.

For *finite polycyclic groups* a special kind of presentation
corresponding to a composition series is used. Such a presentation
implies a canonical form for the elements and thus allows efficient
operations with the elements of such a group. This presentation is used
to make functions such as 'Centralizer', 'Normalizer', 'Intersection',
and 'ConjugacyClasses' very efficient. GAP's capabilities for finite
polycyclic groups exceed those of the computer system SOGOS (which was
developed at Lehrstuhl D f"ur Mathematik for the last decade).

There is also support for *mappings* and *homomorphisms*. Since they
play such a ubiquitous role in mathematics, it is only natural that they
should also play an important role in a system like GAP. Mappings and
homomorphisms are objects in their own right in GAP. You can apply a
mapping to an element of its source, multiply mappings (provided that the
range of the first is a subset of the source of the second), invert
mappings (even if what you get is a multi-valued mapping), and perform a
few more operations. Important examples are the 'NaturalHomomorphism'
onto a factor group, 'OperationsHomomorphism' mapping a group that
operates on a set of elements into the symmetric group on [1..],
'Embeddings' into products of groups, 'Projections' from products of
groups onto the components, and the general 'GroupHomomorphismByImages'
for which you only specify the images of a set of generators.

The library contains a package for handling character tables of finite
groups. This includes almost all possibilities of the computer system
CAS (which was developed at Lehrstuhl D f"ur Mathematik in the last
decade), and many new functions. You can compute character tables of
groups, or construct character tables using other tables, or do some
calculations within known character tables. You can, for example,
compute a list of candidates for permutation characters. Of course there
are many character tables (at the moment more than 650 ordinary tables)
in the data library, including all those in the ATLAS of finite groups.

For large integers we now also have a package for *elementary number
theory*. There are functions in this package to test primality, factor
integers of reasonable size, compute the size phi() of the prime
residue group modulo an integer , compute roots modulo an integer ,
etc. Also based on this there is a package to do calculations in the
ring of Gaussian integers.

The library also includes a package for *combinatorics*. This contains
functions to find all selections of various flavours of the elements of a
set, e.g., 'Combinations' and 'Tuples', or the number of such selections,
e.g., 'Binomial'. Other functions are related to partitions of sets or
integers, e.g., 'PartitionsSet' and 'RestrictedPartitions', or the number
of such, e.g., 'NrPartitions' and 'Bell'. It also contains some
miscellaneous functions such as 'Fibonacci' and 'Bernoulli'.

The *data library* at present contains the primitive permutation groups
of degree up to 50 from C. Sims, the 2-groups of size dividing 256 from
E. O'Brien and M. F. Newman, the solvable groups of size up to 100 from
M. Hall, J. K. Senior, R. Laue, and J. Neub"user, and a library of
character tables including all of the ATLAS. We plan to extend the data
library with more data in the future.


How to get GAP
==============
Ceterum censeo:
Nobody has ever paid a licence fee
for using a proof
that shows Sylow's subgroups to exist.
Nobody should ever pay a licence fee
for using a program
that computes Sylow's subgroups.
(J. Neub"user)

GAP is distributed *free of charge*. You can obtain it via 'ftp' or
electronic mail and give it away to your colleagues. GAP is *not* in the
public domain, however. In particular you are not allowed to incorporate
GAP or parts thereof into a commercial product.

If you get GAP, we would appreciate it if you could notify us, e.g., by
sending a short e-mail message to '[email protected]',
containing your full name and address, so that we have a rough idea of
the number of users. We also hope that this number will be large enough
to convince various agencies that GAP is a project worthy of (financial)
support. If you publish some result that was partly obtained using GAP,
we would appreciate it if you would cite GAP, just as you would cite
another paper that you used. Again we would appreciate if you could
inform us about such a paper.

We distribute the *full source* for everything, the C code for the
kernel, the GAP code for the library, and the LaTeX code for the manual,
which has at present about 700 pages. So it should be no problem to get
GAP, even if you have a rather uncommon system. Of course, ports to non
UNIX systems may require some work. We already have a port to the Atari
ST. A port to IBM PC compatibles with an Intel 80386 or 80486 is under
way. We also hope to provide a port to the Apple Macintosh in the near
future. Note that about 4 MByte of main memory and a harddisk are
required to run GAP.

GAP 3.1 can be obtained by anonymous *ftp* from the following servers.

'samson.math.rwth-aachen.de':
Lehrstuhl D fur Mathematik, RWTH Aachen, Germany (137.226.152.6).

'dimacs.rutgers.edu':
DIMACS, Rutgers, New Brunswick, New Jersey (128.6.75.16).

'math.ucla.edu':
Math. Dept., Univ. of California at Los Angeles (128.97.4.254).

'pell.anu.edu.au':
Math. Dept., Australian National Univ., Canberra (150.203.15.5).

'ftp' to the server *closest* to you, login as user 'ftp' and give your
full e-mail address as password. GAP is in the directory 'pub/gap'.
Remember when you transmit the files to set the file transfer type to
*binary image*, otherwise you will only receive unusable garbage. Those
servers will always have the latest version of GAP available.

GAP can also be obtained via *electronic mail*. To get one of the files
mentioned below send a message to '[email protected]'
containing a line 'get GAP ', e.g., 'get GAP src3r1.tar.Z'.
'listserv' will reply by sending you the file as e-mail message.

Because most files are large binary files they will be uuencoded and
split into several parts, each at most 64 kBytes large. You can
concatenate the parts by hand, removing the mail header, and then use
'uudecode' to decode them. We suggest however that you also get 'uud.c',
which skips the mail headers automatically and is also able to fix up
transmission errors caused by 'EBCDIC' machines. You can also get single
parts of a file by sending 'get GAP '.

For users in the United Kingdom with only Janet access, neither 'ftp' nor
the mail server will work (please do *not* try to use the mail server).
Please contact Derek Holt (e-mail address '[email protected]'). He
has kindly offered us to distribute GAP in the United Kingdom.

The 'ftp' directory and the 'listserv' archive contain the following
files. Please check first which files you need, to avoid transferring
those that you don't need.

'README': the file you are currently reading.

GAP version 3 release 1 itself comes in several files. You do not need
all of those files. All files are 'compress'-ed 'tar' archives.

'src3r1.tar.Z': the *source code* for the GAP kernel. You need
this unless you get one of the executables below.
This file is about 600 KBytes long.

'lib3r1.tar.Z': the *library of functions*. You need this. This
file is about 700 KBytes long.

'doc3r1.tar.Z': the *documentation*. Serves as LaTeX source
for the printed manual and online documentation.
Contains further installation information. This
file is about 700 KBytes long.

'doc3r1.dvi.Z': the preformatted documentation. You need this
if you do not have a *big* TeX. This file is
about 900 KByte long.

'grp3r1.tar.Z': various *group libraries*. Contains for example
all primitive permutation groups of degree at
most 50. This file is about 50 KByte long.

'two3r1.tar.Z': the library of *2-group* of size at most 256.
This file is about 630 KByte long.

'tbl3r1.tar.Z': a library of *character tables* including all of
the ATLAS. This file is about 2000 KByte long.

'src3r1.zoo', 'lib3r1.zoo', 'doc3r1.zoo',
'grp3r1.zoo', 'tbl3r1.zoo', 'two3r1.zoo':
'zoo' archives containing *exactly* the same
files as the 'compress'-ed 'tar' archives above.
The advantage of 'compress'-ed 'tar' archives is
that 'uncompress' and 'tar' are widely available
on UNIX systems. The advantage of 'zoo' archives
is that they are smaller (about 30 percent) and
that 'zoo' is more common on PC-s and Atari ST-s.
(Those files may not be available on all servers)

We supply executables for some of the more popular machines. If you have
one of those machines it will be easier for you to get this executable
instead of compiling GAP yourself. The following executables are
available (again these files may not be available on all servers)

'gapexe.st': executable for Atari ST (680?0) running TOS
compiled with the GNU C compiler. This file is
about 360 KByte long.

'gapexe.su3': executable for SUN 3 (680?0) running SunOS 4.0 or
higher compiled with SunOS C. This file is about
410 KByte long.

'gapexe.su4': executable for SUN 4 (Sparc) running SunOS 4.0 or
higher compiled with SunOS C. This file is about
450 KByte long.

'gapexe.dec': executable for DECstation (MIPS) running Ultrix
4.0 or higher compiled with Ultrix C. This file
is about 500 KByte long.

The following support files are also available (and again these files may
not be available on all servers)

'compress.tar': 'compress' version 4.1. You need this program
to uncompress the compressed tar files. Note
however, that almost all UNIX systems these days
already come with an executable 'compress'. This
file is about 90 KByte long.

'uud.c': 'uud' version 3.4. 'uud' is much better than the
'uudecode' that comes with most UNIX systems.
This file is about 12 KByte long.

'zoo21.tar.Z': Rahul Dhesi's 'zoo' archiver version 2.1. You
need this to unpack the *zoo-archives*. Note
that the widespread version 2.01 will *not* work.
This file is about 250 KByte long.

'zooexe.st': Executable of 'zoo' for the Atari ST. This file
is about 80 KByte long.


How to install GAP
==================

The file 'install.tex' in 'doc3r1.tar.Z' contains extensive installation
instructions. If however, you are one of those who never read manuals,
here is a quick installation guide.

Make a directory for GAP, e.g., '~/gap/' or '/usr/local/lib/gap/'.

Unpack the source archive 'src3r1.tar.Z' into the subdirectory 'src/';
unpack the library archive 'lib3r1.tar.Z' into the subdirectory 'lib/';
unpack the documentation 'doc3r1.tar.Z' into the subdirectory 'doc/'.

If you have obtained the optional groups and character tables libraries
'grp3r1.tar.Z', 'tbl3r1.tar.Z', and 'two3r1.tar.Z', unpack them into
the subdirectories 'grp/', 'tbl/', and 'two/'.

Change into 'src/' and execute 'make' to see a list of possible targets;
select a target, if in doubt use 'bsd' or 'usg', and make the kernel.

In an appropriate directory, e.g., '~/bin/' or '/usr/local/bin/', create
a shell script that executes the GAP kernel. This should look like

exec /src/gap -m 4m -l /lib/ $*

The option '-m' specifies the amount of initial memory; the option '-l'
specifies where to find the library, if you get it wrong GAP complains

gap: hmm, I cannot find 'lib/init.g', maybe use option '-l '?

Change into 'doc/' and make the printed manual with the commands

latex manual; latex manual; lp -dvi manual.dvi

or something similar, according to your local custom for using LaTeX.


Try something in GAP, e.g., the following exercises GAP quite a bit

gap> m11 := Group( (1,2,3,4,5,6,7,8,9,10,11), (3,7,11,8)(4,10,5,6) );;
gap> Number( ConjugacyClasses( m11 ) );

The result should be 10.


The Future of GAP
=================
See ye not all these things?
Verily I say unto you,
there shall not be left here
one stone upon another,
that shall not be thrown down.
(Matthew 24:2)

Clearly GAP will contain bugs, as any system of this size, though
currently we know none. Also there are things that we feel are still
missing, and that we would like to include into GAP. We will continue to
improve and extend GAP. We will release new versions quite regulary now,
about three or four upgrades a year are planned.

We are committed however, to staying upward compatible from now on in
future releases. That means that everything that works now will also
work in those future releases. This is different from the quite radical
step from GAP 2.4 to GAP 3.1, in which almost everything was changed.

Of course, we have ideas about what we want to have in future versions of
GAP. However we are also looking forward to your comments or
suggestions.


The GAP Forum
=============

We have also established a GAP forum, where interested users can discuss
GAP related topics by e-mail. In particular this forum is for questions
about GAP, general comments, bug reports, and maybe bug fixes. We, the
developers of GAP, will read this forum and answer questions and
comments, and distribute bug fixes. Of course others are also invited to
answer questions, etc. We will also announce future releases of GAP on
this forum. So in order to be informed about bugs and their fixes as
well as about additions to GAP we recommend that you subscribe to the GAP
forum.

To subscribe send a message to '[email protected]'
containing the line 'subscribe gap-forum ', where
should be your full name, not your e-mail address. You will receive an
acknowledgement, and from then on all e-mail messages sent to
'[email protected]'.

'[email protected]' also accepts the following
requests: 'help' for a short help on how to use 'listserv', 'unsubscribe
gap-forum' to unsubscribe again, 'recipients gap-forum' to get a list of
subscribers, and 'statistics gap-forum' to see how many e-mail messages
each subscriber has sent so far.


If you have further questions or comments do not hesitate to write to me
'[email protected]'.

Thank you for your attention, Martin.

--
Martin Sch"onert, [email protected], +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany
Received: from urmel.Informatik.RWTH-Aachen.DE by martigny.ai.mit.edu with SMTP
(16.7/15.6) id AA21455; Thu, 16 Apr 92 16:12:55 -0400
Return-Path:
Received: from math (math.math.RWTH-Aachen.DE) by urmel.informatik.rwth-aachen.d
e (4.1/urmel-MX.31)
id AA11788; Thu, 16 Apr 92 22:12:41 +0200
Errors-To: [email protected]
Received: from samson by math with SMTP
(15.11/15.6) id AA14715; Thu, 16 Apr 92 22:07:51 mes
Received: by samson.math.rwth-aachen.de (5.57/Ultrix3.0-C)
id AA19949; Thu, 16 Apr 92 22:11:07 +0200
Date: Thu, 16 Apr 92 22:11:07 +0200
Message-Id: <[email protected]>
Comment: Listserv server
Errors-To: [email protected]
Reply-To:
Sender: [email protected]
Version: 5.31 -- Copyright (c) 1991, Anastasios Kotsikonas
From: [email protected]
To: [email protected]
Subject: SUBSCRIBE GAP-FORUM ALLAN ADLER


You have been added to list [email protected]
Requests to [email protected]
Welcome to the GAP Forum.

We have established the GAP forum as a place where interested users can
discuss GAP related topics by e-mail. In particular this forum is for
questions about GAP, general comments, bug reports, and maybe bug fixes.
We, the developers of GAP, will read this forum and answer questions and
comments, and distribute bug fixes. Of course others are also invited to
answer questions, etc. We will also announce future releases of GAP on
this forum.

Please send questions as e-mail to '[email protected]'
not to '[email protected]'. From now on you will
receive all such e-mail messages sent to 'gap-forum', except your own.

'[email protected]' also accepts the following
requests: 'help' for a short help on how to use 'listserv', 'unsubscribe
gap-forum' to unsubscribe again, 'recipients gap-forum' to get a list of
subscribers, 'statistics gap-forum' to see how may emails each subsriber
has sent so far, and 'set gap-forum mail ack' to receive your own e-mail
messages too.

If you have further questions or comments do not hesitate to write to me
'[email protected]'.


[next article]
From: [email protected] (Charles Hedrick)

Subject: should malloc.h include ansidecl.h? u_long, etc.
Message-ID:
Date: 4 May 92 04:44:05 GMT
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 12

I just ported lq_text 1.12 beta to Linux 0.96-, with GCC 2.1 and
the libraries and include files that come with it. I had to make
a number of changes due to include file problems. I'm interested
whether these are portability problems in the software or
bugs in the include files:

requires EXFUN, etc. These are declared in
. Should include itself?

lq_text uses u_long, u_short, and u_int. Apparently they expect
these to be declared in standard header files on by the compiler.
They aren't. Should they be?


[next article]
From: [email protected] (Sir David H. Hunter I)

Subject: Using IPC ...Thanks
Message-ID: <[email protected]>
Date: 4 May 92 05:19:22 GMT
Sender: [email protected]
Reply-To: [email protected] (Sir David H. Hunter I)
Organization: Ericsson Network Systems, Richardson TX
Lines: 18
Nntp-Posting-Host: s08b19.exu.ericsson.se

Thanks for the many replies
dd works fine using a block size of 18k

I seem to be missing a couple of .h files for GCC 2.1
but I will have double check that I got all of the parts

Is someone working on some packages to support a Tektronix
terminal connected to a 386 as /dev/ttys[1|2] ?

thanks again
david


--
[email protected] (214)997-6740
David H. Hunter the previous
Ericsson Network Systems drivel is mine
Richardson, TX 75081 != Ericsson's


[next article]
From: [email protected] (Zeyd M. Ben-Halim)

Subject: bugs in linux; any clues?
Keywords: bugs library shell archiver
Message-ID: <[email protected]>
Date: 4 May 92 05:53:29 GMT
Sender: [email protected] (netnews admin account)
Organization: University of Denver, Dept. of Math & Comp. Sci.
Lines: 17

There are several bugs in linux. I'm running 0.95c+ and gcc2.1.
Two not serious but annoying bugs:
pressing ENTER at the prompt of more results in the prompt line being scrolled
together with the rest of the screen.
characters typed before the prompt appears get echoed again after the prompt.
this only happens with bash and ash but not with rc.
There is a bug in the gcc2.1 library preventing archivers, lha-1.00 and zip-1.0
working properly. lha keeps gobbling memory until it runs out of swap memory;
this with more than 2MB of memory. zip simply sits there with no visible
action (it could be allocating memory, but it never crashed)
finally gawk keeps crashing with general protection error on scripts (namely,
one with rc and in makewhatis from man-1.0)

If anybody has any clues or fixes please feel free to impart them.

Thanks,
Zeyd


[next article]
From: [email protected] (Jim Winstead Jr.)

Subject: Re: bugs in linux; any clues?
Keywords: bugs library shell archiver
Message-ID: <[email protected]>
Date: 4 May 92 06:20:41 GMT
References: <[email protected]>
Sender: [email protected] (The News System)
Organization: Harvey Mudd College, WIBSTR
Lines: 32

In article <[email protected]> [email protected] (
Zeyd M. Ben-Halim) writes:
>There are several bugs in linux. I'm running 0.95c+ and gcc2.1.
>Two not serious but annoying bugs:
>pressing ENTER at the prompt of more results in the prompt line being scrolled
>together with the rest of the screen.

I just tested this, and didn't notice it myself. You should hack out
the code 'cs=\E..etc' from your termcap file. Apparently it doesn't
work under Linux, and causes problems with at least Emacs, and
possible more.

>characters typed before the prompt appears get echoed again after the prompt.
>this only happens with bash and ash but not with rc.

This is the expected behavior, I believe, and is a result of using the
GNU readline library. It does that so you can edit the command line.
(I say it's probably a result of readline, because my version of rc is
compiled with readline, and behaves as you mention - this is on my
school's computer, though, which could be different.)

>finally gawk keeps crashing(50%)>characters typed before the prompt appears get echoed again after the prompt.
>this only happens with bash and ash but not with rc.

This is the expected behavior, I believe, and is a result of using the
GNU readline library. It does that so you can edit the command line.
(I say it's probably a result of readline, because my version of rc is
compiled with readline, and behaves as you mention - this is on my
school's computer, though, which could be different.)

>finally gawk keeps crashing(50%)>characters typed before the prompt appears get echoed again after the prompt.
>this only happens with bash and ash but not with rc.

This is the expected behavior, I believe, and is a result of using the
GNU readline library. It does that so you can edit the command line.
(I say it's probably a result of readline, because my version of rc is
compiled with readline, and behaves as you mention - this is on my
school's computer, though, which could be different.)

>finally gawk keeps crashing
Hope I didn't introduce any new bugs...

Rick Sladkey
[email protected]
-----
This is a new version of GNU Emacs 18.58 for Linux 0.95c+ compiled
with GCC 2.1. It corrects a few small problems I've had with the
version compiled by Bernd Wiegmann .

The major fixes are that suspending and resuming now work and
interrupts and job control now work in shell-mode.

It also works to compile with the shared libraries but we have been
encouraged not to distribute dynamically linked binaries. Because of
the way emacs works, it is not possible to prepare an emacs.a file
ready for linking. This would reduce the binary by about 75k.

It took me a long time to find out that there is a bad bug in
setvbuf/setbuf in the 92.04.06 version of the gcc2.1 library. I
commented out its use and Emacs now seems to be pretty robust.
Symptoms were random hangs, segmentation violations, and Emacs killing
itself with ABORT after detecting a corrupted memory pool.

You can still use the rest of Bernd's distribution. Just copy emacs
to /usr/local/bin/emacs. If emacs complains about not being able to
find DOC-18.58.1 then just copy DOC-18.58.14 to DOC-18.58.1. They are
identical.

I have included the config.h I used as well as the few small patches
needed for the rest of the source. I learned a lot about Linux this
way ...

Rick Sladkey
[email protected]


[next article]
Fromool.

You can still use the rest of Bernd's distribution. Just copy emacs
to /usr/local/bin/emacs. If emacs complains about not being able to
find DOC-18.58.1 then just copy DOC-18.58.14 to DOC-18.58.1. They are
identical.

I have included the config.h I used as well as the few small patches
needed for the rest of the source. I learned a lot about Linux this
way ...

Rick Sladkey
[email protected]


[next article]
Fromool.

You can still use the rest of Bernd's distribution. Just copy emacs
to /usr/local/bin/emacs. If emacs complains about not being able to
find DOC-18.58.1 then just copy DOC-18.58.14 to DOC-18.58.1. They are
identical.

I have included the config.h I used as well as the few small patches
needed for the rest of the source. I learned a lot about Linux this
way ...

Rick Sladkey
[email protected]


[next article]
From
|> some versions of MSDOS will not edit a disk if it does not have a valid
|> boot sector - try another version):

Thank you Jim. I finaly figured it out myself late saturday evening! ๐Ÿ™‚
)
Sometimes I just think things are much more difficult than they realy are!

Anyway I now got a Linux (0.95a) runing em(acs), gcc and mtools. So
far it looks real good!

Hallvard (the horrible) Paulsen


[next article]
From: [email protected] (Linus Benedict Torvalds)

Subject: 0.96 out next week
Message-ID: <[email protected]>
Date: 4 May 92 07:38:03 GMT
References: <[email protected]>
Organization: University of Helsinki
Lines: 61

Ok, the subject says most of it: I'll send out 0.96 sometimes next week
(ie 92.05.11-17), and this is just an announcement to confirm that.

0.96 has a lot of changes (even relative to pre-0.96), and it's entirely
possible that making it available as cdiffs isn't feasible. It contains
a lot of new files, as well as some re-organizations in the old ones.

Main new things are:

- The SCSI distribution is now in the standard package. I (obviously)
haven't been able to test my patchings, so there might be problems in
this first release. I had to do some changes "blind" to the cdiffs,
but most of them were pretty trivial.

- X11r5 as ported by obz is supported. It's still in beta-testing (join
the X11-channel on the original mailing-list), but as I'm writing this
from an xterm under linux, it works pretty well. Changes to pre-0.96
are just the socket-code by obz, and some small tweaking by me.

- Hopefully better interrupt latency - I've changed select() not to use
cli-sti, and most IRQ's to enable interrupts, and instead disable just
their own interrupt-line. The interrupt latency has been noticeable at
higher serial speeds, and I hope 0.96 will be better in this respect.
Again, I only have 2400bps, so I've never seen the problems, and
cannot guarantee the new version will help. (btw, I hope the problems
with select are gone now)

- Reorganisation of the vfs routines and minix filesystem driver. These
shouldn't bother anyone but people that have implemented their own
filesystems (I know of just 2 to date), but I hope the current
vfs-interface will prove to be relatively stable. The new vfs
interface has made some things much cleaner, and the promised cleanup
of special devices has happened.

- ps/uptime patches + added readahead, so having computationally
intensive background processes isn't as noticeable any more when doing
IO.

Additionally, there /might/ be a new floppy-driver that supports
formatting and autodetecting floppies, but I haven't had time to check
into it yet.

There are probably any number of minor changes: I've lost track. People
have sent me some diffs, and some of them went in, depending on how
energetic I was that day. I've tried to correct all the bugs I've
gotten reports on, and hopefully 0.96 will work with just about
everything (gdb etc).

Things I wanted, but didn't have time for:

- The config patches aren't there. Sorry everybody. That means still no
wd8003 driver etc.

- Any number of minor patches (quota, auto-SVGA etc)

Generally, 0.96 is cleaning some things up, but on the other hand the
new features can have their share of problems. We'll see. Anyway, most
things seem to work, and I hope there won't be the same type of problems
as with the first 0.95 release.

Linus


[next article]
From: [email protected] (Hallvard Paulsen)

Subject: What is *limits.h* and what to do next
Keywords: stdio.h, limits.h, shell, emacs
Message-ID: <[email protected]>
Date: 4 May 92 08:10:21 GMT
Sender: [email protected] (NetNews Administrator)
Reply-To: [email protected] (Hallvard Paulsen)
Organization: University of Trondheim, Norway
Lines: 32


Hello everybody!

This weekend I managed to get a Linux(0.95a) system running
on my home computer. And so far it looks very promising. But I have had
some problems:

1. The em (uemacs) editor is not 100% compatible with what
I use at work. (CTRL X CTRL S whitch I use to save a file
locks the display). And I do not have the help file so I
can find out what keystrokes do what. What files should
I get to fix this problem.

2. GCC when using the #include statement in a C program
the compiler complains that "limits.h" is not found. What is
limits.h, why is it not included in the gcc(binary) tar file and
where can I get this file (in what tar file)?
(Or what should I put in it?)

3. The shell is quite primitive (I'm using 4dos in MS-dos). Are there
anything better around?

4. Upgrading to new vertions of the system: As far as I know
the latest vertion is 0.95c (I've got 0.95a). Is this an
easy operation or do I have to start from scratch again?

5. Man pages. Are there any around? How much HD space do I need
to run such a thing? (I've only got about 40 MB for Linux)

6. I guess I'll post more questions soon, but this is it for now! ๐Ÿ˜‰

Hallvard (the horrible) Paulsen


[next article]
From: [email protected] (Werner Almesberger)

Subject: Re: Experimental polling serial lines driver
Message-ID: <[email protected]>
Date: 4 May 92 09:11:59 GMT
References: <[email protected]>
Sender: [email protected] (USENET News System)
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Lines: 21

In article <[email protected]> I wrote:
> There have been occasional lockups. Don't know whether they are
> still there. Opening the same port from another process seems to
> resolve the problem.

Those lockups were caused by my modem using DSR in much the same way
as DCD. This confused the "clever" trick to auto-detect devices that
support DSR flow control. There are probably many other modems that
do the same thing ...

Fix: in my serial.c, uses_dsr should be initialized to whatever is
appropriate for the local configuration (0 if hardware flow control
isn't really needed) and the automatic setting of uses_dsr in
serial_open should be removed.

- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ETH Zuerich, CH [email protected] /
/ IFW A44 Tel. +41 1 254 7213 [email protected] /
/_BITNET:[email protected]__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/


[next article]
From: [email protected] (Fabien Coutant)

Subject: New version of BootLinux
Message-ID: <[email protected]>
Date: 4 May 92 07:47:04 GMT
Sender: [email protected]
Reply-To: [email protected] (Fabien Coutant)
Lines: 30
Nntp-Posting-Host: uapu


---
Hello, guys. I'm sorry not to have answered sooner, but my news
server was having a lot of problems...
This week-end I had time to write a new version, which aim is
to correct a bug that made garbage appear instead of the SVGA prompt.
I have uploaded it today on tsx-11.mit.edu. So check the date for
/pub/linux/INSTALL/bootlin.zip (In fact I'm not sure it will show up
under the same name, but I uploaded it as bootlin.zip)
Here's the WHATSNEW file:

==============================================================================
I think I have now corrected the bug that hung some computers and
made everyone have garbage in place of the "Press to see SVGA modes".

If the ROOT device number is not defined, it allows you to choose
it within some devices.

It has a far more simple command line parsing routine. That allowed
to save about 33% of the size, which in turn allowed the new BootLinux to
be smaller than the old one. Drawback: no checking is done. Anyway,
it has the same syntax than the previous BootLinux.

I now give a MASM source !
==============================================================================
Fabien COUTANT

---

Email: [email protected]


[next article]
From: [email protected] (Libedinsky Fernando (Amiram))

Subject: Utilities ditribution
Message-ID: <[email protected]>
Date: 27 Apr 92 12:33:08 GMT
Sender: [email protected]
Organization: Tel Aviv University School of Math and CS, ISRAEL
Lines: 17
Nntp-Posting-Host: math.tau.ac.il

The utilities distribution procedure for Linux is very confusing
now. I have identified the folowing sources:

- ftp sites 'binaries' or 'bin' directory.
- the 2.1shared... file in the gcc 2.1 distribution.
- the interim distribution
- the root diskette

I think someone should take the job of utilities distributions because
with the coming release of 0.96 the situation will be worst: new root
disk, new gcc release, new interim release, etc. And most of us don't
want to spend a lot of time searching the ftp sites for the most
newer version of the utilities.

Fernando Libedinsky
Tel-Aviv University
[email protected]


[next article]
From: [email protected] (Walter Hafner)

Subject: Re: FTP-site, mirroring tsx-11 in Germany?
Message-ID: <[email protected]>
Date: 4 May 92 10:55:02 GMT
References:
Sender: [email protected] (USENET Newssystem)
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
Lines: 18
In-Reply-To: [email protected]'s message of Thu, 30 Apr 92 21:23:59 GMT


> I heard about an FTP-site in Munich, that's mirroring tsx-11.mit.edu.
> Can anybody tell the internet-number?
> It's because I can't acces tsx-11.

Hi!

The name of the computer is "ftp.informatik.tu-muenchen.de"
The IP-number is 131.159.0.110

The mirror is in the directory /pub/Linux

-Walter
--
____________
/ / Walter 'madhouse' Hafner
-------8888888888===========------------ [email protected]
\___________\ [email protected]


[next article]
From: [email protected] (Stephen R. van den Berg)

Subject: Re: Questions about lmail, Taylor UUCP, and selection-1.0
Message-ID: <[email protected]>
Date: 4 May 92 13:24:00 GMT
References:
Sender: [email protected] (Newsfiles Owner)
Organization: RBI - RWTH Aachen
Lines: 24
Originator: [email protected]
Nntp-Posting-Host: ikki

Joe Waters writes:
>1) Does anybody know where I can get lmail, either in binary or source
>form for a Linux-0.95c+ kernel?

A very good alternative (backwards compatible and more powerful)
for lmail is procmail (I admit, I'm biased, I wrote it :-).

Installation should be a snap, a simple make should do, then copy procmail
over lmail (or make a link to it); alternatively, read the installation
instructions that go with the program :-).
----------------------
A recent version can be picked up at various comp.sources.misc archives.
The latest version can be obtained directly from the ftp-archive at:

ftp.informatik.rwth-aachen.de (137.226.112.31)

as compressed tar file: pub/unix/procmail.tar.Z <128KB
or in compressed shar format: pub/unix/procmail.0?.Z
----------------------
--
Sincerely, [email protected]
Stephen R. van den Berg (AKA BuGless). [email protected]

Real programmers don't produce results, they return exit codes.


[next article]
From: [email protected]

Subject: DEL with XC, xcomm solved (ugly)
Message-ID: <[email protected]>
Date: 4 May 92 13:45:59 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected]
Organization: The Internet
Lines: 9

Have work around to output DEL with XC with existing termcap.

echo -en "" >del

When need to send DEL merely do a ^A f del

BTW: With this last piece of kludging, no longer using MS-DOS for any
communication to mainframe!!!
John


[next article]
Message-ID: <[email protected]>
Date: 4 May 92 13:45:59 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected]
Organization: The Internet
Lines: 9

Have work around to output DEL with XC with existing termcap.

echo -en "" >del

When need to send DEL merely do a ^A f del

BTW: With this last piece of kludging, no longer using MS-DOS for any
communication to mainframe!!!
John


[next article]
Message-ID: <[email protected]>
Date: 4 May 92 13:45:59 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected]
Organization: The Internet
Lines: 9

Have work around to output DEL with XC with existing termcap.

echo -en "" >del

When need to send DEL merely do a ^A f del

BTW: With this last piece of kludging, no longer using MS-DOS for any
communication to mainframe!!!
John


[next article]
Message-ID: <[email protected]>
Date: 4 May 92 13:45:59 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected]
Organization: The Internet
Lines: 9

Have work around to output DEL with XC with existing termcap.

echo -en "" >del

When need to send DEL merely do a ^A f del

BTW: With this last piece of kludging, no longer using MS-DOS for any
communication to mainframe!!!
John


[next article]
> * DOS functions can maybe be done by translating the system files
> with the translator, and mapping int's to calls (i.e. link
> the translated program with the DOS "library"????
> * As for direct screen access, SVGA, etc., if the program writes
> directly to memory it shouldn't need much at all, just as with
> in/out commands to the Video Card.
> * BIOS - hum, I don't know if under LINUX the BIOS is accessable???
> speed here...
> * DOS functions can maybe be done by translating the system files
> with the translator, and mapping int's to calls (i.e. link
> the translated program with the DOS "library"????
> * As for direct screen access, SVGA, etc., if the program writes
> directly to memory it shouldn't need much at all, just as with
> in/out commands to the Video Card.
> * BIOS - hum, I don't know if under LINUX the BIOS is accessable???
> speed here...
> * DOS functions can maybe be done by translating the system files
> with the translator, and mapping int's to calls (i.e. link
> the translated program with the DOS "library"????
> * As for direct screen access, SVGA, etc., if the program writes
> directly to memory it shouldn't need much at all, just as with
> in/out commands to the Video Card.
> * BIOS - hum, I don't know if under LINUX the BIOS is accessable???
> speed here...
> * DOS functions can maybe be done by translating the system files
> with the translator, and mapping int's to calls (i.e. link
> the translated program with the DOS "library"????
> * As for direct screen access, SVGA, etc., if the program writes
> directly to memory it shouldn't need much at all, just as with
> in/out commands to the Video Card.
> * BIOS - hum, I don't know if under LINUX the BIOS is accessable???
> speed here...
> * DOS functions can maybe be done by translating the system files
> with the translator, and mapping int's to calls (i.e. link
> the translated program with the DOS "library"????
> * As for direct screen access, SVGA, etc., if the program writes
> directly to memory it shouldn't need much at all, just as with
> in/out commands to the Video Card.
> * BIOS - hum, I don't know if under LINUX the BIOS is accessable???
> speed here...
> * DOS functions can maybe be done by translating the system files
> with the translator, and mapping int's to calls (i.e. link
> the translated program with the DOS "library"????
> * As for direct screen access, SVGA, etc., if the program writes
> directly to memory it shouldn't need much at all, just as with
> in/out commands to the Video Card.
> * BIOS - hum, I don't know if under LINUX the BIOS is accessable???
> now.


[next article]
From: [email protected] (Joerg Pommnitz)

Subject: Re: vi editor
Keywords: editor
Message-ID:
Date: 4 May 92 14:05:19 GMT
References: <[email protected]>
Sender: [email protected] (Owner of all binaries)
Organization: tu-chemnitz
Lines: 18

[email protected] (Hien Luu) writes:


>I would like to use vi on Linux, does any body out there knows where
>I can get a copy of the vi clone to run on Linux..?
>
>Now I got Linux on my system and it runs beautifully, I would like
>to learn how to build the kernel from scratch. I understand that
>I have to down load the source files, but could someone that has
>been through this before please explain which files are needed and
>it would be great if you can list some sort of procedures
>
>Thanks a lot in advance....
>Hien Luu

There is a free vi clone called elvis. Only a couple of weeks ago there was
a new release (1.5) in the alt.sources newsgroup. It runs fine under Linux
without any changes.


[next article]


From: [email protected] (Jacob Martin Bohn Lorensen)

Subject: Re: GCC, 0.95c+, pre-0.96 and weird inconsistencies
Message-ID: <[email protected]>
Date: 4 May 92 16:37:06 GMT
References: <[email protected]> <[email protected]
>
Sender: [email protected]
Organization: Department of Computer Science, U of Copenhagen
Lines: 19

[email protected] (Rob Hooft) writes:

>May be related problem: under gnu-chess 3.1 I have to press 4
>times before the program reacts to a single line command. Does anybody
>have a good solution for this?

I also had another problem, which I think is located in the stdio library.
I compiled gnugo with no trouble at all.
Gnugo seemed to work, except after a couple of draws it got stuck
in a _very_ memory-consuming loop, eating my 8 Mb swap space in 2 minutes.
I fixed it by putting a fflush(stdout) in the main loop, which is why
I believe it to be an error in the library.

(Running 0.95c+, GCC2.1)

Jacob Lorensen
[email protected]
--
No signature yet !


[next article]
From: [email protected] (Michael K. Johnson)

Subject: new stuff at tsx-11
Message-ID: <[email protected]>
Date: 4 May 92 19:14:50 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected] (Michael K. Johnson)
Organization: The Internet
Lines: 24

at tsx-11.mit.edu:/pub/linux/*, we have:

INSTALL/bootlin.zip
The /new/ one, with source. Thanks, Fabien!

binaries/usr.games/dkptrace.tar.Z
Raytracer...

binaries/usr.bin/file.tar.Z
file executable and docs, by longshot. He says that disply
problem will be fixed soon...

sources/usr.games/life.tar.Z
sources, docs, and executable for game of life...

and hopefully soon, we will have the fixed emacs as
binaries/emacs-18.58/newemacs.tar.Z
but that may have to wait a little, due to reasons beyond my control.

michaelkjohnson
[email protected]

--- Please, when you download things to tsx-11, drop a note ---
--- to [email protected] -- It may help things happen ---


[next article]
From: [email protected] (Rajat Datta)

Subject: Re: Suspending emacs and bringing it back
Message-ID: <[email protected]>
Date: 4 May 92 19:59:11 GMT
References: <[email protected]> <[email protected]>
Sender: [email protected] (NNTP News Poster)
Organization: IBM T.J. Watson Research Center
Lines: 32
Disclaimer: This posting represents the poster's views, not necessarily those of
IBM
Nntp-Posting-Host: shravani.watson.ibm.com

In article <[email protected]> [email protected] writes:
>
>It might pay to wait for 0.96 to see if the problem persists.
>
>

Yup, that's what I thought. I'm waiting.

However, I did write a simple program that simply puts the tty into
raw mode and accepts input in an infinite loop. It also enables
SIGCONT, so that I can put it to sleep and when I bring it back, it
can print out the current settings of the tty. This points out a bug
in the tty driver.

Basically, to put a tty into raw mode, you have to turn of CANONical
processing. I also set the VMIN (minimum number of chars input before
responding) to 5 and VTIME (length of time to wait in 1/100 of a
second) to 10. When I receive a SIGCONT, I print out the current tty
settings and go back to reading the input. What I'm finding is that
once I come back from SIGCONT, the tty settings claim to still have
CANONical processing turned off, but the driver is still doing such
processing. That is, I'm getting echoing and cooked mode processing.

I haven't read the code all that closely yet (haven't had all that
much free time lately), but I remember there is a current terminal tty
structure and the tty structure for each process group. Looks like
maybe they aren't set the same in certain occasions when they should
be. Anyway, it all sounds suspiciously similar to the TIOCSPGRP bug
and maybe the same fix will fix both problems.

--
rajat ([email protected])


[next article]
From: [email protected]

Subject: Re: Shouldn't we be using zoo?
Message-ID: <[email protected]>
Date: 3 May 92 09:17:50 GMT
References: @cck.coventry.ac.uk> <[email protected]>
Organization: Computer Centre, Monash University, Australia
Lines: 25

In article <[email protected]>, [email protected]
.FI (Lars Wirzenius) writes:
> [email protected] (Plug) writes:
> Personally I support the idea that for distribution (as opposed to
> personal archiving) .tar.Z is currently the best choice: it works,
> reliably (modulo invalid libraries), fairly efficiently, portably, and
> is free.
>
--
A couple of points about .zoo versus .tar.Z
1) From my observations, .zoo gives better compression than .tar.Z.
By extracting all of the files from a .tar.Z and then placing them into
a .zoo archive, I have always saved space; usually between a couple of
percent and perhaps 15 per cent.
2) Under msdos, .tar.Z is very inconvenient. Just to get a listing of the
files you must first uncompress the file to obtain the .tar file. This is
a severe problem when the .tar.Z file is one or two Mbyte and you are
running low on disk space!
I guess that with linux you probably get real pipes and therefore avoid
having to create a .tar file...

---------------
Bill Metzenthen
Mathematics Department
Monash University
Australia


[next article]
From: [email protected] (James R. Saker Jr.)

Subject: compress -d problems
Keywords: compress,eating memory,ack,aarg
Message-ID:
Date: 4 May 92 20:33:21 GMT
Sender: [email protected] (UNO Network News Server)
Organization: University of Nebraska at Omaha
Lines: 16


I'm running into problems w/ Linux compress eating up all my
available memory and swap (8MB RAM/25MB virtual) when uncompressing
files of various sizes. compress -d chews up all existing memory almost
immediately and then starts eating into swap until there's none left -
even on compressed files as small as 100,000.

I've tried the compress fix on tsx-11:/pub/linux/binaries/usr.bin/compress
and it does the same (I presume it's the same binary since I'm running
0.95c+). I'm running on a 486DX, 8MBytes RAM, 210MB IDE, VGA.

Has anyone run into similar probs and found a fix for it?

. . . . . . . . . . . . . . . . . . . . . . . . . .
. Jamie Saker [email protected] .
. . . . . . . . . . . . . . . . . . . . . . . . . .


[next article]
From: [email protected] (Jean-Marc Alliot)

Subject: Problems with tar, compress and HD driver (was Frustrating problem with gcc-2.1)
Message-ID: <[email protected]>
Date: 22 Apr 92 11:54:07 GMT
References: <[email protected]>
Sender: [email protected]
Distribution: comp
Organization: Centre d'Etudes de la Navigation Aerienne, Toulouse, France
Lines: 21
In-Reply-To: [email protected]'s message of Sat, 18 Apr 1992 10:13:04
GMT


I finally succeeded in fixing the problem by myself. The tar and
compress that comes with the standard distribution seem to have
problems from time to time. The new versions on banjo solved part of
my problem.

However, there is something much more serious. The HD linux-driver is
definitely buggy with high speed disk+machine. I had to set the speed
to 8Mhz instead of 33Mhz on my 486 to make everything work properly.
It seems that, when loading a program, the kernel sometimes loads
incorrect blocks making programs to fail with strange messages. I
presume the kernel also writes incorrect blocks from time to time.
It took a long time to find this out, and I think it could be included
in a FAQ to prevent other people to have similar problems.

This is somewhat frustrating. I'll try to correct that if I have the
time. I presume it is a timeout problem somewhere. Is somebody already
working on that ?

Apart this, Linux is a great thing for kernel hackers. Congratulations
to all people who worked on it, and especially to Linus.


[next article]
From: [email protected] (Theodore Ts'o)

Subject: Re: ** LIST NEWS **
Message-ID: <[email protected]>
Date: 5 May 92 02:01:39 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected]
Organization: The Internet
Lines: 44

For those of you who were complaining about not seeing much traffic on
the digest list: The [email protected] software was
using the same software as the Perl-Users mailing list, and so it was
hit with the same bug. Oops..... I should have looked at the perl
script a bit more carefully. Sorry 'bout that!

- Ted

To: [email protected]
** LIST NEWS **

I forgot to remove a June '91 hack to avoid digestifying a bunch of old
reposted articles that were coming in from USENET. The hack just discarded
articles which matched (case-insensitively) the regular expression

date:[^m]*may

That caused most of the articles received over the past four days to be
ignored. The next few digests will contain them all along with repeats of
the few that escaped the axe in the first place.

I'm sorry for the interruption.

-- Marc Rouleau

** FOR YOUR REFERENCE **

The service addresses, to which questions about the list itself and requests
to be added to or deleted from it should be directed, are as follows:

Internet: [email protected]
[email protected]
BITNET: [email protected]
UUCP: ...!uunet!virginia!perl-users-request

You can send mail to the entire list (and comp.lang.perl) via one of these

addresses:

Internet: [email protected]
BITNET: [email protected]
UUCP: ...!uunet!virginia!perl-users

End of Perl-Users Digest
******************************


[next article]
From: [email protected] (V. Narayanan)

Subject: Writing an OS - questions !!
Message-ID: <[email protected]>
Date: 5 May 92 01:57:05 GMT
Sender: [email protected]
Reply-To: [email protected] (V. Narayanan)
Lines: 20


Hi folks,
For quite some time this "novice" has been wondering as to how one goes
about the task of writing an OS from "scratch". So here are some questions,
and I would appreciate if you could take time to answer 'em.

1) How would you typically debug the kernel during the development phase?
2) Can you test the kernel functionality by running it as a process on a
different OS? Wouldn't the OS(the development environment) generate
exceptions in cases when the kernel (of the new OS) tries to modify
'priviledged' registers?
3) Would new linkers and loaders have to be written before you get a basic
kernel running?
4) Was Linux developed in a DOS environment? Maybe Linus could shed some light
on this subject.

Thanks in anticipation.


N. Venkat


[next article]
From: [email protected] (Rick)

Subject: Filesystems + ISO-9660(CDROM) + SCSI (newbie stuff)
Message-ID: <[email protected]>
Date: 5 May 92 02:29:34 GMT
Organization: Telecom Australia, TNE Computer Support Services
Lines: 17


Some newbie questions: what do these TLA's mean?
UFS
VFS
LFS
FFS
etc..
I know they represent various types for filesystems, but details??

More on filesystems: anybody implemented ISO-9660?

I read in an article a while back that the ST-02 SCSI driver will work
on a Future Domain 885 with some changes. What changes? Can I (please,
please...) boot 0.96 and have it see the SCSI on the 885?

Thanx,
Rick.


[next article]
From: [email protected]

Subject: Re: DEL with XC, xcomm solved (ugly)
Message-ID: <[email protected]>
Date: 5 May 92 02:41:16 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected]
Organization: The Internet
Lines: 7

Sorry, should be echo -en "backslash 177" >del

Use by ^A f del

Interesting that have hard time generating del, but system eats
backslash 177 as del when don't want it to --- perverse
John


[next article]
From: [email protected] (Joel M. Hoffman)

Subject: Re: Filesystems + ISO-9660(CDROM) + SCSI (newbie stuff)
Message-ID: <[email protected]>
Date: 5 May 92 03:01:28 GMT
References: <[email protected]>
Sender: [email protected] (USENET News system)
Organization: University of Maryland at College Park
Lines: 8
Nntp-Posting-Host: wam.umd.edu

In article <[email protected]> [email protected]
.au (Rick) writes:
>More on filesystems: anybody implemented ISO-9660?

I just saw on comp.unix.bsd that someone was playing with this for
386BSD. Anyone interested might start there.

-Joel
([email protected])


[next article]
From: [email protected] (Todd Radel)

Subject: X11 won't work? Help!
Message-ID: <[email protected]>
Date: 5 May 92 03:15:26 GMT
Organization: University of Delaware
Lines: 40

Well, I ftp'ed the X11 package from banjo.concert.net, and installed it as
per the docs. However, on running xinit, I get:

X386 Version 1.2 / X Window System [linux version]
(protocol Version 11, revision 0, vendor release 5000)


Fatal server error:
Can't open /dev/tty0

I then attempted to create /dev/tty0, by first linking it to /dev/tty,
then to /dev/tty1, then by executing mknod /dev/tty0 c 4 0. All gave
me this response:

X386 Version 1.2 / X Window System [linux version]
(protocol Version 11, revision 0, vendor release 5000)


VGA256: pvga1 (mem: 256k clocks: 25 28 0 22 36 52 0 62)
Too less memory for virtual resolution

Fatal server error:
No screens found.
Giving up.
xinit: Invalid argument (errno 22): unable to connect to X server.
xinit: No such process (errno 3): Server error.

What the blazes is going on here? Why can't I connect? And why does X386
believe my Paradise card only has 256k of memory?

I'd really love to get X up on my machine, so if anyone has any ideas, they
can post or e-mail. Thanks!

-- Todd

--
Todd Radel | "Scheme is evil and must be destroyed."
CIS/English | -- anyone from CISC180 --
University of Delaware | No, I'm NOT a sysop any more, thank you
Internet: [email protected] | very much. I'm well now.


[next article]
From: [email protected] (Adam Thompson)

Subject: Re: new SVGA patch. Realtek card added
Message-ID: <[email protected]>
Date: 5 May 92 02:57:38 GMT
References: <[email protected]>
Organization: University of Manitoba, Winnipeg, Canada
Lines: 22

In <[email protected]> [email protected]
ikhef.nl (Willem Kasdorp) writes:

> - If you select a SVGA text mode (not the standard 80x50 VGA mode) there is no
> login prompt at the other virtual consoles! Surely this is a bug, but is it
> mine? It is still possible to enter a login name and password though.
> Do people with other SVGA cards have it as well? Some hacking around
> in init.c and getty.c revealed no obvious reason for the bug. It is
> probably related to the fact that setting the SVGA mode clears the screen.

Yes... I have this problem too. I use an ATI VGA1024 w/512k (chiplevel 1).
I've noticed that the behaviour exists *only* with 0.95c+. I haven't had
time to get 0.95c++ but the problem was ... introduced at some point LATER
then 0.95b, as that version worked fine in this regard. It didn't bother me,
as you just hit and output works fine...

-Adam Thompson
[email protected]
--
= Adam Thompson ---- Computer Engineering ---- University of Manitoba =
= [email protected] = "When you have eliminated the improbable, =
= ...!uunet!decwrl!alberta!\ = whatever is left, however impossible, =
= ccu.UManitoba.CA!umthom61 = must be the answer." =


[next article]
From: [email protected] (Jawaid Bazyar)

Subject: Re: Writing an OS - questions !!
Message-ID: <[email protected]>
Date: 5 May 92 03:33:10 GMT
References: <[email protected]>
Sender: [email protected] (Net Noise owner)
Organization: University of Illinois at Urbana
Lines: 63

[email protected] (V. Narayanan) writes:


Having just written a Multitasking OS, I couldn't resist...

>Hi folks,
> For quite some time this "novice" has been wondering as to how one goes
>about the task of writing an OS from "scratch". So here are some questions,
>and I would appreciate if you could take time to answer 'em.

>1) How would you typically debug the kernel during the development phase?

On my machine (Apple IIgs), we have a machine-language debugger which
has a number of nifty features, the most important here being that it
'turns-on' whenever certain reserved software traps are activated. You
can intersperse these in your code to trace certain locations.
And, there's always the infamous "printf" method, printing out every
value you deem relevant to the problem.
You probably won't be able to use existing source-level debuggers (see
below), but this is just conjecture on my part and indeed depends on how
you initially implement the system.

>2) Can you test the kernel functionality by running it as a process on a
> different OS? Wouldn't the OS(the development environment) generate
> exceptions in cases when the kernel (of the new OS) tries to modify
> 'priviledged' registers?

Yes, and in fact many classes in OS design are taught with this principle.
"Operating System Design" by Douglas Comer implements a Unix-like OS
called XINU. There is source code publically available for a version
of XINU which runs under UNIX systems. This system works by basically
implementing threads (multiple processes inside one real Unix process).
Your mention of the new OS accessing privileged registers is a good question,
and as far as I know there's no good answer except one: you have to get
the basic multitasking and low-level OS features working by sweat alone.
Usually, you have to boot into your new OS, instead of running it from
your development system. This means that you have a really tedious
test, reboot, compile, reboot, test cycle.

>3) Would new linkers and loaders have to be written before you get a rocess).
Your mention of the new OS accessing privileged registers is a good question,
and as far as I know there's no good answer except one: you have to get
the basic multitasking and low-level OS features working by sweat alone.
Usually, you have to boot into your new OS, instead of running it from
your development system. This means that you have a really tedious
test, reboot, compile, reboot, test cycle.

>3) Would new linkers and loaders have to be written before you get a Windows, Windows->DOS, etc).
As far as loaders, you probably would want to for later user programming,
but most OS's are written to be loaded into a pre-defined area of physical
memory, and thus you won't need a loader to boot your system. In any
event, loaders are in general fairly simple, and you could probably
emulate existing ones (so as to be able to use existing compilers, etc).

Writing an OS is probably one of the most satisfying things I've done;
I wouldn't recommend it for the faint of heart, however. ๐Ÿ™‚

--
Jawaid Bazyar | Ask me about the GNO Multitasking Environment
Procyon, Inc. | for the Apple IIgs! (314) 334-7078
[email protected] | 1005 N. Kingshighway, Suite 309
--Apple II Forever!-- | Cape Girardeau, MO 63701


[next article]
From: [email protected] (Erik Green)

Subject: New Pcomm
Message-ID:
Date: 5 May 92 03:48:51 GMT
Distribution: comp.os.linux
Organization: Long polymers in double-helix formation
Lines: 16
Nntp-Posting-Host: att2.cs.mankato.msus.edu


Has anyone else out there had problems with the new pcomm? The old one
worked fine for me except for the screen problems, but the new one, although
it connects and seems to transmit and receive fine, never prints the current
line until after it scrolls up one, so I can never see what I'm typing.

If this is a PDSP(previously discussed small problem), please email me
the fix.

Thx 0xf4240,
Longshot
--
Erik "Longshot" Green
[email protected](vax1 | att2.cs | krypton | theory.cs).mankato.msus.edu
"Ash nazg durbatuluk, ash nazg gimbatul, ash nazg
thrakatuluk agh burzum-ishi krimpatul!"


[next article]
From: [email protected] (Randy Appleton)

Subject: Re: 0.96 out next week
Message-ID: <[email protected]>
Date: 5 May 92 04:05:52 GMT
References: <[email protected]>
<[email protected]>
Organization: University Of Kentucky, Dept. of Math Sciences
Lines: 15

[email protected] (Linus Benedict Torvalds) writes:

>Main new things are:

>- X11r5 as ported by obz is supported. It's still in beta-testing (join
> the X11-channel on the original mailing-list), but as I'm writing this
> from an xterm under linux, it works pretty well. Changes to pre-0.96
> are just the socket-code by obz, and some small tweaking by me.

Here's a question. What CGA cards does it support, and at what
resolutions. Also, what's the realistic RAM requirements?

-Thanks
-Randy


[next article]
From: [email protected] (Todd Radel)
Newsgroups: comp.os.linux,comp.unix.sysv386,comp.windows.x

Subject: X386 Paradise configuration?
Message-ID: <[email protected]>
Date: 5 May 92 04:49:50 GMT
References: <[email protected]>
Followup-To: comp.os.linux
Organization: University of Delaware
Lines: 14

Does anyone know what should be put into Xconfig for my Western
Digital WA-V77 card? (Paradise clone; 512k VRAM; 640x480x256) The
card is hooked up to an Aamazing "ULTRA VGA Color Monitor", which is
noninterlaced all the way to 1024x768.

Could some kind soul help me out? I'd be happy to provide data from
the manufacturers' spec sheets if it would help.

Thanks!
--
Todd Radel | "Scheme is evil and must be destroyed."
CIS/English | -- anyone from CISC180 --
University of Delaware | No, I'm NOT a sysop any more, thank you
Internet: [email protected] | very much. I'm well now.


[next article]
From: [email protected] (Paul H. Hargrove)

Subject: Possible bug in lp driver, or just me?
Summary: write error
Message-ID: <[email protected]>
Date: 5 May 92 05:50:18 GMT
Sender: [email protected]
Organization: Cornell University, Ithaca New York, USA
Lines: 18
Nntp-Posting-Host: theory.tc.cornell.edu

I am running the Pre-0.96 version of linux on a Zenith Turbosport 386
with 2Mb memory, and 4 meg swap. The problem I have is this:
when I type something like:
cat textfile >/dev/lp1
I get back:
cat: write error
And the printer receives just the first character of textfile.
I created /dev/lp1 with:
mknod /dev/lp1 c 6 1
chmod 666 /dev/lp1

I have tried 0.95c+, and get the same problem. Is this a problem
unique to my hardware?

--
Paul H. Hargrove
[email protected]
"A witty saying proves nothing." --Voltaire


[next article]
From: [email protected] (Paul H. Hargrove)

Subject: Kermit(5A) with pre-0.96
Summary: echos only first char of line
Keywords: kermit pre0.96
Message-ID: <[email protected]>
Date: 5 May 92 06:02:42 GMT
Sender: [email protected]
Organization: Cornell University, Ithaca New York, USA
Lines: 22
Nntp-Posting-Host: theory.tc.cornell.edu

running pre0.96 w/ 2mb real and 4mb swap on a Zenith turbosport386:

Running the version of Kermit(5A) which came on the mcc-interim disks
for 0.95c+ under Pre0.96 I find that at the Kermit-C> prompt I only
get the first character of my line echoed. This is annoying becaus I
can't see what I have typed. When I hit Enter I get the rest of the line
drawn, and a beep or two if I tried to backspace to before the start of
the line.

Is this a problem others have seen? Should I be using a newer version
of kermit? If so which one, and where do I get it?

Thanx

Pre.S.
Thank You to Linus and all the others who have provided me with an escape
from MESS-DOSS, and the ability do actually accomplish something on my
machine.
--
Paul H. Hargrove
[email protected]
"A witty saying proves nothing." --Voltaire


[next article]
From: [email protected] (Linus Benedict Torvalds)

Subject: X386 (Was Re: 0.96 out next week)
Message-ID: <[email protected]>
Date: 5 May 92 06:35:13 GMT
References: <[email protected]> <[email protected]
aava.Helsinki.FI> <[email protected]>
Organization: University of Helsinki
Lines: 28

In article <[email protected]> [email protected] (Randy Appleton) w
rites:
>> [ X window system ]
>
>Here's a question. What CGA cards does it support, and at what
>resolutions. Also, what's the realistic RAM requirements?

X definitely won't work with CGA - it won't even work with normal VGA
cards: you need SVGA (and even not just any SVGA card will do). The
supported cards are et[3|4]000 and some others (pvga? tvga?).
Resolutions range from 640x480 to 1192x900 (or something like that), all
at 256 colours, depending on what kind of card/monitor combination you
have.

As to memory: I'm using it in 8MB ram, and no swapping (with a couple of
xterms, xclock and xcalc - nothing major). If I want to recompile the
kernel in an xterm, I'll have to start up swapping (well, actually I've
done it without swapping, but it's tight). I assume it's still useable
in 4MB and a big swap-file, but I'm happy I haven't tested it.

Speed probably depends heavily on the SVGA card: on my 386/33 with a
no-name et4000 card I get totally acceptable performance: scrolling big
windows is slow with other things going on, but not irritatingly so.
You don't want to make opaque moves, but I can live without that.

Harddisk space is totally up to you: minimum about 10MB for just the
minimal clients, maximum probably the sky is the limit.

Linus


[next article]
From: [email protected] (Chris Watts)
Newsgroups: comp.os.linux,alt.os.linux

Subject: uucp, pbmplus and rc corrupt ?
Message-ID: <[email protected]>
Date: 2 May 92 14:51:07 GMT
Organization: Bristol Polytechnic, England
Lines: 13

I've had some problems installing the binaries to uucp, pbmplus and rc
from both tsx-11.mit.edu and nic.funet.fi. The always end up corrupt
when I uncompress and untar them. Has anybody else had this problem
or is it just me? If it is a problem with compiling them can the
person that put the up correct it please.


+------------------------+--------------------------------------+
| ___ | Janet: [email protected] |
| / / __ | Internet: [email protected]|
| / /--- /-- . ( | |
| \__ / / / / __) | |
+------------------------+--Has anybody else had this problem
or is it just me? If it is a problem with compiling them can the
person that put the up correct it please.


+------------------------+--------------------------------------+
| ___ | Janet: [email protected] |
| / / __ | Internet: [email protected]|
| / /--- /-- . ( | |
| \__ / / / / __) | |
+------------------------+--Has anybody else had this problem
or is it just me? If it is a problem with compiling them can the
person that put the up correct it please.


+------------------------+--------------------------------------+
| ___ | Janet: [email protected] |
| / / __ | Internet: [email protected]|
| / /--- /-- . ( | |
| \__ / / / / __) | |
+------------------------+--this problem - but when I repulled the file it came down OK.
I think nsf.sun sometimes erroneously defaults to text-transfer mode so
I now always type 'bin' to ensure the transfer is just that.

--
Email : JANET [email protected] | Everywhere else [email protected]
[email protected] | [email protected]


[next article]
From: [email protected] (Linus Benedict Torvalds)

Subject: Re: Writing an OS - questions !!
Message-ID: <[email protected]>
Date: 5 May 92 07:58:17 GMT
References: <[email protected]>
Organization: University of Helsinki
Lines: 136

In article <[email protected]> [email protected] (V. Narayanan) writes:
>
>Hi folks,
> For quite some time this "novice" has been wondering as to how one goes
>about the task of writing an OS from "scratch". So here are some questions,
>and I would appreciate if you could take time to answer 'em.

Well, I see someone else already answered, but I thought I'd take on the
linux-specific parts. Just my personal experiences, and I don't know
how normal those are.

>1) How would you typically debug the kernel during the development phase?

Depends on both the machine and how far you have gotten on the kernel:
on more simple systems it's generally easier to set up. Here's what I
had to do on a 386 in protected mode.

The worst part is starting off: after you have even a minimal system you
can use printf etc, but moving to protected mode on a 386 isn't fun,
especially if you at first don't know the architecture very well. It's
distressingly easy to reboot the system at this stage: if the 386
notices something is wrong, it shuts down and reboots - you don't even
get a chance to see what's wrong.

Printf() isn't very useful - a reboot also clears the screen, and
anyway, you have to have access to video-mem, which might fail if your
segments are incorrect etc. Don't even think about debuggers: no
debugger I know of can follow a 386 into protected mode. A 386 emulator
might do the job, or some heavy hardware, but that isn't usually
feasible.

What I used was a simple killing-loop: I put in statements like

die:
jmp die

at strategic places. If it locked up, you were ok, if it rebooted, you
knew at least it happened before the die-loop. Alternatively, you might

use the sound io ports for some sound-clues, but as I had no experience
with PC hardware, I didn't even use that. I'm not saying this is the
only way: I didn't start off to write a kernel, I just wanted to explore
the 386 task-switching primitives etc, and that's how I started off (in
about April-91).

After you have a minimal system up and can use the screen for output, it
gets a bit easier, but that's when you have to enable interrupts. Bang,
instant reboot, and back to the old way. All in all, it took about 2
months for me to get all the 386 things pretty well sorted out so that I
no longer had to count on avoiding rebooting at once, and having the
basic things set up (paging, timer-interrupt and a simple task-switcher
to test out the segments etc).

>2) Can you test the kernel functionality by running it as a process on a
> different OS? Wouldn't the OS(the development environment) generate
> exceptions in cases when the kernel (of the new OS) tries to modify
> 'priviledged' registers?

Yes, it's generally possible for some things, but eg device drivers
usually have to be tested out on the bare machine. I used minix to
develop linux, so I had no access to IO registers, interrupts etc.
Under DOS it would have been possible to get access to all these, but
then you don't have 32-bit mode. Intel isn't that great - it would
probably have been much easier on a 68040 or similar.

So after getting a simple task-switcher (it switched between two
processes that printed AAAA... and BBBB... respectively by using the
timer-interrupt - Gods I was proud over that), I still had to continue
debugging basically by using printf. The first thing written was the
keyboard driver: that's the reason it's still written completely in
assembler (I didn't dare move to C yet - I was still debugging at
about instruction-level).

After that I wrote the serial drivers, and voila, I had a simple
terminal program running (well, not that simple actually). It was still
the same two processes (AAA..), but now they read and wrote to the
console/serial lines instead. I had to reboot to get out of it all, but
it was a simple kernel.

After that is was plain sailing: hairy coding still, but I had some
devices, and debugging was easier. I started using C at this stage, and
it certainly speeds up developement. This is also when I start to get
serious about my megalomaniac ideas to make "a better minix that minix".
I was hoping I'd be able to recompile gcc under linux some day...

The harddisk driver was more of the same: this time the problems with
bad documentation started to crop up. The PC may be the most used
architecture in the world right now, but that doesn't mean the docs are
any better: in fact I haven't seen /any/ book even mentioning the weird
386-387 coupling in an AT etc (Thanks Bruce).

After that, a small filesystem, and voila, you have a minimal unix. Two
months for basic setups, but then only slightly longer until I had a
disk-driver (seriously buggy, but it happened to work on my machine) and
a small filesystem. That was about when I made 0.01 available (late
august-91? Something like that): it wasn't pretty, it had no floppy
driver, and it couldn't do much anything. I don't think anybody ever
compiled that version. But by then I was hooked, and didn't want to
stop until I could chuck out minix.

>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?

All versions up to about 0.11 were crosscompiled under minix386 - as
were the user programs. I got bash and gcc eventually working under
0.02, and while a race-condition in the buffer-cache code prevented me
from recompiling gcc with itself, I was able to tackle smaller compiles.
0.03 (October?) was able to recompile gcc under itself, and I think
that's the first version that anybody else actually used. Still no
floppies, but most of the basic things worked.

Afetr 0.03 I decided that the next version was actually useable (it was,
kind of, but boy is X under 0.96 more impressive), and I called the next
version 0.10 (November?). It still had a rather serious bug in the
buffer-cache handling code, but after patching that, it was pretty ok.
0.11 (December) had the first floppy driver, and was the point where I
started doing linux developement under itself. Quite as well, as I
trashed my minix386 partition by mistake when trying to autodial
/dev/hd2.

By that time others were actually using linux, and running out of
memory. Especially t boy is X under 0.96 more impressive), and I called the next
version 0.10 (November?). It still had a rather serious bug in the
buffer-cache handling code, but after patching that, it was pretty ok.
0.11 (December) had the first floppy driver, and was the point where I
started doing linux developement under itself. Quite as well, as I
trashed my minix386 partition by mistake when trying to autodial
/dev/hd2.

By that time others were actually using linux, and running out of
memory. Especially than minix, and by now people started to
really get interested.

Then it was 0.95 in March, bugfixes in April, and soon 0.96. It's
certainly been fun (and I trust will continue to be so) - reactions have
been mostly very positive, and you do learn a lot doing this type of
thing (on the other hand, your studies suffer in other respects ๐Ÿ™‚

Linus


[next article]
From: [email protected] (Chris Watts)
Newsgroups: comp.os.linux,alt.os.linux

Subject: Re: uucp, pbmplus and rc corrupt ?
Message-ID: <[email protected]>
Date: 5 May 92 08:28:58 GMT
References: <[email protected]> <[email protected]
brispoly.ac.uk>
Organization: Bristol Polytechnic, England
Lines: 17

In article <[email protected]> [email protected] (D
ylan Smith) writes:
>In article <[email protected]> [email protected]
k (Chris Watts) writes:
>>I've had some problems installing the binaries to uucp, pbmplus and rc
>>from both tsx-11.mit.edu and nic.funet.fi. The always end up corrupt
>>when I uncompress and untar them. Has anybody else had this problem
>>or is it just me? If it is a problem with compiling them can the
>
>I had this problem - but when I repulled the file it came down OK.
>I think nsf.sun sometimes erroneously defaults to text-transfer mode so
>I now always type 'bin' to ensure the transfer is just that.
>
But I used ft-relay to pull it so either theres a problem with ft-relay
or the files are corrupt at site. Perhaps some one in the US could check.

___________________________________________________________________________
Email : Janet [email protected]
Internet [email protected]


[next article]
From: [email protected] (GEC-Marconi Research Centre)
re the transfer is just that.
>
But I used ft-relay to pull it so either theres a problem with ft-relay
or the files are corrupt at site. Perhaps some one in the US could check.

___________________________________________________________________________
Email : Janet [email protected]
Internet [email protected]


[next article]
From: [email protected] (GEC-Marconi Research Centre)
will appear, then move seemingly randomly about the
| screen, selecting random bits of text and pasting them wherever it
| feels like it, but only when I move the mouse... I have a Logitech
| series-9 3-button mouse; my hunch is that the selection driver eats it
| when dealing with this type of mouse. Has any body patched it for the
| Logitech series-9?

[email protected] (Jim Winstead Jr.) writes:

| I've had the exact same problem, and looked at the code briefly, but
| decided that it was a bit beyond my talents, since I didn't have the
| slightest clue as to what is going on with the mouse handling. I'd
| really like to use my mouse as long as I can't run X, so if anyone has
| any ideas, fire away....

| (One thing I've found out in reading my mouse manual pretty thoroughly
| - the Logitech mouse runs at 9600 baud, and I seem to recall the
| selection-1.0 code expecting the mouse to run at 1200.)

Hmmm, probably some of these problems if not all are caused by my having no
documentation at all on how mice work, what codes they return, etc. So when I
wrote the mouse-handling code, I could only test it against my (two-button)
mouse. I had mail from somebody saying that he had to put his three-button
mouse into two-button mode, then it worked. And with other folk it worked OK
without any mods. Experimenting with the baud rate setting seems a good idea;
having it set wrong would certainly give the symptoms mentioned above. I have
no idea how I could put auto-baud rate detection into the mouse handler.

I'll be putting out a new version of selection when the 0.96 kernel appears;
this one supports selection by word and line as well as by character, and
has a more xterm-like selection interface, but the mouse driver hasn't changed.
I'll also be including a simple test program, so you can check for mouse
compatibility without having to patch the kernel first.

I'll repeat my plea for information: If anyone knows of some on-line
documentation about mice at some archive site, please tell me about it.

----
Andrew Haylett | Inet: [email protected] | Fax: +44 245 75244
GEC-Marconi Research | Tel: +44 245 73331 x.3283 | Telex: 995016 GECRES G


[next article]
From: [email protected] (Tommy Frandsen)

Subject: GNUPLOT 3.0 ported to Linux
Keywords: gnuplot, linux
Message-ID: <[email protected]>
Date: 5 May 92 10:26:39 GMT
Sender: [email protected]
Organization: Department of Computer Science, U of Copenhagen
Lines: 14

Hi!

I have just uploaded a Linux port of GNUPLOT 3.0 to banjo.concert.net in
the file /pub/Linux/Incoming/gnuplot.tar.Z. This is a binary only version,
since my patches to the orignal sources still needs a little tidying up.
It requires the following to run in graphics mode:
- The pre-0.96 kernel or newer
- A VGA-adapter and an analog monochrome or color monitor
If you use an older kernel or don't have a VGA-adapter you should still be
able to run gnuplot and get printer or latex output.

Please send comments and bug-reports to:

[email protected] (Tommy Frandsen)


[next article]
From: [email protected] (Tommy Frandsen)

Subject: VGA graphics library for Linux
Keywords: VGA, graphics, library
Message-ID: <[email protected]>
Date: 5 May 92 10:32:05 GMT
Sender: [email protected]
Organization: Department of Computer Science, U of Copenhagen
Lines: 910

Hi!

With the pre-0.96 kernel we got the mmap and ioperm syscalls, and it
is now possible to do some real graphics programming with Linux. I
think there will be a need for a general graphics library (e.g.
Libgraph.a), so that we get a common base for porting and devoloping
graphics applications for Linux (X is such a common base, but it's a
bit overkill if all you want to do is to run a dvi-previewer from time
to time, and many of us simply dosen't have the necessary hardware to
run X).

In my work to port gnuplot to Linux I have written a couple of graphics
routines that I think could serve as basis for such a library. The
following is implemented:
- Support for all standard VGA 16 and 256 color modes
- Support for non-standard 256 color modes (including mode X)
- Simple primitives: point and line
- Complete restoration of the text mode display when returning
from graphics mode (should also work with SVGA text modes)
- Handling of console I/O (e.g. disabling of terminal echoing
in graphics mode)
This should be sufficient for porting many applications to Linux, but
it would be nice if we could include the following in the library:
- Support for SVGA graphics modes
- Support for EGA and Herculers adapters
- Advanced primitives: circles, filled polygons etc
- Faster primitives (recoding of critical parts in assembler)
- Text output in graphics mode
- Better error handling (currently none)
I would be happy if somebody could help with the implementation of
some of these, but I welcome any comments and suggestions, especially
on the contens and structure of the library.

I have included four files:
- "vgalinux.h" is the header file
- "vgalinux.c" contains the source
- "vgatest.c" is a simple demonstration
- "Makefile" compiles the demonstration
Important: The makefile assumes that the pre-0.96 kernel source is
placed in "/usr/src/linux". If that is not true, you should modify the
makefile accordingly.

Please send any comments, bug-reports etc to

[email protected] (Tommy Frandsen)


--- vgalinux.h ------------------------------------------------------------


#ifndef VGALINUX_H
#define VGALINUX_H

#define TEXT 0
#define G320x200x16 1
#define G640x200x16 2
#define G640x350x16 3
#define G640x480x16 4
#define G320x200x256 5
#define G320x240x256 6
rnel source is
placed in "/usr/src/linux". If that is not true, you should modify the
makefile accordingly.

Please send any comments, bug-reports etc to

[email protected] (Tommy Frandsen)


--- vgalinux.h ------------------------------------------------------------


#ifndef VGALINUX_H
#define VGALINUX_H

#define TEXT 0
#define G320x200x16 1
#define G640x200x16 2
#define G640x350x16 3
#define G640x480x16 4
#define G320x200x256 5
#define G320x240x256 6
rnel source is
placed in "/usr/src/linux". If that is not true, you should modify the
makefile accordingly.

Please send any comments, bug-reports etc to

[email protected] (Tommy Frandsen)


--- vgalinux.h ------------------------------------------------------------


#ifndef VGALINUX_H
#define VGALINUX_H

#define TEXT 0
#define G320x200x16 1
#define G640x200x16 2
#define G640x350x16 3
#define G640x480x16 4
#define G320x200x256 5
#define G320x240x256 6
rnel source is
placed in "/usr/src/linux". If that is not true, you should modify the
makefile accordingly.

Please send any comments, bug-reports etc to

[email protected] (Tommy Frandsen)


--- vgalinux.h ------------------------------------------------------------


#ifndef VGALINUX_H
#define VGALINUX_H

#define TEXT 0
#define G320x200x16 1
#define G640x200x16 2
#define G640x350x16 3
#define G640x480x16 4
#define G320x200x256 5
#define G320x240x256 6
rnel source is
placed in "/usr/src/linux". If that is not true, you should modify the
makefile accordingly.

Please send any comments, bug-reports etc to

[email protected] (Tommy Frandsen)


--- vgalinux.h ------------------------------------------------------------


#ifndef VGALINUX_H
#define VGALINUX_H

#define TEXT 0
#define G320x200x16 1
#define G640x200x16 2
#define G640x350x16 3
#define G640x480x16 4
#define G320x200x256 5
#define G320x240x256 6
rnel source is
placed in "/usr/src/linux". If that is not true, you should modify the
makefile accordingly.

Please send any comments, bug-reports etc to

[email protected] (Tommy Frandsen)


--- vgalinux.h ------------------------------------------------------------


#ifndef VGALINUX_H
#define VGALINUX_H

#define TEXT 0
#define G320x200x16 1
#define G640x200x16 2
#define G640x350x16 3
#define G640x480x16 4
#define G320x200x256 5
#define G320x240x256 6
rnel source is
placed in "/usr/src/linux". If that is not true, you should modify the
makefile accordingly.

Please send any comments, bug-reports etc to

[email protected] (Tommy Frandsen)


--- vgalinux.h ------------------------------------------------------------


#ifndef VGALINUX_H
#define VGALINUX_H

#define TEXT 0
#define G320x200x16 1
#define G640x200x16 2
#define G640x350x16 3
#define G640x480x16 4
#define G320x200x256 5
#define G320x240x256 6

#define MIS_C 1 /* 1 Misc Output Register */

/* VGA registers saving indexes */
#define CRT 0 /* CRT Controller Registers start */
#define ATT CRT+CRT_C /* Attribute Controller Registers start */
#define GRA ATT+ATT_C /* Graphics Controller Registers start */
#define SEQ GRA+GRA_C /* Sequencer Registers */
#define MIS SEQ+SEQ_C /* General Registers */
#define END MIS+MIS_C /* last */

#define ABS(a) (((a)<0) ? -(a) : (a))

/* graphics mode information */
struct info {
int xdim;
int ydim;
int colors;
};


/* BIOS mode 0Dh - 320x200x16 */
static char g320x200x16_regs[60] = {
0x2D,0x27,0x28,0x90,0x2B,0x80,0xBF,0x1F,0x00,0xC0,0x00,0x00,
0x00,0x00,0x00,0x00,0x9C,0x8E,0x8F,0x14,0x00,0x96,0xB9,0xE3,
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x10,0x11,0x12,0x13,
0x14,0x15,0x16,0x17,0x01,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x0F,0xFF,
0x03,0x09,0x0F,0x00,0x06,
0x63
};
static struct info g320x200x16_info = { 320, 200, 16 };


/* BIOS mode 0Eh - 640x200x16 */
static char g640x200x16_regs[60] = {
0x5F,0x4F,0x50,0x82,0x54,0x80,0xBF,0x1F,0x00,0xC0,0x00,0x00,
0x00,0x00,0x00,0x00,0x9C,0x8E,0x8F,0x28,0x00,0x96,0xB9,0xE3,
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x10,0x11,0x12,0x13,
0x14,0x15,0x16,0x17,0x01,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x0F,0xFF,
0x03,0x01,0x0F,0x00,0x06,
0x63
};
stat00,0x06,
0x63
};
static struct info g320x200x16_info = { 320, 200, 16 };


/* BIOS mode 0Eh - 640x200x16 */
static char g640x200x16_regs[60] = {
0x5F,0x4F,0x50,0x82,0x54,0x80,0xBF,0x1F,0x00,0xC0,0x00,0x00,
0x00,0x00,0x00,0x00,0x9C,0x8E,0x8F,0x28,0x00,0x96,0xB9,0xE3,
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x10,0x11,0x12,0x13,
0x14,0x15,0x16,0x17,0x01,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x0F,0xFF,
0x03,0x01,0x0F,0x00,0x06,
0x63
};
stat50, 16 };


/* BIOS mode 12h - 640x480x16 */
static char g640x480x16_regs[60] = {
0x5F,0x4F,0x50,0x82,0x54,0x80,0x0B,0x3E,0x00,0x40,0x00,0x00,
0x00,0x00,0x00,0x00,0xEA,0x8C,0xDF,0x28,0x00,0xE7,0x04,0xE3,
0x00,0x01,0x02,0x03,0x04,0x05,0x14,0x07,0x38,0x39,0x3A,0x3B,
0x3C,0x3D,0x3E,0x3F,0x01,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x05,0x0F,0xFF,
0x03,0x01,0x0F,0x00,0x06,
0xE3
};
static struct info g640x480x16_info = { 640, 480, 16 };


/* BIOS mode 13h - 320x200x256 */
static char g320x200x256_regs[60] = {
0x5F,0x4F,0x50,0x82,0x54,0x80,0xBF,0x1F,0x00,0x41,0x00,0x00,
0x00,0x00,0x00,0x00,0x9C,0x8E,0x8F,0x28,0x40,0x96,0xB9,0xA3,
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,
0x0C,0x0D,0x0E,0x0F,0x41,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x40,0x05,0x0F,0xFF,
0x03,0x01,0x0F,0x00,0x0E,
0x63
};
static struct info g320x200x256_info = { 320, 200, 256 };


/* non-BIOS mode - 320x240x256 */
static char g320x240x256_regs[60] = {
0x5F,0x4F,0x50,0x82,0x54,0x80,0x0D,0x3E,0x00,0x41,0x00,0x00,
0x00,0x00,0x00,0x00,0xEA,0xAC,0xDF,0x28,0x00,0xE7,0x06,0xE3,
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,
0x0C,0x0D,0x0E,0x0F,0x41,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x40,0x05,0x0F,0xFF,
0x03,0x01,0x0F,0x00,0x06,
0xE3
};
static struct info g320x240x256_info = { 320, 240, 256 };


/* non-BIOS mode - 320x400x256 */
static char g320x400x256_regs[60] = {
0x5F,0x4F,0x50,0x82,0x54,0x80,0xBF,0x1F,0x00,0x40,0x00,0x00,
0x00,0x00,0x00,0x00,0x9C,0x8E,0x8F,0x28,0x00,0x96,0xB9,0xE3,
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,
0x0C,0x0D,0x0E,0x0F,0x41,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x40,0x05,0x0F,0xFF,
0x03,0x01,0x0F,0x00,0x06,
0x63
};
static struct info g320x400x256_info = { 320, 400, 256 };


/* non-BIOS mode - 360x480x256 */
static char g360x480x256_regs[60] = {
0x6B,0x59,0x5A,0x8E,0x5E,0x8A,0x0D,0x3E,0x00,0x40,0x00,0x00,
0x00,0x00,0x00,0x00,0xEA,0xAC,0xDF,0x2D,0x00,0xE7,0x06,0xE3,
0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,
0x0C,0x0D,0x0E,0x0F,0x41,0x00,0x0F,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x40,0x05,0x0F,0xFF,
0x03,0x01,0x0F,0x00,0x06,
0xE7
};
static struct info g360x480x256_info = { 360, 480, 256 };


static char text_regs[60]; /* VGA registers for saved text mode */

static int cur_mode = TEXT; /* current video mode */
static struct info cur_info; /* current video mode parameters */
static int cur_color; /* current color */

static int initialized = 0; /* flag: init() called ? */

static int mem_fd; /* /dev/mem file descriptor */
static char* graph_mem; /* dummy buffer for mmapping grahics memory */
static char* text_mem; /* dummy buffer for mmapping text memory */

static char text_buf[TEXT_SIZE]; /* saved text mode memory */
static char font_buf[FONT_SIZE]; /* saved font data */

static struct termios text_termio; /* text mode termio parameters */
static struct termios graph_termio; /* graphics mode termio parameters */


static void inline port_out(char value, unsigned short port)
{
__asm__ volatile ("outb %0,%1"
::"a" ((char) value),"d" ((unsigned short) port));
}


static unsigned char inline port_in(unsigned short port)
{
unsigned char _v;
__asm__ volatile ("inb %1,%0"
:"=a" (_v):"d" ((unsigned short) port));
return _v;
}


static void set_graphtermio()
{
/* flush all terminal streams (just to be sure) */
fflush(stdin);
fflush(stdout);
fflush(stderr);

/* disable input buffering */
setbuf(stdin, NULL);

/* save text mode termio parameters */
ioctl(0, TCGETS, &text_termio);

graph_termio = text_termio;

/* change termio parameters to allow our own I/O processing */
graph_termio.c_iflag &= ~(BRKINT|PARMRK|INPCK|IUCLC|IXON|IXOFF);
graph_termio.c_iflag |= (IGNBRK|IGNPAR);

graph_termio.c_oflag &= ~(ONOCR);

graph_termio.c_lflag &= ~(ICANON|ECHO|ECHOE|ECHOK|ECHONL|NOFLSH);
graph_termio.c_lflag |= (ISIG);

graph_termio.c_cc[VMIN] = 1;
graph_termio.c_cc[VTIME] = 0;
graph_termio.c_cc[VSUSP] = 0;

/* set graphics mode termio parametrameters to allow our own I/O processing */
graph_termio.c_iflag &= ~(BRKINT|PARMRK|INPCK|IUCLC|IXON|IXOFF);
graph_termio.c_iflag |= (IGNBRK|IGNPAR);

graph_termio.c_oflag &= ~(ONOCR);

graph_termio.c_lflag &= ~(ICANON|ECHO|ECHOE|ECHOK|ECHONL|NOFLSH);
graph_termio.c_lflag |= (ISIG);

graph_termio.c_cc[VMIN] = 1;
graph_termio.c_cc[VTIME] = 0;
graph_termio.c_cc[VSUSP] = 0;

/* set graphics mode termio paramet: allocation error \n");
exit (-1);
}
if ((unsigned long)graph_mem % PAGE_SIZE)
graph_mem += PAGE_SIZE - ((unsigned long)graph_mem % PAGE_SIZE);
graph_mem = (unsigned char *)mmap(
(caddr_t)graph_mem,
GRAPH_SIZE,
PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED,
mem_fd,
GRAPH_BASE
);
if ((long)graph_mem < 0) {
printf("init: mmap error \n");
exit (-1);
}

/* mmap text memory */
if ((text_mem = malloc(TEXT_SIZE + (PAGE_SIZE-1))) == NULL) {
printf("init: allocation error \n");
exit (-1);
}
if ((unsigned long)text_mem % PAGE_SIZE)
text_mem += PAGE_SIZE - ((unsigned long)text_mem % PAGE_SIZE);
text_mem = (unsigned char *)mmap(
(caddr_t)text_mem,
TEXT_SIZE,
PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED,
mem_fd,
TEXT_BASE
);
if ((long)text_mem < 0) {
printf("init: mmap error \n");
exit (-1);
}

/* get I/O permissions for VGA registers */
if (ioperm(CRT_I, 1, 1)) {
printf("init: can't get I/O permissions \n");
exit (-1);
}
ioperm(ATT_IW, 1, 1);
ioperm(GRA_I, 1, 1);
ioperm(SEQ_I, 1, 1);
ioperm(PEL_IW, 1, 1);
ioperm(CRT_D, 1, 1);
ioperm(ATT_R, 1, 1);
ioperm(GRA_D, 1, 1);
ioperm(SEQ_D, 1, 1);
ioperm(MIS_R, 1, 1);
ioperm(MIS_W, 1, 1);
ioperm(IS1_R, 1, 1);
ioperm(PEL_D, 1, 1);

initialized = 1;
}


static int set_regs(char regs[])
{
int i;

port_out(0x00,GRA_I);
port_out(0x00,GRA_D); /* set/reset */

port_in(IS1_R); /* clear flip-flop */
port_out(0x00,SEQ_I);
port_out(0x01,SEQ_D); /* synchronous reset on */

port_out(regs[MIS+0], MIS_W); /* update misc output register */

port_out(0x1, SEQ_I);
port_out(regs[SEQ+1], SEQ_D); /* update clocking mode */

for (i = 2; i < SEQ_C; i++) { /* sequencer registers */
port_out(i, SEQ_I);
port_out(regs[SEQ+i], SEQ_D);

}

port_out(0x11, CRT_I);
port_out(regs[CRT+0x11]&0x7F, CRT_D); /* deprotect registers 0-7 */

for (i = 0; i < CRT_C; i++) { /* CRT controller registers */
port_out(i, CRT_I);
port_out(regs[CRT+i], CRT_D);
}

for (i = 0; i < GRA_C; i++) { /* graphics controller registers */
port_out(i, GRA_I);
port_out(regs[GRA+i], GRA_D);
}

for (i = 0; i < ATT_C; i++) { /* attribute controller registers */
port_in(IS1_R); /* reset flip-flop */
port_out(i, ATT_IW);
port_out(regs[ATT+i],ATT_IW);
}

port_out(0x00, SEQ_I);
port_out(0x03, SEQ_D); /* synchronous reset off */

return 0;
}


int vga_setmode(int mode)
{
int old_mode, i;

if (mode == cur_mode)
return 0;

old_mode = cur_mode;
cur_mode = mode;

if (!initialized)
init();

/* disable video */
port_in(IS1_R);
port_out(0x00, ATT_IW);

if (mode == TEXT) {
/* write to all bits */
port_out(0x08, GRA_I );
port_out(0xFF, GRA_D );

/* disable Set/Reset Register */
port_out(0x01, GRA_I );
port_out(0x00, GRA_D );

/* restore character map in plane 2 */
port_out(0x02, SEQ_I );
port_out(0x04, SEQ_D );
memcpy(graph_mem, font_buf, FONT_SIZE);

/* restore text mode VGA registers */
set_regs(text_regs);

/* restore contents of text mode memory */
memcpy(text_mem, text_buf, TEXT_SIZE);

/* restore text mode termio */
set_texttermio();
} else {
if (old_mode == TEXT) {
/* set graphics mode termio */
set_graphtermio();

/* save contents of text mode memory */
memcpy(text_buf, text_mem, TEXT_SIZE);

/* save text mode VGA registers */
for (i = 0; i < CRT_C; i++) {
port_out(i, CRT_I);
text_regs[CRT+i] = port_in(CRT_D);
}
for (i = 0; i < ATT_C; i++) {
port_in(IS1_R);
port_out(i, ATT_IW);
text_regs[ATT+i] = port_in(ATT_R);
}
for (i = 0; i < GRA_C; i++) {
port_out(i, GRA_I);
text_regs[GRA+i] = port_in(GRA_D);
}
for (i = 0; i < SEQ_C; i++) {
port_out(i, SEQ_I);
text_regs[SEQ+i] = port_in(SEQ_D);
}
text_regs[MIS] = port_in(MIS_R);
}

switch (mode) {
case G320x200x16:
set_regs(g320x200x16_regs);

/* enable Set/Reset Register */
port_out(0x01, GRA_I );
port_out(0x0F, GRA_D );

/* write with logical OR */
port_out(0x03, GRA_I );
port_out(0x20, GRA_D );

cur_info = g320x200x16_info;
break;
case G640x200x16:
set_regs(g640x200x16_regs);

/* enable Set/Reset Register */
port_out(0x01, GRA_I );
port_out(0x0F, GRA_D );

/* write with logical OR */
port_out(0x03, GRA_I );
port_out(0x20, GRA_D );

cur_info = g640x200x16_info;
break;
case G640x350x16:
set_regs(g640x350x16_regs);

/* enable Set/Reset Register */
port_out(0x01, GRA_I );
port_out(0x0F, GRA_D );

/* write with logical OR */
port_out(0x03, GRA_I );
port_out(0x20, GRA_D );

cur_info = g640x350x16_info;
break;
case G640x480x16:
set_regs(g640x480x16_regs);

/* enable Set/Reset Register */
port_out(0x01, GRA_I );
port_out(0x0F, GRA_D );

/* write with logical OR */
port_out(0x03, GRA_I );
port_out(0x20, GRA_D );

cur_info = g640x480x16_info;
break;
case G320x200x256:
set_regs(g320x200x256_regs);
cur_info = g320x200x256_info;
break;
case G320x240x256:
set_regs(g320x240x256_regs);
cur_info = g320x240x256_info;
break;
case G320x400x256:
set_regs(g320x400x256_regs);
cur_info = g320x400x256_info;
break;
case G360x480x256:
set_regs(g360x480x256_regs);
cur_info = g360x480x256_info;
break;
}

/* save font data if necessary - easy in graphics mode */
if (old_mode == TEXT) {
/* select page 2 */
port_out(0x04, GRA_I);
port_out(0x02, GRA_D);

/* save font data */
memcpy(font_buf, graph_mem, FONT_SIZE);

/* restore map mask register */
port_out(0x04, GRA_I);
port_out(0x00, GRA_D);
}

/* clear screen (sets current color to 15) */
clear();
}

/* enable video */
port_in(IS1_R);
port_out(0x20, ATT_IW);

return 0;
}


int clear()
{
int i;

switch (cur_mode) {
case G320x200x16:
case G640x200x16:
case G640x350x16:
case G640x480x16:
vga_setcolor(0);

/* write to all bits */
port_out(0x08, GRA_I );
port_out(0xFF, GRA_D );

/* write dummy values to clear video memory */
memcpy(graph_mem , text_buf, TEXT_SIZE);
memcpy(graph_mem+TEXT_SIZE, text_buf, TEXT_SIZE);

break;
case G320 (cur_mode) {
case G320x200x16:
case G640x200x16:
case G640x350x16:
case G640x480x16:
vga_setcolor(0);

/* write to all bits */
port_out(0x08, GRA_I );
port_out(0xFF, GRA_D );

/* write dummy values to clear video memory */
memcpy(graph_mem , text_buf, TEXT_SIZE);
memcpy(graph_mem+TEXT_SIZE, text_buf, TEXT_SIZE);

break;
case G320 (cur_mode) {
case G320x200x16:
case G640x200x16:
case G640x350x16:
case G640x480x16:
vga_setcolor(0);

/* write to all bits */
port_out(0x08, GRA_I );
port_out(0xFF, GRA_D );

/* write dummy values to clear video memory */
memcpy(graph_mem , text_buf, TEXT_SIZE);
memcpy(graph_mem+TEXT_SIZE, text_buf, TEXT_SIZE);

break;
case G320
int i;

/* select palette register */
port_out(index, PEL_IW);

/* write RGB components */
port_out(red, PEL_D);
for(i = 0; i < 10; i++) ; /* delay (minimum 240ns) */
port_out(green, PEL_D);
for(i = 0; i < 10; i++) ; /* delay (minimum 240ns) */
port_out(blue, PEL_D);

return 0;
}


int vga_drawpixel(int x, int y)
{
unsigned long offset;

switch (cur_mode) {
case G320x200x16:
/* select bit */

int i;

/* select palette register */
port_out(index, PEL_IW);

/* write RGB components */
port_out(red, PEL_D);
for(i = 0; i < 10; i++) ; /* delay (minimum 240ns) */
port_out(green, PEL_D);
for(i = 0; i < 10; i++) ; /* delay (minimum 240ns) */
port_out(blue, PEL_D);

return 0;
}


int vga_drawpixel(int x, int y)
{
unsigned long offset;

switch (cur_mode) {
case G320x200x16:

/* select bit */

int i;

/* select palette register */
port_out(index, PEL_IW);

/* write RGB components */
port_out(red, PEL_D);
for(i = 0; i < 10; i++) ; /* delay (minimum 240ns) */
port_out(green, PEL_D);
for(i = 0; i < 10; i++) ; /* delay (minimum 240ns) */
port_out(blue, PEL_D);

return 0;
}


int vga_drawpixel(int x, int y)
{
unsigned long offset;

switch (cur_mode) {
case G320x200x16:
/* select bit */
cur_color;
break;
case G360x480x256:
/* select plane */
port_out(0x02, SEQ_I);
port_out(1 << (x & 3), SEQ_D);

/* write color to pixel */
graph_mem[y*90 + (x>>2)] = cur_color;
break;
}

return 0;
}


int vga_drawline(int x1, int y1, int x2, int y2)
{
int dx = x2 - x1;
int dy = y2 - y1;
int ax = ABS(dx) << 1;
int ay = ABS(dy) << 1;
int cur_color;
break;
case G360x480x256:
/* select plane */
port_out(0x02, SEQ_I);
port_out(1 << (x & 3), SEQ_D);

/* write color to pixel */
graph_mem[y*90 + (x>>2)] = cur_color;
break;
}

return 0;
}


int vga_drawline(int x1, int y1, int x2, int y2)
{
int dx = x2 - x1;
int dy = y2 - y1;
int ax = ABS(dx) << 1;
int ay = ABS(dy) << 1;
int
while (y != y2) {
vga_drawpixel(x, y);

if (d > 0 || d == 0 && sy == 1) {
x += sx;
d -= ay;
}
y += sy;
d += ax;
}
}

return 0;
}


int vga_getxdim()
{
return cur_info.xdim;
}


int vga_getydim()
{
return cur_info.ydim;
}


int vga_getcolors()
{
return cur_info.colors;
}

int vga_getch()
{
return getc(stdin);
}


--- vgatest.c -------------------------------------------------------------


#include "vgalinux.h"

static void testmode(int mode)
{
int xmax, ymax, i;

vga_setmode(mode);

xmax = vga_getxdim()-1;
ymax = vga_getydim()-1;

vga_drawline( 0, 0, xmax, 0);
vga_drawline(xmax, 0, xmax, ymax);
vga_drawline(xmax, ymax, 0, ymax);
vga_drawline( 0, ymax, 0, 0);

for(i = 0; i <= 15; i++) {
vga_setcolor(i);
vga_drawline(10+i*5, 10, 100+i*5, 100);
}
for(i = 0; i <= 15; i++) {
vga_setcolor(i);
vga_drawline(100+i*5, 10, 10+i*5, 100);
}

if(vga_getcolors() == 256) {
for(i = 0; i < 64; i++)
vga_setpalette(i+128, i, i, i);
for(i = 0; i < 64; i++) {
vga_setcolor(i+128);
vga_drawline(200+i, 10, 200+i, 100);
}
}

vga_getch();
}


main()
{
testmode(G320x200x16);
testmode(G640x200x16);
testmode(G640x350x16);
testmode(G640x480x16);
testmode(G320x200x256);
testmode(G320x240x256);
testmode(G320x400x256);
testmode(G360x480x256);

vga_setmode(TEXT);
}


--- Makefile --------------------------------------------------------------


CPP =gcc
CFLAGS =-static -nostdinc -I/usr/src/linux/include -I/usr/include
OBJS =vgalinux.o vgatest.o

.c.o:
$(CPP) $(CFLAGS) -c -o $*.o $<

all: vgatest


vgatest: $(OBJS)
$(CPP) $(CFLAGS) -o vgatest $(OBJS)


[next article]
From: [email protected] (Rhys Weatherley)

Subject: Re: Writing an OS - questions !!
Message-ID: <[email protected]>
Date: 5 May 92 11:28:55 GMT
References: <[email protected]> <[email protected]>
Sender: [email protected]
Reply-To: [email protected]
Lines: 20

In <[email protected]> [email protected] (Linus
Benedict Torvalds) writes:

>Well, I see someone else already answered, but I thought I'd take on the
>linux-specific parts. Just my personal experiences, and I don't know
>how normal those are.

Thanks for posting that Linus - it's very good to read how it all began. I
hope that the FTP site administrators save away your message as a piece of
Linux folklore. I especially liked the bit about you being proud of your
two AAAA... and BBBB... processes. ๐Ÿ™‚

Cheers,

Rhys.

+=====================+==================================+
|| Rhys Weatherley | The University of Queensland, ||
|| [email protected] | Australia. G'day!! ||
|| "I'm a FAQ nut - what's your problem?" ||
+=====================+==================================+


[next article]
From: [email protected] (Stephen Hite)

Subject: Re: DOS EMULATION
Message-ID: <[email protected]>
Date: 5 May 92 14:34:29 GMT
References: <[email protected]>
Organization: University of North Florida, Jacksonville
Lines: 16


How does VP/IX basically work? It comes distributed with a Phoenix
Bios image file. Since each DOS session requires at least 1 meg, it
sounds to me like you're just getting a separate copy of the Bios
image for each one. Is it not possible to create an emulator for Linux
where it comes with a program that will dump anybody's ROM Bios to an
image file and /that/ can be loaded into the proper VM86 memory space
before DOS 3.3, 4.0, 5.0, etc. gets loaded? My assumption though is that
the Phoenix Bios image you get with VP/IX is not specially modified.
It would be interesting to hear someone post to comp.os.linux who
knows how the basic process works and why it would be extremely difficult
to reproduce.


Steve Hite
[email protected]


[next article]
From: [email protected] (Hillel Steinberg)
Newsgroups: alt.os.linux,comp.os.linux

Subject: Logitech Mouse and X11
Keywords: X11, Logitech, Mouse
Message-ID: <[email protected]>
Date: 5 May 92 15:15:58 GMT
Sender: [email protected]
Followup-To: alt.os.linux
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 37


When Selection-1.0 came out I downloaded it and found that it didn't work.
But, using the code, I was able to find out what my Logitech (non-bus)
three button mouse was sending, and I rewrote the code so I could use it.
It worked beautifully.

Now I would gladly give up this functionality to have my Logitech mouse work
with X. I download the binaries, and EVERYTHING works, except for the MOUSE.
This problem was mentioned in a previous post, and I want to reiterate it.
I know my mouse is working fine - off ttys1 (cat tells me this and the code
mentioned above). Since the Logitech mouse is actually an option in Xconfig,
why in the world doesn't it work? I have tried to change the Xconfig file
in every way - it started with something like:

Logitech "/dev/ttys1"
Baud 1200
SampleRate 150

(this was done from memory - so the exact synatax is not important)

I tried everything, and I REALLY WANT X11 BAD, does anyone know we can get
or LOGITECH mice working? -Hillel

+---------------------------------------------------------------------------+
| /~~~~~~~~\ |
| /\ My Friend |________| _ , / / / |
| \_> /| ||__/\__|| ' ) / / / / / |
| __|__ \'o.O' \ / /--/ __. _ /_ _ __ ' ' ' |
| / ( =(___)= \ ~ / / /_(_/|_/<_/ <_<'_/ ( o o o |
| | A ( U H |
| \____( ME A B U D D Y /\ |
| E //// .--/--\--. |
| Three can keep a secret if Y //// \/ \/ |
| two are dead........ \\\\ //// /\ /\ |
| -Ben Franklin- \\\X/// `--\--/--' |
| \XXX/ \/ |
+---------------------------------------------------------------------------+


[next article]
From: [email protected] (Kevin Cummings)

Subject: Re: Linux Networking(?)
Message-ID: <[email protected]>
Date: 5 May 92 15:22:54 GMT
References: <[email protected]> <[email protected]> <199
[email protected]> <[email protected]>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 39

In article <[email protected]>, [email protected]
in comp.os.linux:
From: [email protected] (Kevin Cummings)

Subject: Re: Linux Networking(?)
Message-ID: <[email protected]>
Date: 5 May 92 15:22:54 GMT
References: <[email protected]> <[email protected]> <199
[email protected]> <[email protected]>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 39

In article <[email protected]>, [email protected]
in comp.os.linux:
From: [email protected] (Kevin Cummings)

Subject: Re: Linux Networking(?)
Message-ID: <[email protected]>
Date: 5 May 92 15:22:54 GMT
References: <[email protected]> <[email protected]> <199
[email protected]> <[email protected]>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 39

In article <[email protected]>, [email protected]
bps.

> Just a small network in the area, not connected to Internet. I want to use
> telnet, ftp, irc, etc. over it. Is any/all of this ported to Linux? Could

KA9Q supports telnet, ftp, and ping. Its only problem is that it is a user prog
ram
rather than having the network handled by the OS. I use it for download to
my LINUX system (I have another modem at work on the INTERNET). Works fine.

=================================================================
Kevin J. Cummings bps.

> Just a small network in the area, not connected to Internet. I want to use
> telnet, ftp, irc, etc. over it. Is any/all of this ported to Linux? Could

KA9Q supports telnet, ftp, and ping. Its only problem is that it is a user prog
ram
rather than having the network handled by the OS. I use it for download to
my LINUX system (I have another modem at work on the INTERNET). Works fine.

=================================================================
Kevin J. Cummings 1245 (of 1255)--what next? [npq] Article 1246 (9 more) in comp.os.linux:
From: [email protected] (Bernd Kratz)

Subject: Problems with cdd
Keywords: cdd linux
Message-ID: <[email protected]>
Date: 5 May 92 14:45:08 GMT
Organization: CSD., University of Erlangen, Germany
Lines: 33

Hi,
For a few months ago, i wrote a programm for ms-dos, called cdd.
It's similar to Norton's NCD. Now i'm trying it to porting it to linux.
There's a little, ugly problem:
If i start a cdd, the program get's a new environment.
Now,if cdd changes the directory, (this is the function of
this porgram), it is in the selected directory and terminates.
But the shell is still in the old directory.
E.G:
int main()
{
....
a=chdir("/usr");
string=getcwd(NULL,MAX_PATH_NAME+2);
printf("\n cur. wd is %s",string); /* it prints "/usr" */
return a;
}
If you start this , normally you expecting, that your new directory
is /usr, but you are still in your old directory.

Got anybody an idea ?
Or it's possible to export the cwd. of cdd to father process ?

I'm working with GCC 1.40, Linux 0.95c+.

Thanks, Ben

EMAIL: [email protected]

--

| Bernd Kratz IRCNICK: |
| Internet: [email protected] |


[next article]
From: [email protected] (Win Bent)

Subject: DIFFERENT Frustrating problem with gcc-2.1
Summary: all programs "Memory fault"
Keywords: gcc2.1 linux0.95
Message-ID: <[email protected]>
Date: 5 May 92 16:32:52 GMT
Sender: [email protected] (NetNews Administrator)
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 21
Nntp-Posting-Host: eoth.hoh.att.com

My problem is as frustrating the famous "line 1: parse error before (",
but of a slightly different nature: all programs abort with the
message "Memory error". No core file, though - shouldn't there be
one? Then again, what would I do with it, since there's no debugger?

I'm running 0.95a (booting from 0.95c+), using gcc 2.1 from
tsx-11.mit.edu: 2.1*.tar.Z. Installation went quite smoothly, there
were no other compilers on my system to conflict with this one, and
programs compile without complaint. I've got 8 Mb of RAM, so I really
don't think that "Hello, world" is running out of space!

Did I forget some crucial installation step? If so, why don't
compilations complain about something?

Further details and tests on request. Being a well-mannered person,
I will summarize to The Net if and when I get results.

--
Wilson H. Bent, Jr. ... att!hoh-2!whb ([email protected])
AT&T - Bell Laboratories (201) 888-7129
Disclaimer: My company has not authorized me to issue a disclaimer.


[next article]
From: [email protected] (Doug Mayfield)

Subject: What kernel needed to run X???
Message-ID: <[email protected]>
Date: 5 May 92 18:01:46 GMT
Sender: [email protected]
Reply-To: [email protected] (Doug Mayfield)
Organization: UC Davis, EECS Division of Computer Science
Lines: 10

To re-iterate... What version of the kernel is required to
run X.

Inquiring minds want to know.

------------------------------------------------------------
Douglas B. Mayfield
[email protected]
(Computer Science Dept.)
(University of California at Davis)


[next article]
From: [email protected] (Kevin Cummings)

Subject: Re: X386 (Was Re: 0.96 out next week)
Message-ID: <[email protected]>
Date: 5 May 92 18:06:04 GMT
References: <[email protected]> <[email protected]
aava.Helsinki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]nki.FI>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsoki.FI> <[email protected]> <[email protected]
a.Helsinki.FI>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 65

In article <[email protected]>, [email protected]
FI (Linus Benedict Torvalds) writes:
> In article <[email protected]> [email protected] (Randy Appleton)
writes:
> >> [ X window system ]
> >
> >Here's a question. What CGA cards does it support, and at what
> >resolutions. Alsodn't (at that time) know how protected-mode friendly BIOS was, so I
went ahead and used the BIOS function call to switch into protected mode.
That gave me the bonus of getting a descriptor for the BIOS data segment
in my GDT for free. Very helpful. Unfortunately, I really had to go
through loops to keep the BIOS from using my hardware interrupts. Very
ugly.

I never did get as far as Linux has come, so when I found Linux last month,
I jumped in with both feet. Some of my Syrinx stuff is better than Linux's,
but most of Linux is far more advanced than Syrinx ever got.

In general, I think Linus' tactic of getting a bare system up first is a
better bet than trying to make everything fully-formed as you go. I
never did get a C compiler, but I did write an assembler that worked under
Syrinx (I called it Sinas).

One thing that helped my Syrinx development was DOS EXE compatibility. I
checked the header of any files that you tried to execute, and if it was
a DOS EXE header, then I ran it in V86 mode. I could get a number of things
to run, but anything that tried to switch to protected mode would die in
a rather horrible way, so there were a lot of things I couldn't use. I
also didn't support EMS or XMS or DPMI, so those programs were all out.
Basically, what it came down to was that I couldn't run any commercial
programs. ๐Ÿ™

Syrinx has now been shoved way back on the burner, however, and I've
gone whole-hog into Linux.

One of the first things I did when I got Linux was to look at the kernel
code (the equivalent to my /init). I was rather surprised to see that
Linus switched to protected mode all on his own, without going through
the BIOS. I also like his little comment in the sources:
! This is how real programmers do it
or something to that effect. ๐Ÿ™‚


[next article]
From: [email protected] (Linus Benedict Torvalds)

Subject: Re: What kernel needed to run X???
Message-ID: <[email protected]>
Date: 5 May 92 19:11:03 GMT
References: <[email protected]>
Organization: University of Helsinki
Lines: 9

In article <[email protected]> [email protected] (Doug Mayfi
eld) writes:
>To re-iterate... What version of the kernel is required to
>run X.

You need pre-0.96 with the (pretty small) patches for sockets that are
included with the X distribution. Alternatively, you can wait a week
for the real 0.96, which also fixes a couple of minor problems.

Linus


[next article]
From: [email protected] (I Reid)

Subject: Re: new SVGA patch. Oak Svga code available
Message-ID: <[email protected]>
Date: 5 May 92 20:12:28 GMT
References: <[email protected]>
Organization: Edinburgh University
Lines: 11

I have a patch for Oak 0-67 (tested) and Oak 0-37C (untested, incomplete but
easily completed if you have an 037c) Svga board and will post it as soon as I
get my machine talking to the outside world again (I hit C-A-D by accident and
I'm continually finding corrupt binaries (including ALL my comms stuff)). If
anyone wants it then mail me and I'll send it. Supported modes are

43h 132x60.... lovely!
50h 132x25.... out of focus. unusable.... don't know why.
51h 132x43.... out of focus. unusable.... don't know why.

Iain


[next article]
From: [email protected]ola.ca.us (Darren Senn)

Subject: Re: Swapping (Was Re: X386 (Was Re: 0.96 out next week))
Message-ID: <[email protected]>
Date: 5 May 92 20:21:31 GMT
References: <[email protected]> <[email protected]
aava.Helsinki.FI> <[email protected]> <[email protected]
a.Helsinki.FI> <[email protected]>
Sender: [email protected]
Reply-To: [email protected]
Organization: Curiosity Confederacy
Lines: 29

Ok, so my subject line is getting too nested... so shoot me. *bang* *thump* ๐Ÿ™‚

In article <[email protected]>, [email protected] (Kevin
Cummings) writes:
> > As to memory: I'm using it in 8MB ram, and no swapping (with a couple of
> > xterms, xclock and xcalc - nothing major). If I want to recompile the
> > kernel in an xterm, I'll have to start up swapping (well, actually I've
> > done it without swapping, but it's tighus
Organization: Curiosity Confederacy
Lines: 29

Ok, so my subject line is getting too nested... so shoot me. *bang* *thump* ๐Ÿ™‚

In article <[email protected]>, [email protected] (Kevin
Cummings) writes:
> > As to memory: I'm using it in 8MB ram, and no swapping (with a couple of
> > xterms, xclock and xcalc - nothing major). If I want to recompile the
> > kernel in an xterm, I'll have to start up swapping (well, actually I've
> > done it without swapping, but it's tighus
Organization: Curiosity Confederacy
Lines: 29

Ok, so my subject line is getting too nested... so shoot me. *bang* *thump* ๐Ÿ™‚

In article <[email protected]>, [email protected] (Kevin
Cummings) writes:
> > As to memory: I'm using it in 8MB ram, and no swapping (with a couple of
> > xterms, xclock and xcalc - nothing major). If I want to recompile the
> > kernel in an xterm, I'll have to start up swapping (well, actually I've
> > done it without swapping, but it's tigh
particular problem could be with the MCC-interim release, or GCC, or 0.95c+,
or virtual consoles, or swapping, or who knows. The point is, that's the
only problem I've encountered, and I swap a lot.


[next article]
From: [email protected]

Subject: X Windows Problem
Message-ID: <[email protected]>
Date: 5 May 92 20:51:25 GMT
Sender: [email protected]
Reply-To: [email protected]
Organiza
particular problem could be with the MCC-interim release, or GCC, or 0.95c+,
or virtual consoles, or swapping, or who knows. The point is, that's the
only problem I've encountered, and I swap a lot.


[next article]
From: [email protected]

Subject: X Windows Problem
Message-ID: <[email protected]>
Date: 5 May 92 20:51:25 GMT
Sender: [email protected]
Reply-To: [email protected]
[email protected]>
Date: 5 May 92 20:39:35 GMT
References: <[email protected]>
Sender: [email protected] (NNTP News Poster)
Organization: IBM T.J. Watson Research Center
Lines: 26
Disclaimer: This posting represents the poster's views, not necessarily those of
IBM
Nntp-Posting-Host: shravani.watson.ibm.com

Sigh! This is probably the best candidate for the most asked question
in Unix.

The concept of executing a program is *very* different under Unix than
[email protected]>
Date: 5 May 92 20:39:35 GMT
References: <[email protected]>
Sender: [email protected] (NNTP News Poster)
Organization: IBM T.J. Watson Research Center
Lines: 26
Disclaimer: This posting represents the poster's views, not necessarily those of
IBM
Nntp-Posting-Host: shravani.watson.ibm.com

Sigh! This is probably the best candidate for the most asked question
in Unix.

The concept of executing a program is *very* different under Unix than
unthe program execution terminates. So, your program is
certainly doing the chdir() properly, but it doesn't affect the
environment for the process the shell is running under. When your
program execution stops, that environment and that current directory
pointer is gone. Your shell is pointed to exactly where it was before
cdd execution began.

To write a new 'cd' you have to modify the shell itself. Under Linux,
that will mean changes to bash or ash. If bash, you might be able to
do this with a shell function. Exactly what does your cdd do?
Perhaps we can help you implement it.

--
rajat ([email protected])




Leave a Reply