August 2002 - Oberon - mailman3.inf.ethz.ch

Narrow Displays and Oberon Language
by Paul Reed 23 Aug '02

23 Aug '02

> From: GitM > > The OS is not ONLY about exercising the hardware. It is also about > > communication with the USER. > From: "Thomas Frey" <frey(a)inf.ethz.ch> > Therefore the original Ceres workstation had a 1024x800 display > resolution Thomas, I totally agree with you. As I've said, I have a Ceres 3 on my desk and its monitor is a modified Moniterm VCX1000 manufactured in Minnetonka, MN, in the US of A way back in March 1990. My guess is that the monitors cost ETH more than each Ceres, anyone from ETH in that era care to comment? :) The point is, it's a 21" screen, and Oberon's beautifully crisp and clear at 1024x768 (viewable area 17"). The first time I got the same experience with other hardware that I could afford was last year, when I bought a Sony VAIO with a really nice 1024x768 TFT display (tape measure again: 14" viewable area). I think this demonstrates how far Wirth and Gutknecht were ahead of their time, and so it is understandable that they didn't feel the need to pander to the conventions being tentatively established on how GUIs should work - it was far from a foregone conclusion! As has widely been observed, departing the "bandwagon trail" allowed them to simplify greatly the way the whole system worked. For some people, it's too simple (like not having columns, or overloading the mouse instead of having to remember keyboard shortcuts). But although I have made great efforts to adapt Oberon to legacy hardware (e.g. narrower displays), I view these adaptations as "specialist applications" and I wouldn't expect the maintainers of ETH Oberon to be particularly worried about them (I hope you're reading this Pieter :]). I sympathise with people's desires to make Oberon run on diverse hardware (because I do it myself) but it is impossible to do this without cutting at the very heart of the design principles which make Oberon great. It strikes me that taking a system like Native Oberon and trying to make it usable on 640x480 is like trying to make a motorbike by sawing a car in half. > From: Frank van Riet <Fvanriet(a)spescom.com> > Most of the traffic on the mailing list is devoted to the OS aspects of > Oberon. I'd like to digress from > this for a while and get some feedback on the language itself. First of > whatever I say is only aimed at > Oberon 1 and 2 i.e not Active Oberon, although some of it may be applicable. > I have used Oberon in developing > commercial software for some time. I'd like to know if anyone else has been > doing the same. I have the following > comments on some limitations that I have experienced. Some of my comments > are specific only to the ETH > implementation of Oberon while others are fundamental to the language. > > Please note that this is not an attack on the language, I'm asking :) It's always wise to include a caveat like that - we programmers are sensitive people at heart! :) I've been using Oberon as my commercial programming language since developing a more commercially-oriented compiler based on Project Oberon in 1997 (see JMLC 2000). I've used it on everything from a questionnaire data entry program on DOS, through delivery note software on Win32, to CGI scripts on FreeBSD (see the search system at http://www.rexfeatures.com) I find Oberon to be the most productive development environment I've ever had (I've been programming for twenty years). However, I sympathise with your comment about the lack of unsigned types and #ifdef, since I did at first miss them from my C programming days. > 1) The lack of unsigned data types is a great annoyance. Sure there are ways > of getting around this, but > I cannot see that Oberon has gained anything as a language by not > supporting unsigned types. Sure > it makes the compiler simpler, but not significantly. Perhaps it is > because of the potential complexities > of mixing signed and unsigned types in expressions ? This also does > not seem like a convincing argument. > It could simple have been disallowed. Having implemented a compiler, the addition of more basic types makes me cringe, but even Java took the view that there were certain types you must have. I don't think it would be that difficult to add them, but as Patrik will probably tell you :) the combinatorial explosion of type conversions (e.g. inclusion) within the compiler would indeed make it much bigger. Disallowing some of these conversions would draw complaints from fans of type inclusion. :) Wirth's view has always been to stick to the essential, and so he would I'm sure say that unsigned types are just "nice to have". I don't use SHORTINT a lot, but an unsigned byte is a pretty fundamental unit on any normal (non-Turing :]) computer, so I end up having to use CHR and ORD to maintain bytes using CHARs. I agree this is unnatural, but I live with it because my compiler is more maintainable with less types. I know that's a personal view. :) One advantage of a lack of unsigned types is that it makes me a better programmer, because I think much more carefully about the full range of my variables than I did with C. This amused me recently when I noticed that in BSD the byte-range available for locking a file is only half what it should be due to signed-unsigned design failure. This is a problem for Samba, which must maintain the DOS byte-range locking semantics, which are correct (a rare example of DOS > Unix). :] Would any computer scientists like to comment about the educational value of fewer basic types, and therefore a simpler language? > 2) In developing large systems for different platforms, conditional > definintions are a real life saver. > (e.g. (Borland?) Pascal's $IFDEF) I'm not sure if this is a language > or an implementational issue, although I suspect it is the former. Apart > from having code for differing platforms. Conditionals will > get rid of the clutter of debugging code > > CONST > debug = TRUE; > ;;; > IF debug THEN .... > > which is painfully inefficient. > > The below is perhaps more related to the ETH implemetation. Others may very > implement these differently. I get round the lack of #ifdef by keeping machine- dependent code in different (parallel) directories, compiling the one I need when necessary. I admit that this sometimes results in similar or identical code being duplicated in at least some cases. However, there is one huge advantage to a lack of conditional compilation: you are developing the same program as you release. Wirth says that Tony Hoare commented on the switching off of array bounds checking for release programs: it's like wearing arm-bands when swimming in a pool, and then abandoning them when at sea! I remember my shock in a meeting with Microsoft back when Excel 3.0 came out (.exe on 1 floppy): they boasted that the debug version was over 10 megabytes! ("And that's good?" I thought...) > 3) Dynamic array headers: Why was the decision made to to stick the header > in the middle of the structure > and not in-front as with other structures. Not only is it > non-intuitive nit having the pointer point > to the firts element, but it would also make language > interoperability very difficult. Let alone the > nightmare of porting older code in which this was not the case... Can't comment on this one - I think it was done to support garbage collection of dynamic arrays of structures, something I don't support. I point to the beginning of the array. :) > 4) Pragmas are only allowed on a per module basis. It would be very usefull > to disable type guard checking > in many cases, simply for the sake of efficiency. True it > compromises security, but why allow it > at all then. I agree in general that if you have control over a compiler, it should be fine-grained. But I am happy with no guard checking at all (see my comment about swimming above). Instead of the cost of a guard at every access, I insert ASSERT() statements where necessary to enforce invariants. > As an aside does anyone know whether read-only exports are still supported ? > Frank >--------------------------------------- >Frank van Riet (Software Developer) >Datavoice (Pty) Ltd >Snail mail PO Box 582 > Stellenbosch 7599 > South Africa Again, can't comment but aren't they like GOTO? :) I think in Oberon-SA, Wirth disallowed exporting variables completely - computer scientists say you should have exported procedures to set and get the value. I know, I know - you are concerned about efficiency. :) Paul Reed

2 1

a comment
by Josef Sedlacek 23 Aug '02

23 Aug '02

Hi together Oberon is a system which proofed during last years to be a very powerful tool for writing industrial software. In such an environment the stability of system is crucial. One hour fault of system costs at certain applications $20000. Another important point is to be able to write the software fast and with few errors in order to satisfy the more and more tight wishes of the customers. Also this is very comfortably possible using Oberon. Perhaps we all could be a little bit more positive. Regards Josef Sedlacek -- Company: Radiar, Dr. J. Sedlacek, CH-7554 Sent Tel: +41 (81) 860 06 60 Fax: +41 (81) 860 06 62

1 0

Re (2): [Oberon] Identify Calling Command
by muller＠inf.ethz.ch 23 Aug '02

23 Aug '02

> Thanks a lot, Pieter, > that's exactly what I need. I need it for the following: consider the Procedure Reading the following description, it seems you'll also need the procedure name, not just the module PC offset. It seems that your calling procedure is always going to be a command, so you could run through the mod.cmds (in Kernel.ModuleDesc) array to look for the matching command in the module descriptor, based on its .adr field. The .adr field stores the entry point of the command procedure, so you'll have to search for the next lower address in the array, based on the return address from the procedure. Hope you follow what I'm trying to say, otherwise I could be more explicit :-) -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

2 1

Re: [Oberon] System Freeze in Oberon System
by Patrik Reali 23 Aug '02

23 Aug '02

----- Original Message ----- Subject: Re: [Oberon] System Freeze in Oberon System > Pieter Muller writes: > Yes, this indeed seems to be a problem. The Decoder shows that the > problem is that the copying of the value parameter in dosomething > is done from low memory to high memory. In some circumstances this > can also cause a crash in Native Oberon and Aos. > > A possible fix would be to do the copying in the other direction. > Compiler-Patrik, are you listening? :-) This time I was listening :-) Anyway, till the end of october my time for Oberon will be rather limited, and I will be fixing the urgent problems. I've prepared a fix for this problem for both OP2 and Paco. The only problem is, I'm only able to test it on the compilers by bootstrapping them (which was fine), but have no chance to test it by compiling the whole system before two weeks. So it would be nice if somebody could please make a quick rebuild to validate my fixes. About the OP2 fix: * in OPC.Enter, substitute MoveBlock with MoveBlockReversed (this already solves the ploblem) * in OPL.GenRepMovs, I wrote an optimized version that tries to make REP MOVSBs for backwards moves whenever possible (like in the forward REP MOV implementation). This change is optional but recommended for performance reasons About the Paco fix: I took the stack-touch approach: beginning from the top of the destination memory block, the block is touched every 4096 bytes (one memory page). This approach is simpler to implement, as Paco has no reverse copy block operation, and should also fit both back-ends (Bernhard please confirm for the StrongARM!). The proposed fixes are in the attachment. Ciao, Patrik --------------------------------------------------------------------- OP2 Changes: OPC.Enter (use MoveBlockReversed instead of MoveBlock) PROCEDURE Enter* (proc: OPT.Object; dataSize: LONGINT; node: OPT.Node); VAR par: OPT.Object; x, z, t0, t1, size: Item; step, scale: SHORTINT; useRef: BOOLEAN; BEGIN (* !!later due to a bug this procedure looks no longer very nice *) useRef := (proc # NIL) & (proc.sysflag # 0); IF proc # NIL THEN OPL.FixupLocalProcCall (proc); (* fixup local procedure calls and assign target pc to procedure *) par := proc.link ELSE par := NIL; END; Gen1 (enter, dataSize, node); WHILE par # NIL DO (* copy val parameter SDynArr, OpenArr *) IF par.mode = Var THEN IF (par.typ.comp IN {OpenArr, SDynArr}) THEN MakeVar(x, par); TypeSize(x, size, step, scale); ASSERT(step IN {OPO.Bit8, OPO.Bit16, OPO.Bit32}); ASSERT(scale IN {OPO.Scale1, OPO.Scale2, OPO.Scale4}); load(size); ASSERT(size.mode=Reg); Gen2(neg, t0, size); z.mode:=RegRel; z.adr:=ESP; z.inx:=t0.adr; z.scale:=scale; z.typ:=OPT.linttyp; loadAdr(z); OPL.Instr [pc-1].hint := OPL.useESP; IF step # OPO.Bit32 THEN (*clear the last 2 bits -> grows down!*) z.typ := OPT.linttyp; MakeCon(t0, OPT.linttyp, -4); t1 := z; Gen3 (and, z, t1, t0); OPL.Instr [pc-1].hint := OPL.useESP END; MoveBlockReversed(z, x, size, step); MakeVar(x, par); x.typ := OPT.linttyp; z.mode:=Reg; z.adr:=ESP; Move(x, z) ELSIF par.typ.comp = DynArr THEN MakeCon(x, OPT.linttyp, 0); GenPush(x); (*allocate*) MakeVar(z, par); x.mode:=RegRel; x.adr:=ESP; x.offs:=0; x.inx:=none; x.typ:=par.typ; x.descReg:=none; CopyDynArr(x, z); GenPop(x); MakeVar(z, par); Move(z, x); ELSIF useRef & (par.typ.comp IN {StaticArr, Record}) THEN (* copy array, record *) z.mode := Var; z.typ := OPT.linttyp; z.node := NIL; z.adr := par.linkadr; z.mnolev := par.mnolev; x.mode := VarPar; x.typ := OPT.linttyp; x.adr := par.adr; x.node := NIL; x.mnolev := par.mnolev; MakeCon (size, OPT.linttyp, par.typ.size); MoveBlockReversed (z, x, size, OPO.Bit8) END END; par := par.link END END Enter; OPL.GenRepMovs PROCEDURE GenRepMovs (VAR instr: Instruction); (* repMovs *) VAR src, dest, nofElem, tmp: SHORTINT; BEGIN FindLoadReg (instr.dest, dest); ASSERT (dest IN {EAX..EDI}); IF dest # EDI THEN IF instr.dest >= 0 THEN AssignThisReg (instr.dest, EDI) ELSE GetThisReg (EDI) END; OPO.GenMOV (RegReg, EDI, dest, noInx, noScale, noDisp, noImm); IF ~(dest IN {ESP, EBP}) THEN regTab [dest] := free END; END; FindLoadReg (instr.src1, src); ASSERT (src IN {EAX..EDI}); IF src # ESI THEN IF instr.src1 >= 0 THEN AssignThisReg (instr.src1, ESI) ELSE GetThisReg (ESI) END; OPO.GenMOV (RegReg, ESI, src, noInx, noScale, noDisp, noImm); IF ~(src IN {ESP, EBP}) THEN regTab [src] := free END; END; FindLoadReg (instr.src2, nofElem); ASSERT (nofElem IN {EAX..EDI}); IF nofElem # ECX THEN IF instr.src2 >= 0 THEN AssignThisReg (instr.src2, ECX) ELSE GetThisReg (ECX) END; OPO.GenMOV (RegReg, ECX, nofElem, noInx, noScale, noDisp, noImm); IF ~(nofElem IN {ESP, EBP}) THEN regTab [nofElem] := free END; END; IF (instr.inx = AL) & (instr.hint = noHint) THEN (*8-bit move, forward move*) GetReg8(tmp); OPO.GenMOV(RegReg, tmp, CL, noInx, noScale, noDisp, noImm); OPO.GenShiftRot(SHR, ImmReg, ECX, noBase, noInx, noScale, noDisp, 2); OPO.GenTyp1(AND, ImmReg, tmp, noBase, noInx, noScale, noDisp, 3); OPO.GenRepString(MOVS, EAX); OPO.GenMOV(RegReg, CL, tmp, noInx, noScale, noDisp, noImm); OPO.GenRepString(MOVS, AL); FreeReg(tmp) ELSIF (instr.inx = AL) & (instr.hint = 1) THEN (*8-bit move, backward move*) GetReg(tmp); OPO.GenMOV(RegReg, tmp, ECX, noInx, noScale, noDisp, noImm); OPO.GenShiftRot(SHR, ImmReg, tmp, noBase, noInx, noScale, noDisp, 2); OPO.GenTyp1(AND, ImmReg, CL, noBase, noInx, noScale, noDisp, 3); OPO.GenRepString(MOVS, AL); OPO.GenTyp1(SUB, ImmReg, ESI, noBase, noInx, noScale, noDisp, 3); OPO.GenTyp1(SUB, ImmReg, EDI, noBase, noInx, noScale, noDisp, 3); OPO.GenMOV(RegReg, ECX, tmp, noInx, noScale, noDisp, noImm); OPO.GenRepString(MOVS, EAX); FreeReg(tmp) ELSE OPO.GenRepString (MOVS, SHORT (instr.inx)) END; IF regTab [ECX] = Occupied THEN FreeReg (ECX) ELSE DecReg (ECX) (* nofElem *) END; IF regTab [ESI] = Occupied THEN FreeReg (ESI) ELSE DecReg (ESI) (* src *) END; IF regTab [EDI] = Occupied THEN FreeReg (EDI) ELSE DecReg (EDI) (* dest *) END END GenRepMovs; Paco changes: PCC.LocalArray PROCEDURE LocalArray*(code: Code; par: PCT.Parameter); VAR x, size, dim: Item; reg, mask: PCLIR.Register; aligned: BOOLEAN; offs: LONGINT; reg2, const: PCLIR.Register; begin, end: Label; skip: BOOLEAN; BEGIN ASSERT(~par.ref); MakeItem(x, par, 0); LoadAdr(code, x); offs := x.offs; (*compute size*) dim.mode := RegRel; dim.adr := x.breg; dim.offs := x.boffs; dim.type := PCT.Int32; GetArrayBaseSize(code, size, x); aligned := (size.mode = Const) & (size.value MOD 4 = 0); DOp(code, PCS.times, size, dim); skip := (size.mode = Const) & (size.value < 4096); Load(code, size); GenConv(code, PCLIR.convu, size, PCLIR.Address, FALSE); PCLIR.EmitLoadConst(code, const, PCLIR.Address, FALSE, 0); PCLIR.Emit12(code, PCLIR.add, reg2, PCLIR.SP, const); (*allocate*) PCLIR.Emit12(code, PCLIR.sub, reg, PCLIR.SP, size.adr); IF ~aligned THEN PCLIR.EmitLoadConst(code, mask, PCLIR.Address, FALSE, 0FFFFFFFCH); PCLIR.Emit12(code, PCLIR.and, reg, reg, mask); END; PCLIR.Emit01(code, PCLIR.loadsp, reg); IF ~skip THEN DefLabel(code, begin); PCLIR.EmitLoadConst(code, const, PCLIR.Address, FALSE, 1000H); PCLIR.Emit12(code, PCLIR.sub, reg2, reg2, const); end := code.pc; PCLIR.Emit02C(code, PCLIR.jb, reg2, PCLIR.SP, -1); PCLIR.EmitLoadConst(code, const, PCLIR.Int8, FALSE, 1000H); PCLIR.EmitStoreRelative(code, 0, reg2, const); PCLIR.Emit0C(code, PCLIR.jmp, begin); PCLIR.FixList(code, end, code.pc); PCLIR.Emit0C(code, PCLIR.label, 0); END; (*move*) PCLIR.Emit03(code, PCLIR.move, x.adr, reg, size.adr); (*store address*) PCLIR.EmitStoreRelative(code, offs, PCLIR.FP, PCLIR.SP) END LocalArray; ----- End of forwarded message from Patrik Reali -----

2 1

counting chars when using a proportional font
by Charles Angelich 22 Aug '02

22 Aug '02

>From: muller(a)inf.ethz.ch >Date: Wed, 21 Aug 2002 19:04:05 +0200 >To: oberon(a)inf.ethz.ch >Cc: muller(a)inf.ethz.ch >Subject: Re: [Oberon] ETH N-O Native/Beta directory display >Reply-To: oberon(a)inf.ethz.ch > >Charles Angelich <cangelich(a)famvid.com> wrote: >> 640x480 video display driver: >> System track = 36 Oberon10.Scn.Fnt chars >> User track = 63 Oberon10.Scn.Fnt chars > >Since Oberon10 is a proportional font it makes no sense to >count the number of characters. Or did you mean Courier10? It would've "made sense" to have counted these characters before defining the "small display" within Oberon code to be unable to display the entire menu bar within the system track. It would've made sense to count these characters before allowing documentation, tutorials, .Tool files, to all be formatted beyond the maximum space(s) available to those using the "small" display as defined within Oberon source code. I have found references to smaller displays within existing Oberon modules the problem is that after coding this no one "counted the available character space" and ignored the disappearing text off the right side of the 640x480 screen display. Columnar alignment of fields is basic to a user interface and you tell me it makes no sense? I would say ignoring this makes no sense. The OS is not ONLY about exercising the hardware. It is also about communication with the USER. If using a proportional font as the default for Native Oberon is the crutch to justify the inability to do clean standard displays then I would submit that a default proportional font was a mistake. Options would be: #1: auto-detect display sizes and word-wrap the display to fit the viewer being used. #2: auto-dectect display sizes and incr or decr the font size to fit the viewer being used. #3: ignore this and continue development of BlueBottle for Pentium users at the bleeding edge of technology. Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

2 1

Re: [Oberon] System Freeze in Oberon System
by muller＠inf.ethz.ch 22 Aug '02

22 Aug '02

Patrick.Hunziker(a)unibas.ch wrote: > All versions of Windows Oberon including the current release from 05/2001 are > shot down by this module: Yes, this indeed seems to be a problem. The Decoder shows that the problem is that the copying of the value parameter in dosomething is done from low memory to high memory. In some circumstances this can also cause a crash in Native Oberon and Aos. A possible fix would be to do the copying in the other direction. Compiler-Patrik, are you listening? :-) > Concerning state of the windows versions: > the 'current version' 05/2001 is very unconfortable to use compared to 12/2000 > because the new version of the 'Packages' module does not allow reinstallation > of .oaf packages that are already registered in their current version, even in > the case where small portion of the modules of the content of the package has > been deleted. I've also had problems with this on Windows Oberon, and had to mess around in the Registry to work around it. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Oberon list password
by muller＠inf.ethz.ch 22 Aug '02

22 Aug '02

Patrick.Hunziker(a)unibas.ch wrote: > (Lieber Pieter > ich moechte meine Mailinglist Teilnahme auf meine andere Email: > Patrick.Hunziker(a)unibas.ch umbestellen, habe aber mein Passwort vergessen.) If you forget your mailing list password, you can have it mailed to you by typing your email address at "Changing your Oberon List Subscription" on the page: http://www.lists.inf.ethz.ch/mailman/listinfo/oberon and clicking "Edit Options", followed by "EMail My Password To Me". -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

System Freeze in Oberon System
by Patrick.Hunziker＠unibas.ch 22 Aug '02

22 Aug '02

(Lieber Pieter ich moechte meine Mailinglist Teilnahme auf meine andere Email: Patrick.Hunziker(a)unibas.ch umbestellen, habe aber mein Passwort vergessen.) System Freeze with stack overflow : All versions of Windows Oberon including the current release from 05/2001 are shot down by this module: MODULE Temp; PROCEDURE dosomething(a: ARRAY OF CHAR); BEGIN END dosomething; PROCEDURE Do*; VAR A:ARRAY 1000000 OF CHAR; BEGIN dosomething(A) END Do; END Temp. Concerning state of the windows versions: the 'current version' 05/2001 is very unconfortable to use compared to 12/2000 because the new version of the 'Packages' module does not allow reinstallation of .oaf packages that are already registered in their current version, even in the case where small portion of the modules of the content of the package has been deleted. This is because packages do not check for consistency. Loss/deletion of a single file thus leads to major problems, often solved only be reinstallation of the whole system. For the 05/2001 version, this is a "killer bug" in my opinion, which makes it preferable to use the 12/2000 version for development although several improvements could be found in 05/2001, and for running of applications only, I prefer the latter one. Patrick ------------------------------------------------- This mail sent through IMP: igor.urz.unibas.ch

2 1

Bluebottle
by Soren Renner 22 Aug '02

22 Aug '02

Some of you may remember me. I took a vacation from the internet, and from programming. As soon as I lay hands on a box that'll run Bluebottle, I'll start again. Anyway, to the authors of the Bluebottle bootable CD -- it looks great, but why didn't you include TuringCoatWnd.Mod, the reaction-diffusion pattern demo that I wrote a year ago? If you put it back in the distribution I'll write more demos. sr

1 0

N-O Native font errors
by Charles Angelich 22 Aug '02

22 Aug '02

>From: muller(a)inf.ethz.ch >Date: Wed, 21 Aug 2002 19:04:05 +0200 >To: oberon(a)inf.ethz.ch >Cc: muller(a)inf.ethz.ch >Subject: Re: [Oberon] ETH N-O Native/Beta directory display >Reply-To: oberon(a)inf.ethz.ch > >Charles Angelich <cangelich(a)famvid.com> wrote: >> 640x480 video display driver: >> System track = 36 Oberon10.Scn.Fnt chars >> User track = 63 Oberon10.Scn.Fnt chars > >Since Oberon10 is a proportional font it makes no sense to >count the number of characters. Or did you mean Courier10? >Not a good idea to make non-backward-compatible changes in a >low-level module. Neither is field padding with a proportional >font. While viewing the existing installed fonts within NO Native 08.12.00 to verify my suspicions that the space char was defined as one-half of a space char I found some surprises. Within the same font size I found that the normal font space was not always the same size as the bold font space size. This is within the same font size! If I change a phrase within a paragraph to bold the spacing would also change! I also found that TAB was not _always_ four one-half-spaces, in some fonts it is smaller than that for no apparent reason? You not only have a proportional font you also have a not-proportional font within the proportional fonts. I also added a dot within the ZERO char to assist in reading Oberon source code when the capital "O" is being used along with the "0" (zero) char. Not pretty really but easier on the eyes IMO. Now you can tell me that alerations to correct this are verboten. ;-) Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

1 0