- Oberon - mailman3.inf.ethz.ch

None
by None 02 Oct '26

02 Oct '26

URL: ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/Update/Alpha/readme.txt 2. After booting Oberon-0, Install.Tool is opened automatically. It starts with: > Oberon-0 is a small ramdisk-based system > for configuring the real Oberon system. > For an introductory text, move the mouse > cursor to Edit.Open below and click the > middle button (or double-click left). > Edit.Open Introduction.Text 3. After executing Edit.Open above, Introduction.Text is opened. It starts with: > This tutorial introduces the concepts of the Oberon user interface necessary > to continue the installation process. If you are familiar with Oberon, skip it. ... and goes on to explain Oberon concepts like system track, user track, viewer, scroll bar, menu bar, viewer title, scrolling, command execution, text editing, text selection, resizing viewers. and closing viewers. All in about two pages. URL: ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/Update/Alpha/Build/Build.zip Install.Tool and Introduction.Text ( Edit.Open ^ ) These are simple text documents without large fonts, so that normal TextFrames can be used. Colour and 10pt bold or italic are fine. (They could also be Script documents, with arbitrary fonts, but those fonts would have to be included in the Oberon-0 environment, increasing its memory requirements). 4. Installation continues through steps 1 to 3, documented by the relevant tool texts: Install.Tool, InstallFiles.Tool, Configuration.Tool. ( Edit.Open ^ ) 5. After booting the installed system, the System.Tool is opened automatically with the following at its start: > Script.Open System.Text > click middle mouse button (or double left) > on Script.Open above for introductory text 6. The System.Text starts: > Blue colored parts in this document are Oberon commands. They can be > activated simply by pointing at their beginning with the mouse and > then clicking the middle key (or, if a three button mouse is not > available double click the left key). For example, the Script.Open > UserGuide.Text command can be activated by clicking middle at > Script.Open. It connects to a brief tutorial for new Oberon users. By > its activation, an extra viewer is popped up that can be used, > manipulated and closed again independently. The first link opens the UserGuide.Text, which goes into more detail on operating the system. System.Text documents the configuration of the system, and installation of additional packages. URL: ftp://ftp.inf.ethz.ch/pub/ETHOberon/Native/Update/Alpha/Build/System.zip System.Text and UserGuide.Text ( Script.Open ^ ) The intention is that after reading the documention up to this point carefully, the new user will be able to find his/her way around the system, installing additional packages like Gadgets and Docu, and exploring the documentation there. I find this "documentation path" sensible, even though the contents of the last two documents leaves room for improvement. Suggestions are welcome. Preferably send me edited documents in the same format as the original. BTW The Windows Oberon approach of opening the Gadgets document Distribution.Text automatically is much simpler, but this is not possible in Native Oberon under the restrictions of a single install diskette. -- Pieter P.S. To see how things are progressing with the alpha version, read: http://www.oberon.ethz.ch/native/WebAlpha.html -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

None
by None 02 Oct '26

02 Oct '26

and parts are semi-functional what basis is there for pushing forward into BlueBottle? If BB is built using Native Oberon `parts' the foundation is shakey IMO. Newer faster hardware won't hide the lack of completeness nor will it overcome the need to document and instruct in the use of Oberon. 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

None
by None 02 Oct '26

02 Oct '26

"two button hack" as you call it will disappear in new versions. There is a decided prejudice to hold onto the three button mouse as though it was the central nexus of Oberon. I am saying that interest in a three button mouse died off over a decade ago and will turn away as many potential users (or more) than it will attract because it is nonconformist. The harsh attitude to get a three button mouse or leave will finish off those new users who try to work around it leaving ZERO new Oberon users. [...] > So I recall some guy talking about a "new and weird" thing called Oberon > when I was on College (we were using Modula2 that time - hey! it was > 1992!!!), and I thought "It's time to learn that thing". I installed Oberon at approximately that time and when I saw what it was decided I didn't have time for it. That was my _first_ install of Oberon. [...] > I'm not using Oberon to use it the way I always had used other software. > I'm trying hard to use Oberon to learn NEW WAYS to use and write > software. You wouldn't know it but I really do understand this. I do think we've been handed some bad habits by Microsoft and others and anything that can give us a new perspective is a good thing. > I will use Oberon on my comercial life? Probably not (but should be nice > port it to ARM7500 I'm hacking know). But I want to break old bad > habits, and maybe Oberon can help me on it. You may be entirely correct if that is what you want from Oberon you may get just what you want. :-) >> It's also true that if the full compliment of COMs were supported by >> Native/Beta rather than Alpha which not only has incomplete install >> disk image files it apparently can't unzip it's own source code then >> by now I would reading this from within Oberon wouldn't I? > > Yes. You right. > > However, I think there's a reason some code is called "stable", others > are called "Beta", and even more are called "Alpha". > > Newbies should begin with stable versions. I did. I was _told_ to switch to Alpha or I would not have tried an alpha release. I have had to drop back to Native/Beta since Alpha is incomplete in ways I cannot work around. > Man, go play with Oberon/Win32 (or linux) like I'm doing before trying > something Alpha! Use the Learning Curve in your favor, not against you! I'm not really a Linux user nor all that fond of Win32 either. I dabble in both but normally use DOS or W31. >> You prefer to make a newbie responsible for oversight at ETH to >> complete one version before starting another new version. I think >> that is misguided logic. > > I think it's lack of time. Oberon don't have all the coding-force Linux > and *BSD has. Lack of time does not explain the ability to generate multiple unfinished versions plus BlueBottle. The time to create multiple versions would have been better spent completing what had already been started IMO. >> > Else stick to MS. >> >> I get this feedback far too frequently. If you, or any other Oberon >> users continue with these remarks you will be recieving similar >> comments from me in the future. Correct your attitude. > > Pal, if you are getting this kind of feedback so many times, don't > there's a least a little chance the problem isn't in the rest of the > World? Pal, I get this same flack when I point out inconsistencies to the Linux crowd. They don't intimidate me either. Anyone who can only start software and never finish it doesn't intimidate me. > Is just OUR attitude the one must be corrected? If you want Oberon to ever be acceptable to the rest of the world then yes, only YOUR attitude. > I think there is better ways to be understood. Possibly but I'm trying the best way I know how. >> There is no problem with my "views" as they are. I am new to this >> OS and am being sent up blind alleys to find myself blocked by >> one unfinished version after the next then told to buy a special >> mouse or move on.[...] No, they were known to be a work-in-progress and I didn't have the time. > Oberon, AFAIK, is NOT a mainstream project. You can't expect the same > code cohesion you expect from Linux or BSD. There are no POSIX standart > to lay on. There's no old mistakes to be avoided. > > And people make mistakes. It is not a mistake to generate multiple unfinished versions of Oberon then expect a total newbie to find a way to deal with it. It is just wrong. >> I have been disappointed by Native, Native/Alpha, and Native/Beta >> for many reasons and not petty reasons either. > > Yes, I am disappointed with some features from Oberon myself. The lack > of enumerated types among them. But what I can say? I'm not disappointed by a lack of "features" unless you consider being functional/useful a "feature". > "if you can't stand the heat, get out of the kitchen" ??? Save it, I'm not intimidated enough to care. > If you think the way Oberon is going is that bad, what more else can we > do? "We"? I see no "we" here. >> I am disappointed that text runs off the right side of the screen as >> we debate the need to correct the error. >> I am disappointed that >> ZipTool cannot unzip Source*.Zip files. > > Yes, it is a mess. Maybe a horizontal scrool bar should be implemented? > Who here is so mad with this that are going to fix that? No scroll bar is needed. The right frame needs to be moved to the left (widened). Big deal huh? >> Need I go on? > > Yes. I think the things are driving you mad should be said, you are > plain right on it. At times it sounds more like "go away" to me. >> Anyone familiar with W31 or W9x will tell you cut-n-paste is old news. >> Get over it. > > And anyone who used some flavor of Unix/X-Window will tell YOU MS's > cut-n-past is BAD news. It doesn't require multiple button presses to use it. > There are people who thinks YOUR way of doing things isn't THE BEST way > to do it. I don't own a "way". I'm trying to express one simple fact that everyone is determined to ignore. People don't normally own a three button mouse and aren't going to buy one for an unfinished OS they don't know how to use yet. Life just isn't like that. [...] >> I had cut-n-paste in DOS for all the years I used it by adding a TSR called >> CTRLALT and it was a more global user-friendly cut-n-paste than any I've >> seen since btw. > > It's your opinion, and it is welcomme to me. But isn't the only opinion. You've not tried CTRLALT so, yes, you have to trust me to not lie. It's available from my tech website on the utilities page if you have a DOS to try it with. > In time, when I was in DOS, I used to copy-n-paste using Quaterdeck's > DeskView. And before that, on GEM. Desqview's cut-n-paste was awkward as I recall it. I used CTRLALT. Charles.Angelich DOS the Ghost in the Machine! Family And Friends wepages - Multimedia orginal stories with animation and sound, poetry, music, and photography: http://www.undercoverdesign.com/dosghost/faf Tech pages for DOS and W31 at: http://www.undercoverdesign.com/dosghost

1 0

None
by None 02 Oct '26

02 Oct '26

about needed changes and recent updates but they are not available at any location I am aware of. This was my reason for recommending that the notes be linked at the ETH Oberon webpages using <PRE></PRE> HTML until such time as they can be collated, sorted, reformatted or whatever is required to get them into more taditional HTML webpages. The "PRE" means preformatted text and being Courier font looks like dot matrix printouts. Not pretty but people need that information in this same decade, not another millenium. ;-) Charles.Angelich DOS the Ghost in the Machine! Family And Friends wepages - Multimedia orginal stories with animation and sound, poetry, music, and photography: http://www.undercoverdesign.com/dosghost/faf Tech pages for DOS and W31 at: http://www.undercoverdesign.com/dosghost

1 0

None
by None 02 Oct '26

02 Oct '26

The listing of available versions of Oberon links to various versions without a great deal of explanation as to why a new user should want one versus the other is confusing. The linking to Native seems inappropriate considering that Native is relatively obsolete. Not that Native/Beta is up-to-date but it would seem a better choice for those who intend to install a loopback (all in one FAT file) Oberon. When reading the documentation pages online each part begins to explain some portion of Oberon then gets sidetracked with exclusions for various versions. New users don't know or care about other versions and certainly don't need to be distracted by exclusions while trying to learn about their version of Oberon. It seems there was no desire to write separate up-to-date documentation for each version so that all versions are crammed together into a confusion of exceptions. Considering the diversity of file formats, and changes of command names I think it would be wise to have separate documentation and leave out all the exclusions? Difficult enough to become comfortable with the use of a two button mouse on a three button OS without being constantly reminded that whatever version you use others probably are using a different version with a different file system and different command modules. I could critique these pages line by line but I think anyone who looks at what is there objectively as a new user they would see what I see? Charles.Angelich DOS the Ghost in the Machine! Family And Friends wepages - Multimedia orginal stories with animation and sound, poetry, music, and photography: http://www.undercoverdesign.com/dosghost/faf Tech pages for DOS and W31 at: http://www.undercoverdesign.com/dosghost

1 0

None
by None 02 Oct '26

02 Oct '26

clear, important and appropriate to this discussion. Based on the work that I did in making the ISO_9660 compatible file system, I envision that a change to the file name scanner to include the "/" character in a file name would allow the command in the example to execute, and to give the results described, on a "flat" file system. Moreover, it would give additional power. I have some objections to this solution. You may also object to this solution. Can you explain why? From: "Ghost in the Machine" <cangelich(a)famvid.com> | > Let me explore the following user interface scenario. | > | > 1. A command of the nature | > System.Directories eMail/Y02/July/* | > produces list of file names that the user named and saved from email | > received in July 2002. | > | > Is this the sort of thing you are missing? | | Don't be patronizing. | | I want to be able to separate sets of files into subdirectories | not clump them all together in one huge directory. MSDOS | v2.1 had subdirectories - did you notice that? | |

1 0

None
by None 02 Oct '26

02 Oct '26

Philosophical Foundation 1. I want to make money and Oberon has a mix of novelty and completeness that may work. 2. I like Oberon and want to grow the user base to make its existance more assured. 3. I think society would be safer if software were based on well engineered open sourced systems. An open source, high quality, reliable operating system based on modules that is supported "commercially", and a sound educational program reinforce this foundation. | Aubrey, | | mcintosh(a)vima.austin.tx.us wrote: | .... | I believe a gentle and firm coordination of what already exists | can lead to a low overhead, low maintanence system that is useful | to a large number of individuals. I wish to avoid the opacity of | Microsofts Window's and its bloat. Openness is key. A small organization | lowers its operating expenses and keeps the cost to the consumer down. | ... > where the young become exposed to ... I remember the day I asked the old men how long it took them to get used to bi-focals, and *I really cared* what their answer was.

1 0

None
by None 02 Oct '26

02 Oct '26

1. The CD boot code. 2. A common network card driver. 3. A basic VGA driver, and advanced installer support. 4. Some type of file storage ability, whether RAMdisk, floppy, or perhaps FAT support. Diskless would probably be advantageous. 5. Attention to the sections of ECMA-119 and related documents that speak to multi-hardware boot environment support in CD-ROMs. All of these additional components other than 5 seem to be available in the Oberon community today, principally in the S3/ETH/Native/Bluebottle setting. Why V4 and not Bluebottle? 1. I have produced an entire doctoral dissertation using V4 for the entire production environment: data analysis, and document processing. I can speak with confidence and authority that it is stable and suitable. I have not heard a similar application claim from the S3 side (listening ...) 2. Bluebottle, on the face of it, it is not "bulletproof." Interesting, yes. Important, yes. Receiving much of my time, yes. Attractive because of color and motion, yes. Bootable from CD-ROM as is, yes. Suitable for mass distribution? What else is nice, given that a bootable system is demonstrated? 1. I am convinced that a 50 Mb download is a very large "activation barrier" that prevents more experimental use of Oberon I would make the boot core of the system contain a "net files" module. This 80-100 Kb core could be downloaded in a very short time, and pull in additional modules to local storage on an as needed basis. Subsequent boots would find an increasing inventory of relevant files on local storage. Individual files instead of a single image would be on well known distribution servers. With clever design, version updates would be painless using this incremental, intelligent transfer. 2. Micro-notary of files using PGP and the web of trust would mitigate against viruses. 3. CD-ROM archival is nice. I would like to explore an architecture that allows a first or new track to be written to the CD-ROM from the local storage at any moment in time. Mark the files on local storage for deletion on demand.

1 0

Math in the Oberon subsystem in A2?
by peter＠easthope.ca 27 Sep '26

27 Sep '26

Hi, I have a small module in the Oberon subsystem in A2 where a square root is needed. In my thinking, the module should "Import ... Math IN Oberon ..." and that will require Oberon-Math.GofUu and Oberon-Math.SymUu. For those I need to compile Oberon.Math.Mod and Oberon.Math64.Mod. For completeness, Oberon.Math32.Mod also. Otherwise make a Sqrt procedure in the module where needed. Any corrections before I try to create & compile the Oberon-Math*.Mod files. Thanks, ... P. -- mobile: +1 778 951 5147 Bcc: peter at e a s t h o p e dot c a projects: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Why are `*` and `^` interpreted by individual Oberon commands?
by նորայր 08 Sep '26

08 Sep '26

Hello, I have been thinking about the design of command arguments in the Oberon System, and I would be interested to hear the reasoning behind one particular choice. When I execute something like ``` Compiler.Compile * ``` the system does not expand `*` into some representation of the marked viewer and then pass that to `Compiler.Compile`. Instead, the `Compile` procedure receives the command arguments and itself recognizes `*` and obtains the appropriate text from the marked viewer. Similarly, with ``` Compiler.Compile ^ ``` it is the command procedure itself that interprets `^` and obtains the current selection. I find this interesting when comparing it with the Unix shell model. For example, with ``` ls * ``` the shell expands `*` first, and `ls` receives the resulting list of filenames. `ls` does not need to know that the user originally typed `*`. So I am wondering: why was the Oberon command system designed so that conventions such as `*` and `^` are interpreted by individual commands rather than by the system or command interpreter? It seems that system-level expansion could make commands simpler and establish a common argument mechanism: a command could receive a text/file argument without needing to know whether the user specified it by name, by `*`, by `^`, or perhaps by some future mechanism. On the other hand, I suspect there may be a reason why this would not fit the Oberon model. Perhaps `*` and `^` are intentionally not "argument expansion" at all, but ways for a command to interact with the state of the user interface, and therefore their interpretation belongs to the command. Was this an explicit design decision? And are there advantages to having commands interpret these conventions themselves rather than putting such interpretation into the command execution mechanism? I would be very interested in how people familiar with the Oberon system design think about this distinction. Thank you, norayr

3 4