Lua 1.1 Online Demo for MS-DOS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua 1.1 Online Demo for MS-DOS

Luiz Henrique de Figueiredo
If you want to try Lua 1.1 on MS-DOS, try it online at
https://archive.org/details/lua1.1.0

Other versions are available:
https://archive.org/details/lua1.0.0
https://archive.org/details/lua5.3.5
https://archive.org/details/lua5.4.0

Apparently, these were built with Open Watcom C.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Luiz Henrique de Figueiredo
BTW, if you want to build early versions of Lua using modern
compilers, get the lua-all package at
https://www.lua.org/ftp/lua-all.tar.gz
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Egor Skriptunoff-2
In reply to this post by Luiz Henrique de Figueiredo
On Fri, Sep 11, 2020 at 4:33 PM Luiz Henrique de Figueiredo wrote:
If you want to try Lua 1.1 on MS-DOS, try it online at
https://archive.org/details/lua1.1.0

Other versions are available:
https://archive.org/details/lua1.0.0
https://archive.org/details/lua5.3.5
https://archive.org/details/lua5.4.0

Apparently, these were built with Open Watcom C.

Wow! Lua 5.4 for MSDOS!
With 64-bit integers!  Fantastic!
It would be nice to have Lua 5.4 DOS EXE-file with the ability to load external libraries written in C.
Can this LUA.EXE load external modules?
"require" says it is searching for .so modules at non-DOS paths.
Is loading of binary modules not implemented here?
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Martin-2
In reply to this post by Luiz Henrique de Figueiredo
On 2020-09-11 3:33 p.m., Luiz Henrique de Figueiredo wrote:

> If you want to try Lua 1.1 on MS-DOS, try it online at
> https://archive.org/details/lua1.1.0
>
> Other versions are available:
> https://archive.org/details/lua1.0.0
> https://archive.org/details/lua5.3.5
> https://archive.org/details/lua5.4.0
>
> Apparently, these were built with Open Watcom C.
>

Very cool!

"Lua 5.4 on MS-DOS" sounds like reverse of "COBOL on Windows 10". Feels
like a time-back machine. BTW which version of MS-DOS is used?

-- Martin
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Luiz Henrique de Figueiredo
In reply to this post by Egor Skriptunoff-2
> Can this LUA.EXE load external modules?
> Is loading of binary modules not implemented here?

I don't know. You''l have to ask the uploader, Zazdravnaya:
https://archive.org/details/@zazdravnaya
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Viacheslav Usov
In reply to this post by Egor Skriptunoff-2
On Fri, Sep 11, 2020 at 5:02 PM Egor Skriptunoff
<[hidden email]> wrote:

> Can this LUA.EXE load external modules?
> "require" says it is searching for .so modules at non-DOS paths.
> Is loading of binary modules not implemented here?

They say "compiled from the source code available here
[https://www.lua.org/ftp/lua-5.4.0.tar.gz]" so I guess it is stock Lua
source code, compiled in a non-POSIX, non-Windows environment, so no
support for dynamic libraries. MS-DOS has no such notion anyway. You
might roll your own, though.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Philippe Verdy-2
In reply to this post by Egor Skriptunoff-2
This is very cool, even on servers because it is quite simple to sandbox a tiny VM for it, just for one task needed. And cool also for real-time applications when you don't want interference with the many apps and system threads that all modern OSes have, or as a testing environment.

Le ven. 11 sept. 2020 à 17:02, Egor Skriptunoff <[hidden email]> a écrit :
On Fri, Sep 11, 2020 at 4:33 PM Luiz Henrique de Figueiredo wrote:
If you want to try Lua 1.1 on MS-DOS, try it online at
https://archive.org/details/lua1.1.0

Other versions are available:
https://archive.org/details/lua1.0.0
https://archive.org/details/lua5.3.5
https://archive.org/details/lua5.4.0

Apparently, these were built with Open Watcom C.

Wow! Lua 5.4 for MSDOS!
With 64-bit integers!  Fantastic!
It would be nice to have Lua 5.4 DOS EXE-file with the ability to load external libraries written in C.
Can this LUA.EXE load external modules?
"require" says it is searching for .so modules at non-DOS paths.
Is loading of binary modules not implemented here?
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Rob Kendrick-2
In reply to this post by Martin-2
On Fri, Sep 11, 2020 at 06:57:01PM +0200, Martin wrote:
> "Lua 5.4 on MS-DOS" sounds like reverse of "COBOL on Windows 10".
> Feels like a time-back machine. BTW which version of MS-DOS is used?

It's not MS-DOS as such, it runs under DOSBox, which is an x86 emulator
that directly implements the DOS system calls, and an implementation of
COMMAND.COM.

B.
v
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

v
On Sat, 2020-09-12 at 15:40 +0100, Rob Kendrick wrote:
> It's not MS-DOS as such, it runs under DOSBox, which is an x86
> emulator
> that directly implements the DOS system calls, and an implementation
> of
> COMMAND.COM.
>
> B.

But couldn't one run it in actual MS-DOS by using VM or real
installation?
--
v <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Niccolo Medici
In reply to this post by Viacheslav Usov
On 9/11/20, Viacheslav Usov <[hidden email]> wrote:
> On Fri, Sep 11, 2020 at 5:02 PM Egor Skriptunoff
> <[hidden email]> wrote:
>
>> Can this LUA.EXE load external modules?
>> [...]
>
> [...]
> MS-DOS has no such notion

Right. In the DOS days, if we wanted to provide an extension to some
app, we'd write it as a TSR ("terminate and stay resident") and hook
our code to some interrupt handler. The app would call our extension
thus:

  ax = 23   ; some function number.
  bx = ...    ; argument1
  cx = ....   ; argument2
  int 52      ; call our code
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Coda Highland


On Sat, Sep 12, 2020 at 1:39 PM Niccolo Medici <[hidden email]> wrote:
On 9/11/20, Viacheslav Usov <[hidden email]> wrote:
> On Fri, Sep 11, 2020 at 5:02 PM Egor Skriptunoff
> <[hidden email]> wrote:
>
>> Can this LUA.EXE load external modules?
>> [...]
>
> [...]
> MS-DOS has no such notion

Right. In the DOS days, if we wanted to provide an extension to some
app, we'd write it as a TSR ("terminate and stay resident") and hook
our code to some interrupt handler. The app would call our extension
thus:

  ax = 23   ; some function number.
  bx = ...    ; argument1
  cx = ....   ; argument2
  int 52      ; call our code

That's one way. Another way was an overlay scheme where the main app would load some code from disk on demand (possibly overwriting other loaded code/data) and jump to it. Conceptually similar to a DLL, but used more for handling programs that wouldn't all fit in memory at once. Nothing would have stopped you from using the same technique to support plugins, though; I just don't know offhand of anyone who actually did that because I wasn't a PC user at the time it was relevant.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Viacheslav Usov
In reply to this post by Niccolo Medici
On Sat, Sep 12, 2020 at 8:39 PM Niccolo Medici <[hidden email]> wrote:

> Right. In the DOS days, if we wanted to provide an extension to some
> app, we'd write it as a TSR ("terminate and stay resident")

TSRs were more of system extensions rather than app extensions. In the
context of a Lua host, which wants to load a library, loading a
library as a TSR would be sub-optimal, because TSR will "stay
resident" even after the Lua host terminates.

Overlays seem more appropriate here, which is not to say that would be
very easy to do. The current specification of loading a "C library"
is: "[...] uses a dynamic link facility to link the application with
the library. Then it tries to find a C function inside the library to
be used as the loader. The name of this C function is the string
"luaopen_" concatenated with [...]". Neither "link" nor "find" was
part of the overlay functionality offered by MS-DOS. All it did was to
read an executable file from disk to a specified memory location and
fix relocations, but not "link" or "find" anything.

Interestingly, after some googling I found that a lot of what would be
required was already done in the "DosDLL" project [1]. It does use the
MS-DOS overlay functionality, and implements Windows-style
LoadLibrary() and GetProcAddress() functionality on top of it. So, in
principle, the "find" part is there. The "link" part, however, is
mostly not there, in the sense that the loaded library itself has no
access to the host's symbols, or any other dependency (which would not
be loaded automatically anyway). DosDLL was itself inspired by MikDLL
[2], which is also based on MD-DOS overlays, and which seems to
address the "link" problem somewhat better, but clearly still falling
short of doing everything that is meant by "a dynamic link facility to
link the application with the library".

Cheers,
V.

[1] http://www.kiezsoft.de/download/dosdll.zip

[2] https://www.hornet.org/code/utils/compiler/mikdll.zip
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Coda Highland


On Sun, Sep 13, 2020 at 1:21 PM Viacheslav Usov <[hidden email]> wrote:
On Sat, Sep 12, 2020 at 8:39 PM Niccolo Medici <[hidden email]> wrote:

> Right. In the DOS days, if we wanted to provide an extension to some
> app, we'd write it as a TSR ("terminate and stay resident")

TSRs were more of system extensions rather than app extensions. In the
context of a Lua host, which wants to load a library, loading a
library as a TSR would be sub-optimal, because TSR will "stay
resident" even after the Lua host terminates.

Overlays seem more appropriate here, which is not to say that would be
very easy to do. The current specification of loading a "C library"
is: "[...] uses a dynamic link facility to link the application with
the library. Then it tries to find a C function inside the library to
be used as the loader. The name of this C function is the string
"luaopen_" concatenated with [...]". Neither "link" nor "find" was
part of the overlay functionality offered by MS-DOS. All it did was to
read an executable file from disk to a specified memory location and
fix relocations, but not "link" or "find" anything.

Interestingly, after some googling I found that a lot of what would be
required was already done in the "DosDLL" project [1]. It does use the
MS-DOS overlay functionality, and implements Windows-style
LoadLibrary() and GetProcAddress() functionality on top of it. So, in
principle, the "find" part is there. The "link" part, however, is
mostly not there, in the sense that the loaded library itself has no
access to the host's symbols, or any other dependency (which would not
be loaded automatically anyway). DosDLL was itself inspired by MikDLL
[2], which is also based on MD-DOS overlays, and which seems to
address the "link" problem somewhat better, but clearly still falling
short of doing everything that is meant by "a dynamic link facility to
link the application with the library".

Cheers,
V.

[1] http://www.kiezsoft.de/download/dosdll.zip

[2] https://www.hornet.org/code/utils/compiler/mikdll.zip

If we were to truly care enough to put the effort into it, we could compile the modules with thunks that could be patched-up at load time to access functions out of the main executable. That is, after all, more or less how DLLs work anyway. Transitive dependencies might still be an issue, of course, but given a 640KB memory limit there's only so far you can really practically go anyway.

Of course, if we were to talk about being practical, you'd be better off compiling the modules you want into the executable directly instead of dynamically loading them.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Enrico Colombini
On 13-Sep-20 22:39, Coda Highland wrote:
> If we were to truly care enough to put the effort into it, we could
> compile the modules with thunks that could be patched-up at load time to
> access functions out of the main executable. That is, after all, more or
> less how DLLs work anyway. Transitive dependencies might still be an
> issue, of course, but given a 640KB memory limit there's only so far you
> can really practically go anyway.

Technically you could use extended and expanded memory to break the 640
KB barrier. Ah, the ineffable joy of tuning config.sys ;-)

--
   Enrico
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Sam Trenholme
In reply to this post by Coda Highland
> if we were to talk about being practical, you'd be better
> off compiling the modules you want into the executable directly
> instead of dynamically loading them.

That’s how I compile Lua because it makes for a smaller binary that’s
easier to build.  My personal fork of Lua includes a limited version of
luafilesystem (lfs), without timestamps (to avoid Y2038 problems) or
Unix-specific file information, as well as a variant of the bit32 lib
(because there are *a lot* of places where bit operations make sense,
and bit32 is the closest thing we have to a generally used bit operation
interface in a world where LuaJIT and other non-PUC implementations of
Lua are still at Lua 5.1 + some form of 32-bit op library).
Reply | Threaded
Open this post in threaded view
|

Re: Lua 1.1 Online Demo for MS-DOS

Viacheslav Usov
In reply to this post by Enrico Colombini
On Sun, Sep 13, 2020 at 10:52 PM Enrico Colombini <[hidden email]> wrote:

> Technically you could use extended and expanded memory to break the 640
> KB barrier.

Technically it seems far more straightforward to use a DOS extender to
make your Lua host run as a 32-bit process to begin with and dispense
with the 640K nonsense [1]. Some of them are free software, and I
think the Open Watcom C compiler comes with one. Some of them support
the "linear executable" format, and can actually load and link to such
executables dynamically, which trivially solves every problem we have
discussed so far.

Well, for a legacy 16-bit DOS application (that wants to embed Lua,
and load libs, hmm) going 32 bits might be a tall order. But for a
standalone Lua interpreter, why not?

Cheers,
V.

[1] Insert a BillG joke here.