Recent

Author Topic: Can FreePascal be used to create an internal or embedded DSL?  (Read 8866 times)

alpine

  • Hero Member
  • *****
  • Posts: 1038
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #60 on: August 17, 2022, 08:12:01 pm »
*snip*
Most likely, Forth is one of the many languages I have discounted because they either don't run on the machines I would be targetting or the syntax looks too different to BASIC or Pascal.
It was about how someone approached the particular problem with its own DSL. Not for the language itself. BTW BASIC was created in a similar way.

*snip*
This project wouldn't really be aimed at someone who wants to use a particular computer from their youth, as they can just use BASIC on a physical machine or in an emulator.
I can hardly imagine anyone doing it except out of nostalgic reasons.

This would be for someone who likes or uses more than one machine and wants to produce software for all of them plus modern machines, using one set of code.
*snip*
And who would want to do that? Where is the point?
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

Wysardry

  • Jr. Member
  • **
  • Posts: 69
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #61 on: August 17, 2022, 08:51:04 pm »
There is already software available that allows people to create code on a modern machine that will run on modern machines and multiple retro platforms, so there must be at least some demand for it.

CROSS LIB is an example of a game framework for vintage systems that can also be used for modern systems via GCC.

Lantern is a similar system for creating text adventures.

Several programming languages with multiple targets have already been mentioned in this thread.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #62 on: August 17, 2022, 10:14:46 pm »
There are plenty of other rabbit holes for me to dive down that would be a more direct route to where I want to end up.

Most likely...

Well, yes: you make a good point. But then spoil it with a "most likely" which suggests that you haven't done even basic research.

The important point about Forth is not the (pretty bad) language syntax, but the execution model.

Quote
I actually bought a used book on creating text adventures in UCSD Pascal a couple of years back.

I haven't seen any implementations for 8-bit home computers though, so I haven't explored it too thoroughly.

Right, so you don't know a thing about it.

It was for a long time significantly popular on Apple-II systems... but the important thing is /how/ it worked.

Quote
I will definitely be considering adding extra Z80 targets to FPC if it becomes part of the toolchain.

Although despite my goading you appear to have very little understanding that this is mainly an RTL rather than compiler issue.

Quote
Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.

And you reckon FPC is any different? And you really think you're going to get anywhere if "I hate C" is your overriding criterion?

Quote
I do know that it will be far from easy. I've been searching for potential solutions on and off for about two years now, trying to find compatible pieces of the puzzle.

And I've been doing the same for about 45 years. Need I say more?

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #63 on: August 18, 2022, 01:43:15 am »
Did you look at p-machine implementations at all? P6 is fresh, but first few were built in the seventies when resources were even more limited, so I do not see a problem comming from that side.

Which P6 ?

https://github.com/samiam95124/Pascal-P6     Last commit 4-5 years ago....

http://wirth-dijkstra-langs.org/  Hasn't processed FPC compatibility contributions sent 3 (4?) years ago.

Both seem to be quite stale.

https://sourceforge.net/p/pascal-p6/code/ci/master/tree/

Last change was in 2020
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #64 on: August 18, 2022, 09:05:14 am »
I wouldn't consider the ESP8266 even close as “miniscule”. It's simply an embedded platform just like the Pi Pico which Pascal can run very well on. More miniscule are the AVRs, especially the TinyAVRs and even there you can use Pascal ;)

I'd hardly call the Pico tiny, with 100s of Kb RAM and provision for several Mb Flash. And whenever one maxes-out an AVR one can simply move to the next one along the product range.

Okay, the ESP8266 has around a tenth of the RAM of the Pico, but it can also support several MB of Flash (e.g. here). And at least before the recent announcements of the W variants of the Pico the ability to use WiFi and Bluetooth was quite a selling point (though I personally would go with the ESP32 instead).

Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.

You are aware that FPC also has a relatively small circle of really active core developers? Also with our own workflow... However we are definitely open for merge requests as long as they adhere to a few things (e.g. not changing coding style or providing features that we don't consider in the spirit of Pascal).

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #65 on: August 18, 2022, 09:48:19 am »
Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.

You are aware that FPC also has a relatively small circle of really active core developers? Also with our own workflow... However we are definitely open for merge requests as long as they adhere to a few things (e.g. not changing coding style or providing features that we don't consider in the spirit of Pascal).

I must say that looking superficially at the example screenshots e.g. https://lemonspawn.com/wp-content/uploads/2020/08/trse_background.png I'm a little troubled at the extent to which the Turbo Rascal developers have departed from the standard Pascal syntax. For example, they've reverted to Wirth's original /* */ for comments and they're declaring arrays like
Code: Pascal  [Select][+][-]
  1. array[256] of byte
.

It might well be that their requirements were very similar to OP's and that they settled on something "Pascal-like" because it's usable rather than out of affection for the language and its traditions, but there's a risk that at some point in the future somebody will start arguing that FPC ought to have a TurboRascal mode.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #66 on: August 18, 2022, 01:07:11 pm »
Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.

You are aware that FPC also has a relatively small circle of really active core developers? Also with our own workflow... However we are definitely open for merge requests as long as they adhere to a few things (e.g. not changing coding style or providing features that we don't consider in the spirit of Pascal).

I must say that looking superficially at the example screenshots e.g. https://lemonspawn.com/wp-content/uploads/2020/08/trse_background.png I'm a little troubled at the extent to which the Turbo Rascal developers have departed from the standard Pascal syntax. For example, they've reverted to Wirth's original /* */ for comments and they're declaring arrays like
Code: Pascal  [Select][+][-]
  1. array[256] of byte
.

It might well be that their requirements were very similar to OP's and that they settled on something "Pascal-like" because it's usable rather than out of affection for the language and its traditions, but there's a risk that at some point in the future somebody will start arguing that FPC ought to have a TurboRascal mode.

There'd probably be a Oxygene mode before that... ::)

alpine

  • Hero Member
  • *****
  • Posts: 1038
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #67 on: August 18, 2022, 02:04:38 pm »
There is already software available that allows people to create code on a modern machine that will run on modern machines and multiple retro platforms, so there must be at least some demand for it.

CROSS LIB is an example of a game framework for vintage systems that can also be used for modern systems via GCC.

Lantern is a similar system for creating text adventures.

Several programming languages with multiple targets have already been mentioned in this thread.
I see. My suggestion is that post relates to https://forum.lazarus.freepascal.org/index.php/topic,55335.msg411593.html#msg411593
And it is also about text adventure games, right?

About CROSS LIB - it is a collection of gcc cross compilers and a multi-target library. That is how I would go, but I'm not an opposer of the C language.
About Lantern - it is a GUI of a game builder, it has a script language with {}, not clear to me how the images were built, it is not open-sourced.

If the aim is towards the text adventure games, there is no need for a full programming language. Such games can be completely data driven, i.e. you need the specific game data plus a static interpretative part.

You can write a decent GUI editor (like Lantern) in Lazarus and then assemble a BASIC code with both data and the (game) interpreter. You can use only the common intersection of the available BASIC dialects: namely READ/DATA/RESTORE/PRINT/FOR/NEXT/IF/GOTO. You can even embed the 'scripts' directly into BASIC code - just put line numbers and substitute the 'variables' with a corresponding two-letter names.

That way you can have your beloved BASIC at your disposal and you can use what is given (in ROM) not to waste more RAM for a runtime.



"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #68 on: August 18, 2022, 02:09:58 pm »
There'd probably be a Oxygene mode before that... ::)

I've never looked at in an any detail. Are you suggesting that Turbo Rascal might actually be an Oxygene rather than a Turbo Pascal derivative?

Following up https://docs.elementscompiler.com/Oxygene/ makes standard arrays look like ordinary Object Pascal, rather than the stringlike notation Turbo Rascal's using. Can't see anything on their comment format.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Wysardry

  • Jr. Member
  • **
  • Posts: 69
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #69 on: August 18, 2022, 09:02:07 pm »
The important point about Forth is not the (pretty bad) language syntax, but the execution model.
At this point, I don't know what languages, tools, execution model etc. I will be using. Until I do, thorough research on any topic is likely to eat up too much time for no real benefit.

Quote
... but the important thing is /how/ it worked.
Again, at this point that may or may not be relevant.

I'm not currently looking at using an interpreter or virtual machine on the retro targets. If I used one, it would only be on a modern machine for testing purposes.

Quote
And you reckon FPC is any different? And you really think you're going to get anywhere if "I hate C" is your overriding criterion?
As I would mainly be attempting this project for my own satisfaction, I won't be getting paid for it and there may only be a handful of other people that ever use it, I feel perfectly justified in rejecting any language or tool for any reason I wish.

If I dislike what I'm doing, I'll be less likely to want to finish it.

Quote
And I've been doing the same for about 45 years. Need I say more?
As it's unlikely I have 45 years left in me, telling me (and anyone else reading this) which parts were a waste of time would be useful. :)

You are aware that FPC also has a relatively small circle of really active core developers? Also with our own workflow... However we are definitely open for merge requests as long as they adhere to a few things (e.g. not changing coding style or providing features that we don't consider in the spirit of Pascal).
I may be wrong, but I get the impression that adding new Z80 targets to FreePascal would be simpler and involve creating less C code than doing the same with TurboRascal.

IOW, all other things being equal I would prefer the former.

And it is also about text adventure games, right?
It was originally related to creating text adventures and that is still the main focus, yes. However, I have realised that it wouldn't take much more effort to allow other text-based programs to be created with the same system.

Quote
About CROSS LIB - it is a collection of gcc cross compilers and a multi-target library. That is how I would go, but I'm not an opposer of the C language.
CROSS LIB is more complex than I need, as it supports the use of graphics.

Creating something simpler from scratch using FPC or Nim might be quicker than removing the parts I don't need.

Quote
About Lantern - it is a GUI of a game builder, it has a script language with {}, not clear to me how the images were built, it is not open-sourced.
There is some code available here if you're interested.

There were also some videos available on Youtube, but I haven't checked lately. I think the project was originally used for teaching purposes.

Quote
If the aim is towards the text adventure games, there is no need for a full programming language. Such games can be completely data driven, i.e. you need the specific game data plus a static interpretative part.
There are already several systems that take that approach. I'm looking to create something more flexible.

Quote
You can write a decent GUI editor (like Lantern) in Lazarus and then assemble a BASIC code with both data and the (game) interpreter. You can use only the common intersection of the available BASIC dialects: namely READ/DATA/RESTORE/PRINT/FOR/NEXT/IF/GOTO. You can even embed the 'scripts' directly into BASIC code - just put line numbers and substitute the 'variables' with a corresponding two-letter names.
I was considering a similar system some time ago.

The idea was to create a GUI that allowed the user to create code using blocks and drop down menues similar to the way GameMaker works.

Internally, the code would be stored as an AST in XML or similar. It could then be converted to various program languages (including several BASIC dialects) ready for compilation or direct use.

I put this on the back burner as it didn't seem to be very accessible for screen reader users and I wanted to explore options for the back end of the system.

Quote
That way you can have your beloved BASIC at your disposal and you can use what is given (in ROM) not to waste more RAM for a runtime.
Although I would like to support the use of existing BASIC interpreters on retro targets if possible, I also want users to have other options.

I envision the interpreter as being a set of code libraries that can optionally be included in the primary source code. That way, if someone doesn't need complex maths functions (or whatever) they don't include them and they don't take up space in the final program.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #70 on: August 18, 2022, 10:38:20 pm »
Quote
And I've been doing the same for about 45 years. Need I say more?
As it's unlikely I have 45 years left in me, telling me (and anyone else reading this) which parts were a waste of time would be useful. :)

:-) I've been trying to. Let's see if I can knock something out while waiting for my supper...

OK, in no particular order. As an engineer, I didn't have any sort of "formal background" in compilers. I still think that a lot of that stuff is garbage: if a syntax is difficult to parse then it would be better to select an unambiguous and efficient syntax than spending years working on new algorithms. But there's stuff in there which would have been enormously helpful when I was doing my MPhil in the '80s, provided I didn't get enmired in the crap.

When I started off, people weren't programming small computers in high-level languages (other than BASIC, and that was very much pre-structured). As such I had a better grounding in assembler, followed fairly promptly by the innards of Forth, Smalltalk and- slightly later- systems such as UCSD including their applicability to mainframes.

In terms of HLL, Forth, Smalltalk and APL are deadends because while they have interesting execution models their gross departure from expected syntax etc. puts them out on a limb. I'm not saying they're without merit, but I am saying that things like evaluation order are now so deeply ingrained in basic maths that ignoring them is perilous.

Reference here: the first three chapters of https://web.engr.oregonstate.edu/~budd/Books/leda/ are available for download and are worth reading carefully.

In the 1980s, when people were just about starting to take HLLs on micros seriously, I got a reprint of the classic paper on Meta-2 (I quoted an Alan Kay comment on this). I used that for a brief course for staff members at the university I was working at, and have been using a derivative for various tasks ever since. See Wp.

Much more recently, I came across Tree Meta (again, see Wp). That is much more difficult to get to grips with, but it has the potential of being able to specify rules to optimise the intermediate AST as part of the syntax definition. There was an implementation on GitHub which vanished, I got a lead on an ex-HP guy who'd used it in an instrument but he lost everything in one of the California fires :-(

Both of those may be used to generate a compiler using recursive descent, which AIUI is the technique used for FPC.

RD isn't particularly sexy and can barf when fed certain types of syntax. But it's pretty much adequate for Pascal or classic C, and doesn't need a higher degree to understand. And being simple it's compact, and is probably the technique that Borland used to get their early compilers to run natively on CP/M-80.

@PascalDragon: I've seen suggestion that RD isn't as good as some other approaches at error reporting and recovery. Do you have any comment?

To establish terminology, lets say that typical BASICs used tokenised-interpretive execution: each BASIC keyword was typically tokenised to a single byte when entered and the sequence of tokens, variable names etc. was interpreted at runtime. This is fairly concise but grossly inefficient.

Both Metas use a bytecode-interpretive arrangement as does UCSD Pascal, Java etc. In this, the high-level language is compiled beyond the AST stage and saved as a sequence of bytecodes, which may be subsequently interpreted or translated to e.g. assembler source for conversion to an executable binary.

Forth uses a distinct threaded-interpreted scheme, which was originally tightly coupled to the PDP system it was written for. I don't know how well this works on other systems, but the fact that a Forth implementation was used by Sun, IBM, Apple and the "One Laptop Per Child" project suggests that it's got it's good points: it might still be usable as some sort of intermediate notation, and roughly approximates the AST of a compiled language.

If you look at the P.J.Brown book that I cited, you will see that the BASIC-like language described has to gone to a lot of trouble to handle special cases that in the case of an ALGOL-derivative like Pascal "just work". By analogy, when Waychoff wrote an ALGOL compiler on ALGOL a whole lot of things "just worked" that Grau et al. had sweated blood over.

If you are looking at an implementation such as FPC, by and large there is a single x86 compiler, a single Z80 compiler and so on: where you tell the compiler that the target operating system is such-and-such, that just results in hints being passed to the backend ("use this variant of the RTL, use these linker directives..."). So to a very large extent, if there's a compiler targeting a chip you want then you might need to adapt the RTL (mostly written in Pascal) with a particular focus on some equivalent to the Crt unit (I'm not convinced that as it stands it is a good model for an 8-bit home micro).

So, let's look at how /I'd/ be approaching this, if I had the years.

The first thing is to decide on what in Ada terms would be called a workbench, with editor and debugger which assumed a host >16 bits. Borland, Hisoft et al. demonstrated that good work could be done on an 8-bit host, large chunks of what they did was written in assembler /but/ we are told that these days a compiler can produce code which is at least as good so why shouldn't we have a good development workbench to run on a home computer (assuming adequate RAM etc.)?

I like Pascal, although almost everybody agrees that the language as defined had flaws that weren't fixed until Wirth tried to replace it with Modula-2. Most subsequent languages have borrowed heavily from those when it comes to type checking etc.

Use a token such as := for assignment, and one such as == for comparison. In isolation = is always a syntax error.

I admit the importance of established idioms. That includes expression evaluation order, shortcuts such as +=, and accepted practice such as makefiles and decent preprocessor.

The preprocessor should be sufficiently capable that it can implement contentious features such as += without their having to be in the core language. I like the Smalltalk keyword syntax, and it might be possible to use this in conjunction with some sort of list notation to avoid a whole lot of variadic crap.

String handling is important. The zeroeth element of a string should be reserved, and -ve elements should indicate the length format, codepage and so on.

No automatic type conversion: that should be controlled by a trait system or by overloaded assignment. I'd like to see more overloadable operators, but am unsure whether it can be done in a small compiler (it implies feedback from the parser to the lexer, and this would be particularly problematic working across compilation units).

I appreciate objects, the try-finally construct, exception handling and so on, but if these aren't being used in a call chain they should not result in housekeeping overhead. This might make support of precompiled units difficult, particularly if pointers to functions/procedures are supported as callbacks.

FPC's dynamic arrays are great, but I'd rather see a common underlying mechanism for reference-counted (dynamic) arrays and (long, UTF-8) strings. And if reference counting works for those, it should also work for objects- at least at the user level.

Since classical Pascal (etc.) didn't support multiple compilation units, my preferred Pascal-like language would have separate interface and implementation files (like the TopSpeed compilers). In part this is because of the way that copyright etc. laws are moving, but also because it would be desirable to be able to lock-down at the OS level files containing definitions or complex hacks (e.g. the sort of thing that a systems programmer needs to do to get reference counting to work reliably).

I don't know how close to the immediacy of BASIC anything other than persistent environments (Smalltalk, Lisp, Forth) can get. My experience with the extremely good debugging on e.g. the RPi Pico (RP2040, Cortex M0) make me wonder whether that matters... what it can't do is stop at a breakpoint, allow the user to change the next line and then continue without missing a beat (again, xref to Mystic Pascal here since that at least attempted to). It /might/ be possible to arrange for a Pascal-like language to do that if compiled on the target system, it would be much more difficult if the target and host were distinct (OT but slightly relevant: there used to be a mechanism by which the Linux kernel could be patched while running).

I'm running out of steam. Hopefully that's given you something to think about, and plenty for Sven to complain about :-)

Added: xref to an earlier thread https://forum.lazarus.freepascal.org/index.php/topic,53139.msg392670.html although that was in the context of people who proposed "improvements" to Pascal, which I am not.

MarkMLl
« Last Edit: August 19, 2022, 10:06:12 am by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Wysardry

  • Jr. Member
  • **
  • Posts: 69
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #71 on: August 19, 2022, 04:40:01 am »
Thank you.

I will have to post a longer reply tomorrow as I just spent over 3 hours installing and uninstalling postscript viewers until I found one that would display more than the first page of those .ps files.

I finally used Postscript Viewer from Software Informer if anyone else using Windows 10 has this problem. It converts to a .pdf file and then opens in your default PDF viewer (possibly Microsoft Edge).

sketch

  • New Member
  • *
  • Posts: 32
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #72 on: August 19, 2022, 08:27:16 am »
I finally used Postscript Viewer from Software Informer if anyone else using Windows 10 has this problem. It converts to a .pdf file and then opens in your default PDF viewer (possibly Microsoft Edge).

Never heard of Postscript Viewer.  On Windows or Linux, I'd use Evince or GSview (Ghostscript) since they are well known, and I've used them.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #73 on: August 19, 2022, 08:54:36 am »
There'd probably be a Oxygene mode before that... ::)

I've never looked at in an any detail. Are you suggesting that Turbo Rascal might actually be an Oxygene rather than a Turbo Pascal derivative?

No, I'm saying that Oxygene might be the more interesting Pascal dialect when compared to Turbo Rascal (at least for me it definitely is) and thus it might be more interesting to support that (if any).

@PascalDragon: I've seen suggestion that RD isn't as good as some other approaches at error reporting and recovery. Do you have any comment?

There are certain places where our error reporting could be better though whether they're due to the recursive descent parser or not I can't say right now. And recovery needs to be taken into account at each location and so depending on the error it's a bit hit and miss. Don't know whether a non-RD parser would really fare better there however...

Since classical Pascal (etc.) didn't support multiple compilation units, my preferred Pascal-like language would have separate interface and implementation files (like the TopSpeed compilers). In part this is because of the way that copyright etc. laws are moving, but also because it would be desirable to be able to lock-down at the OS level files containing definitions or complex hacks (e.g. the sort of thing that a systems programmer needs to do to get reference counting to work reliably).

You might get your wish once ISO Extended Pascal modules are supported as that suggests (though not requires) separate files (though nothing is set in stone there yet as work on that hasn't even remotely started yet). What I don't get however is your last part: what do you mean with “lock-down at the OS level”?

I'm running out of steam. Hopefully that's given you something to think about, and plenty for Sven to complain about :-)

Too busy to really read and digest all that and thus I only picked out the cherries. :P

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Can FreePascal be used to create an internal or embedded DSL?
« Reply #74 on: August 19, 2022, 09:31:36 am »
There are certain places where our error reporting could be better though whether they're due to the recursive descent parser or not I can't say right now. And recovery needs to be taken into account at each location and so depending on the error it's a bit hit and miss. Don't know whether a non-RD parser would really fare better there however...

Thanks for that and please note that I definitely wasn't complaining. Noting that I'm only repeating suggestions I've read, my /suspicion/ is that it relates to a compiler's ability to report more than the first syntax error it encounters.

Quote
what do you mean with “lock-down at the OS level”?

Set a file read-only to less-privileged users.

Quote
Too busy to really read and digest all that and thus I only picked out the cherries. :P

You're welcome and I appreciate your comments.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018