[Oberon] SystemV- Heap + Module Space

[Chris Burrows]

> -----Original Message-----
> From: Jörg [mailto:joerg.straube at iaeth.ch]
> Sent: Sunday, 6 January 2019 5:32 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] SystemV- Heap + Module Space
> 
> Yes and no.
> From an encapsulation point of view you're right.

That is how it is done in ETH Oberon for Windows. There are local named (camelCapped) CONSTs for each error code defined in Win32.Modules.Mod: 

CONST
	done = 0;
	fileNotFound = 1;
	invalidObjFile = 2;
	corruptedObjFile = 4;
	cmdNotFound = 5;
	moduleNotFound = 6;
	notEnoughSpace = 7;
	refCntNotZero = 8;
	cyclicImport = 9;
	incompImport = 16;

Note the additional codes; 3 is a mystery value this time ;-)

Error string mapping to these codes is performed in the same module by PROCEDURE ErrMsg(res: INTEGER). Interestingly this doesn't just store the error message in a string, it actually calls a Kernel32 procedure to output the string. However, the output procedure is a variable declared as OutputStringProc* = PROCEDURE (VAR str: ARRAY OF CHAR); presumably to allow runtime control of how the output of those strings is to be handled.

> Let's assume you want to offer the error messages in different
> languages. Then it's questionable if you want to have the text
> translations in the Inner Core.
> TextFrames (with the translation strings) is in the Outer Core and
> can be exchanged more easily.
> 

While that is true - I consider that to be a red herring in the context of named vs. anonymous constants. Internationalisation isn't something that can be readily added on to an existing software system as an afterthought. It has to be designed in from day one - not just the software, but also all documentation, help files, access to technical support  etc. etc.

Chris.