M2C in DOS

[r***@gmail.com]

(trijezdci):
The _stat functions are documented on the Microsoft site.
I also assume those will work on DOS, not only on Windows.

(MarcoV):
If you move to Windows, best leave your Dos legacy at the door.
Windows NT and Dos are mostly unrelated. Windows 64-bit doesn't
even run dos apps.

(trijezdci):
Well, BSD, Linux and MacOS X -- 64 bit or not -- do run DOS apps
via a utility called DOSbox which many folks are using and this
allows you to share directories with the host system. It is
therefore desirable to have M2C build and run under DOSbox.

(Nemo):
Turbo C 2.01 is available from the Borland Musuem (via the
Wayback Machine) and is easilly installed under DOSbox.


Okay, so here's the deal: I think talking about DOS (here) is
a waste of time. I seriously doubt that anyone here (besides me)
is interested. I don't think it's worth worrying about, but hey,
some of you did mention it.

I would not waste my time with TurboC (for many reasons). I
would personally recommend OpenWatcom or DJGPP. OW at least
tries to be portable across platforms (so if stat works, it
should "mostly" work on all targets). DJGPP is fairly POSIX
heavy, so you shouldn't usually have to write DOS-specific code.
Both can be cross-compilers (and tested under various emulations
atop foreign host OSes).

In raw DOS, I failed to build this "new" M2C with latest DJGPP,
but an older version (GCC 3.4.6) did build and run it okay
when used under (Linux) DOSEMU (LFNs!). One file of mine seemed
okay (after fixing a few errant semicolons), but the other seemingly
had problems with variant records (but the switch didn't seem to
help, are multiple switches allowed?). Do you want me to host a
binary build of that somewhere? Probably pointless since, as
mentioned, Win64 doesn't run it. (Even DOSEMU isn't widely
propagated in Linux circles for various reasons. Although yes,
DOSEMU does also work under x64.)

I would not recommend here running (esp. compiling!) under DOSBox
at all. It's not a "real" DOS, only for games. But DOSEMU is Linux
only. I would recommend QEMU or VBox with an appropriate disk image
(which I can provide, if needed). You could also make a bootable
USB, if you find that more convenient.

Didn't you mention bootstrapping via M2M? There's also a few others,
e.g. FST or GPM/PC or GPM/DJGPP. I also had built (and "installed")
M2C 0.6 via DJGPP under DOSEMU a while back (but never published
binaries because I didn't clean up or fix the makefile, hence it
wasn't easily reproducible). Would anyone be interested in that?
(Doubt it.)

Look, I hate to be so cynical and pessimistic. But I doubt anyone
here really worries about extreme portability to such things as DOS
(or Amiga or whatever else you mentioned, Plan 9?). As much as I
really hate to say it, keep it simple: Mac, Win, Linux (aka, Windows
or POSIX). Alas, I'm no great DOS programmer, but I'm willing to
help, if at all possible.

[r***@gmail.com]

Hi,

Post by r***@gmail.com
In raw DOS, I failed to build this "new" M2C with latest DJGPP,
but an older version (GCC 3.4.6) did build and run it okay
when used under (Linux) DOSEMU (LFNs!).
Do you want me to host a binary build of that somewhere?

https://sites.google.com/site/rugxulo/trijezdci-m2c-rework-eda44d353a78.7z?attredirects=0&d=1

[r***@gmail.com]

Hi,

Post by r***@gmail.com
https://sites.google.com/site/rugxulo/trijezdci-m2c-rework-eda44d353a78.7z?attredirects=0&d=1

m2c.exe seems to work okay for me. Though it does error out (incorrectly)
on a procedure variable that has no parameters:

VAR blah: PROCEDURE(): INTEGER;

[r***@gmail.com]

Hi,

Just for further clarity ....

Post by r***@gmail.com
Well, BSD, Linux and MacOS X -- 64 bit or not -- do run DOS apps
via a utility called DOSbox which many folks are using and this
allows you to share directories with the host system. It is
therefore desirable to have M2C build and run under DOSbox.
Turbo C 2.01 is available from the Borland Musuem (via the
Wayback Machine) and is easilly installed under DOSbox.

As much as I like DOSBox and think it's brilliant, it's very limited.

It's "only for games". There are several forks and patches, but the
official version hasn't even had a new release in over 5 years. It's
a "fast" 486 DX (at best, EDIT: oops, forgot it barely supports
"slow pentium" too, I think??). It only supports (at most) 64 MB of
RAM. It doesn't have LFN support at all. (Granted, it is super portable.)

While I have never rebuilt it, you can try a third-party patch which
adds LFN support, but "caveat emptor" (obviously):

(Wengier: "Long File Name support"):
http://www.vogons.org/viewtopic.php?f=41&t=40610&sid=23928e5145e649e18521eaf38b3d0173&start=60

Turbo C doesn't support LFNs at all. DJGPP and pals do. OpenWatcom
is incomplete (although 2.0-pre claims better, but it's not quite
finalized yet): https://open-watcom.github.io/open-watcom/

P.S. Honestly, the best path is to avoid LFNs entirely, but nobody
ever does that. So perhaps using cross-compilers (and full x86
emulators, esp. with VT-X) is really the best idea here.

[r***@gmail.com]

Hi,

(I prefer native and emulators apart, unless they are deeply
integrated to the system and nearly transparent, like the Linuxator)

This is not about preferences, it is about what meets the goals of
the project.
It is more likely somebody will just download DOSbox, than having
an actual DOS machine, it is also more likely somebody will just
download DOSbox instead of installing DOS on a virtual machine.

There is nothing difficult about VMs. But since my own .img is
somewhat quirky and anemic, I'll just point you to some other
examples:

1). http://freedos.sourceforge.net/wiki/index.php/VirtualBox
2). http://www.lazybrowndog.net/freedos/virtualbox/

We have one contributor who is traveling a lot and does everything
he does on a Netbook where the resources are limited to the point
that he doesn't want a virtual machine nor a dual boot setup.

Dual boot isn't too hard either, but these days, I think a bootable
USB is probably easier and less error-prone.

1). http://rufus.akeo.ie/
2). http://unetbootin.github.io/
3). https://wiki.debian.org/FlashBIOS
4). http://joelinoff.com/blog/?p=431

DOSbox is the tool that takes the least effort and the least amount
of resources, in terms of storage, memory and CPU.

Not true. It's very easy to get QEMU working. Granted, VirtualBox or
KVM are better if you have VT-X, but a lot of machines don't. Still,
in most cases, it's not a huge dealbreaker.

P.S. QEMU 2.5.0 was just released. I haven't tried it yet, but 2.4.0
works great.

http://qemu.weilnetz.de/

But the trouble was
syncing M2 sources between M2M and M2C then, which means everyone
else would have to use M2M, which is not desirable. Besides, it is
always good to have control over the bootstap system, too. Affords
more flexibility and more independence.

I've tried FST under QEMU, it works fine. What issues were you having?
(I could also drag out my DJGPP build of M2C 0.6 if needed. Never got
Gauis' modified p2c nor gm2 working in DOS, though. Also not sure
where to reliably find GPM, but that works as well.)

Oh, that reminds me, here's the DJGPP cross-compilers:

https://github.com/andrewwutw/build-djgpp/releases

[trijezdci]

Post by r***@gmail.com

(I prefer native and emulators apart, unless they are deeply
integrated to the system and nearly transparent, like the Linuxator)

This is not about preferences, it is about what meets the goals of
the project.
It is more likely somebody will just download DOSbox, than having
an actual DOS machine, it is also more likely somebody will just
download DOSbox instead of installing DOS on a virtual machine.

There is nothing difficult about VMs.

We have a contributor who is travelling a lot and usually only has a netbook with very limited resources available. He simply does not have the resources for a VM and he will not use one. Period.

Now, this is less of an issue when we have a working native Windows version, but still it shows that there are scenarios where what everybody else thinks is straightforward actually is not and where small download and click solutions like DOSbox have an edge.

Post by r***@gmail.com
Dual boot isn't too hard either, but these days, I think a bootable
USB is probably easier and less error-prone.

No, he didn't have enough disk space for a dual boot. There are other reasons why one may not want to do dual boot. And running entirely of a USB stick can be rather slow, depending on the hardware.

Post by r***@gmail.com

DOSbox is the tool that takes the least effort and the least amount
of resources, in terms of storage, memory and CPU.

Not true. It's very easy to get QEMU working. Granted, VirtualBox or
KVM are better if you have VT-X, but a lot of machines don't. Still,
in most cases, it's not a huge dealbreaker.

In this real world case I described, none of that was viable nor desirable to the contributor.

If a contributor tells you that he or she doesn't want it, then that becomes the requirement. The more you try to convince them that they should do what you think, the more likely they will jump ship.

Modula-2 is not exactly all that well known nor popular these days.

Post by r***@gmail.com

But the trouble was
syncing M2 sources between M2M and M2C then, which means everyone
else would have to use M2M, which is not desirable. Besides, it is
always good to have control over the bootstap system, too. Affords
more flexibility and more independence.

I've tried FST under QEMU, it works fine. What issues were you having?

The more compilers are involved the more work there is required.

If there is any different behaviour reported, then it is not clear whether this is due to a bug in our code or due to a different environment. We will spend time and effort on trying to replicate reported behaviour on different compilers.

Last but not least, and I had already explained this, I'd like to use extensible record types for AST nodes and variable size record types for implementing various dynamically allocatable types such as hash tables and strings. Last but not least I'd like to be able to avoid suffixed literals. This is not part of the standard feature set of existing M2 compilers. In M2C it will be supported as extensions.

Post by r***@gmail.com
(I could also drag out my DJGPP build of M2C 0.6 if needed. Never got
Gauis' modified p2c nor gm2 working in DOS, though. Also not sure
where to reliably find GPM, but that works as well.)

David forked M2C 0.7 from 0.6 and there have been a bunch of changes since. It is a different compiler by now. Furthermore, the new M2C will be much different still. M2C 0.6 is not going to be of any use.

Post by r***@gmail.com
https://github.com/andrewwutw/build-djgpp/releases

From your experience, what is your assessment on those C99 features I mentioned -- variable length arrays in structs and struct initialiser literals? Are they supported by DJGPP?

regards

[r***@gmail.com]

Hi,

(lots of DOS insinuations snipped, nobody cares, certainly not your
netbook-using contributor, although DJGPP works great on XP's NVTDM)

Post by trijezdci

Post by r***@gmail.com

But the trouble was
syncing M2 sources between M2M and M2C then, which means everyone
else would have to use M2M, which is not desirable. Besides, it is
always good to have control over the bootstap system, too. Affords
more flexibility and more independence.

I've tried FST under QEMU, it works fine. What issues were you having?

The more compilers are involved the more work there is required.

My point was that you keep referring to M2M but whining about PIM2 EXPORT.
So use a PIM3 like FST. Not a permanent solution, but you said you were
interested in bootstrapping (or has that changed?).

Post by trijezdci

Post by r***@gmail.com
https://github.com/andrewwutw/build-djgpp/releases

From your experience, what is your assessment on those C99 features
I mentioned -- variable length arrays in structs and struct
initialiser literals? Are they supported by DJGPP?

I compiled your new M2C only two days ago. Did you try it? The
proof is in the pudding.

At risk of stating the obvious, DJGPP is a 32-bit port of GCC to DOS.
The latest version is GCC 5.3, which cross-compiles itself (now using
C++). Yes, it supports C90, C99, and C11 (although the libc misses a
few bits). So yes, it supports both of those features. You can't get
more modern than latest GCC (ironically on DOS while even XP is
considered dead these days).

I don't know what else to tell you (or what else you want to know).

[trijezdci]

Post by r***@gmail.com
My point was that you keep referring to M2M but whining about PIM2 EXPORT.
So use a PIM3 like FST. Not a permanent solution, but you said you were
interested in bootstrapping (or has that changed?).

Bootstrapping is not a do-it-once-throw-away-bootstrapping-tool affair.

Not to us anyway.

The idea is to use a single bootstrap compiler that everybody can use, not having to look for alternatives depending on situation.

Furthermore, neither M2M nor FST support the language features we expect to write the compiler in.

re DJGPP

Post by r***@gmail.com
I compiled your new M2C only two days ago. Did you try it? The
proof is in the pudding.

Yes I saw yo mentioning it but you also said you had some troubles.

Did you overcome those?

As I had mentioned my priority is on moving ahead on Posix. I am not going to get sidetracked on building myself on any other platforms until the whole lot works on Posix (including back end).

In the meantime, there will be folks who will do the building, adjusting and testing on other platforms, for example Tom Breeeden has done it for Amiga OS. If you are interested to cross-build to target DOS, that will be very much appreciated. If you report any issues, I will accommodate them. If you want repo access, I can accommodate that too. But don't expect me to build and test on other platforms myself. This would only delay completion of the compiler.

thanks
regards

[r***@gmail.com]

Hi,

Post by trijezdci

Post by r***@gmail.com
I compiled your new M2C only two days ago. Did you try it? The
proof is in the pudding.

Yes I saw yo mentioning it but you also said you had some troubles.
Did you overcome those?

The problem was generating the depends.mk. For some reason, that didn't
work in raw DOS with LFN driver. (A lot of *nix-y things break in
raw DOS. That's why we haven't been able to natively build most
GNU things for decades, hence (over)reliance on NTVDM or Linux-native
cross-compilers, sadly. Well, "we" is them, not me, I'm not directly
involved, just a very simple end user.)

It's obviously something trivial, but I don't know what just yet. So
I just took the easy way out and used DOSEMU. So no, I didn't iron out
the issue, just avoided it. (I don't have access to buggy NTVDM anymore.)

And yes, m2c.exe built okay and seems to work (in limited testing).
I uploaded a .7z archive with .EXEs, .O objects, and full sources,
including depends.mk and djmake.log.

Post by trijezdci
If you are interested to cross-build to target DOS, that will be
very much appreciated.

This is far from a billion files, so I wouldn't call this project
very complicated (which is good, for me). A simple recompile under
DOSEMU isn't hard.

Post by trijezdci
If you report any issues, I will accommodate them.

Again, most of it seems to work already. I just don't have thousands
of files to test. But ftp.psg.com seems to have a variety of sources.

Post by trijezdci
If you want repo access, I can accommodate that too.

No, I'm old-fashioned, I'm too simple for SCMs.

Post by trijezdci
But don't expect me to build and test on other platforms myself.
This would only delay completion of the compiler.

Of course not, but at the same time, once things stabilize, it might
not be the worst idea to build a stable binary every so often.
Granted, DOS is probably the least popular target, so I don't expect
anything, but it's not the worst idea, IMHO.

[r***@gmail.com]

Hi,

Post by r***@gmail.com
https://github.com/andrewwutw/build-djgpp/releases

Using djgpp-mingw-gcc530-standalone.zip seems to build m2c.exe okay
(using FPC's GNU Make 3.82) atop Win7 (64-bit).

Of course, you have to use "i586-pc-msdosdjgpp-gcc" instead of "gcc"
for $(CC) and $(LD), and put it first in your %PATH%.

There's also a minor issue of two files (m2-filereader.c m2-fileutils.c)
not compiling under strict "-std=c99", so I built them using "-std=gnu99"
instead.

Just FYI.

[trijezdci]

Post by r***@gmail.com
Using djgpp-mingw-gcc530-standalone.zip seems to build m2c.exe okay
(using FPC's GNU Make 3.82) atop Win7 (64-bit).
Of course, you have to use "i586-pc-msdosdjgpp-gcc" instead of "gcc"
for $(CC) and $(LD), and put it first in your %PATH%.
There's also a minor issue of two files (m2-filereader.c m2-fileutils.c)
not compiling under strict "-std=c99", so I built them using "-std=gnu99"
instead.

Thanks for testing.

The C99 issue has been fixed a while ago. However, the latest updates for the compatibility libraries have not been committed to the repo yet. They will be committed together with the AST libraries and AST exporters in an upcoming release.

In the meantime, the portability libs are available as self contained zip archives:

https://bitbucket.org/trijezdci/m2c-rework/downloads/fileutils.zip

https://bitbucket.org/trijezdci/m2c-rework/downloads/pathnames.zip

These contain the implementations of the portability libs for AmigaOS, any Unix/POSIX systems, OpenVMS and Windows. Plan9 and RISC OS versions are under way.

If somebody could test the Windows version on MS-DOS and OS/2 that would be nice.

--
https://bitbucket.org/trijezdci/m2c-rework/wiki/Porting%20M2C

[r***@gmail.com]

Hi,

Post by trijezdci
https://bitbucket.org/trijezdci/m2c-rework/downloads/fileutils.zip
https://bitbucket.org/trijezdci/m2c-rework/downloads/pathnames.zip
These contain the implementations of the portability libs for AmigaOS,
any Unix/POSIX systems, OpenVMS and Windows. Plan9 and RISC OS versions
are under way.
If somebody could test the Windows version on MS-DOS and OS/2 that would be nice.

You mean test the *-win.c code with DJGPP? Or some other compiler
(OpenWatcom)? Because right now I just assumed DJGPP (using POSIX code)
was good enough. That (DPMI) .EXE should run fine on any DOS or OS/2
or NTVDM.

[trijezdci]

Post by r***@gmail.com
You mean test the *-win.c code with DJGPP? Or some other compiler
(OpenWatcom)? Because right now I just assumed DJGPP (using POSIX code)
was good enough. That (DPMI) .EXE should run fine on any DOS or OS/2
or NTVDM.

My understanding is that certain system calls like stat() and getcwd(0 and pathconf() and others are not available in a Windows/DOS environment, regardless of the compiler used and it would need a Cygwin environment to provide these.

Therefore, on a Windows/DOS environment without Cygwin, one needs to use Windows equivalents of those system calls and where the calls are absent altogether, use a different approach.

This is why there is a fileutils-win.c file.

It uses direct.h, _stat() and _getcwd(). It also avoids pathconf().

As for pathnames, it is my understanding that although Windows can use "/" as a directory separator, without Cygwin, this will only work with relative paths, not absolute paths.

Therefore, on a Windows/DOS environment without Cygwin, one needs a Windows/DOS specific pathname parser/splitter library.

This is why there is an m2-pathnames-win.c file.

It parses and splits proper Windows/DOS pathnames, following a grammar that is included in the .c file.

However, if you are telling me that DJGPP does these transformations already within its C stdlib runtime environment then one might not need neither Cygwin nor the portability libs, but I doubt that. Perhaps DJGPP provides POSIX versions of the system calls used by fileutils, but I doubt it provides the functionality of the pathnames library.

[trijezdci]

The APIs are now documented on the M2C wiki:

https://bitbucket.org/trijezdci/m2c-rework/wiki/Portable%20Fileutils%20API

https://bitbucket.org/trijezdci/m2c-rework/wiki/Portable%20Pathnames%20API

[r***@gmail.com]

Hi,

Post by trijezdci
My understanding is that certain system calls like stat() and
getcwd() and pathconf() and others are not available in a Windows/DOS
environment, regardless of the compiler used and it would need a
Cygwin environment to provide these.

stat() : http://www.delorie.com/djgpp/doc/libc/libc_744.html
getcwd() : http://www.delorie.com/djgpp/doc/libc/libc_386.html
pathconf() : http://www.delorie.com/djgpp/doc/libc/libc_612.html

Post by trijezdci
Therefore, on a Windows/DOS environment without Cygwin, one needs
to use Windows equivalents of those system calls and where the
calls are absent altogether, use a different approach.

That might be true for other compilers, but DJGPP is just GCC
with its own heavily-extended (DOS-based, FreeBSD-influenced) libc.
It predates Cygwin by many years (as obviously DOS/DPMI was before
Win32; technically DPMI first came from Win 3.0, but 'D' is for
"DOS", and even OS/2 2.x had DPMI).

Post by trijezdci
This is why there is a fileutils-win.c file.
It uses direct.h, _stat() and _getcwd(). It also avoids pathconf().

Okay, but the chances that Windows and DOS somehow share an API
are very low. There is very little common interest between them
anymore, so it's not likely ... unless the compiler supports both
targets, which is rare (e.g. OpenWatcom).

DJGPP does not share pretty much anything with MinGW or Cygwin
(besides GCC), so the libc is very different. It has lots of
stuff in a vain attempt to be compatible, but it is mostly
ignored these days. So yes, they did try to achieve some
semblance of POSIX (and other) compatibility, but the popularity
is not what it used to be.

Post by trijezdci
As for pathnames, it is my understanding that although Windows can
use "/" as a directory separator, without Cygwin, this will only
work with relative paths, not absolute paths.

I don't really mess with Windows except for casual use. I'm just
saying that Windows is way over-engineered, very complicated.
It's extremely rare that anything in Windows is still related to
DOS at all, most of it has been abandoned or reinvented.

The people interested in Windows overwhelmingly dislike DOS.
But Windows is millions of times more popular, so I doubt
you'll have trouble finding someone to help there. But that
can't be me (as I don't grok that stuff, and only barely
otherwise).

Post by trijezdci
Therefore, on a Windows/DOS environment without Cygwin,
one needs a Windows/DOS specific pathname parser/splitter library.

You'd almost just need separate versions for Win9x or 2k/XP as
well as a newer version for 7/8/10 or whatever. DOS doesn't fit
in there at all. It's unlikely to find a suitable version
for all of them (outside of a million #ifdef statements).

Post by trijezdci
This is why there is an m2-pathnames-win.c file.
It parses and splits proper Windows/DOS pathnames, following a
grammar that is included in the .c file.
However, if you are telling me that DJGPP does these transformations
already within its C stdlib runtime environment then one might not
need neither Cygwin nor the portability libs, but I doubt that.

DJGPP is like Cygwin but for DOS instead of Windows. It has its
own (old) ports of Bash, CoreUtils, Gawk, GNU Grep, GNU Find,
GNU TexInfo, GNU Emacs, etc. (Well, not all of it is old, just
lots of it.)

Post by trijezdci
Perhaps DJGPP provides POSIX versions of the system calls used by
fileutils, but I doubt it provides the functionality of the
pathnames library.

It doesn't (and can't easily) support literally everything POSIX
(e.g. mmap), but it has more than enough for many things. Thousands
of apps have been ported or natively developed over the years.
But it has heavily waned in popularity, unfortunately.

But it still works! So, if you're still interested in DOS, give it
a try.

[trijezdci]

Post by r***@gmail.com
That might be true for other compilers, but DJGPP is just GCC
with its own heavily-extended (DOS-based, FreeBSD-influenced) libc.

Ok, in this case the POSIX version of fileutils will work on DOS with DJGPP.

How about other C compilers on DOS? Do they also provide the functions that fileutils wraps?

However, the pathnames library is an entirely different matter. This library parses pathname/filename strings and splits them.

https://bitbucket.org/trijezdci/m2c-rework/wiki/Portable%20Pathnames%20API

The C standard library does not provide this facility and I doubt that DJGPP does.

Post by r***@gmail.com
It's extremely rare that anything in Windows is still related to
DOS at all, most of it has been abandoned or reinvented.

The pathname syntax should be the same except for older DOS versions with 8.3 style filenaming.

Therefore, when building M2C for DOS, it will require the Windows version of the pathnames library.

NB: The issue of 8.3 filenames on older DOS versions (and DOSbox) will be resolved as a side effect of using a user editable name translation dictionary which is necessary to overcome unlikely but possible ambiguities in filenames on case-insensitive filesystems.

Post by r***@gmail.com
The people interested in Windows overwhelmingly dislike DOS.
But Windows is millions of times more popular, so I doubt
you'll have trouble finding someone to help there.

Frank Schonjans has volunteered to do the testing on Windows and he's using MSVC. So we're all clear on the Windows side of things.

Post by r***@gmail.com

Post by trijezdci
Therefore, on a Windows/DOS environment without Cygwin,
one needs a Windows/DOS specific pathname parser/splitter library.

You'd almost just need separate versions for Win9x or 2k/XP as
well as a newer version for 7/8/10 or whatever.

The fileutils wrapper library should be backwards compatible as I understand the direct.h header and the _stat() and _getcwd() functions go back a very long way, possibly all the way to Windows 95

As for the pathnames library, it does not call any system calls at all and the only standard library function it uses is malloc(). You could even build and run the OpenVMS version under DOS. It will build and work fine but the library does not translate pathnames, it only parses and validates, splits and composes them. Thus, if you then handed your OpenVMS pathname to fopen() it would be rejected by fopen() with an error. In any event, the library is portable across all Windows/DOS operating systems and C compilers as long as malloc() is provided.

Post by r***@gmail.com
DOS doesn't fit
in there at all. It's unlikely to find a suitable version
for all of them (outside of a million #ifdef statements).

I dislike using #ifdef within a single library to cover multiple platforms.

It makes the code cluttered and difficult to comprehend and maintain.

This is why I have a common portable API in fileutils.h and m2-pathnames.h and separate implementations, one for each platform (as needed). The fileutils.c and pathnames.c files are not implementations, but selectors only. They contain ifdefs to select the actual library, they do nothing else.

For OpenVMS, there is no fileutils-vms.c because the fileutils-posix.c implementation works on OpenVMS without any modification and without any ifdef. Instead the fileutils.c selector file selects fileutils-posix.c for OpenVMS.

From what you are telling me, we have a similar situation with MS-DOS, at least when the DJGPP compiler is used. The question is whether this is only the case with DJGPP or also with other C compilers on DOS.

Depending on that I can modify the fileutils.c selector file such that for DOS it will select fileutils-posix.c if the compiler is DJGPP but select fileutils-win.c for other compilers.

Do you happen to know what the macro would be that indicates that DJGPP is being used?

Also, do you happen to know what the story is for other C compilers on DOS that might still be in use today?

Thanks a lot for your assistance with this. I really appreciate it.

[trijezdci]

According to

https://sourceforge.net/p/predef/wiki/Compilers/

the DJGPP compiler defines macro __DJGPP__

I have therefore tentatively changed the fileutils.c selector to handle DOS and OS/2 separately from Windows ...

/* --------------------------------------------------------------------------
* Select implementation for MS-DOS and OS/2 host platforms
* ----------------------------------------------------------------------- */

#elif ((defined(MSDOS)) || defined(OS2))
#if (defined(__DJGPP__))
#include "fileutils-posix.c"
#elif /* other compilers */
#include "fileutils-win.c"
#endif /* __DJGPP__ */

If there are other C compilers for DOS that also work with the POSIX version of fileutils, then their respective macros will need to be added still.

Another question is whether DJGPP can also be used under Windows, in which case the Windows branch will also need the additional test for the compiler macro.

[trijezdci]

The library archive fileutils.zip at

https://bitbucket.org/trijezdci/m2c-rework/downloads/fileutils.zip

has now been updated with the following in selector fileutils.c ...

/* --------------------------------------------------------------------------
* Select implementation for Windows-64 host platforms
* ----------------------------------------------------------------------- */

#elif (defined(_WIN64))
#include "fileutils-win.c"


/* --------------------------------------------------------------------------
* Select implementation for Windows-32, MS-DOS and OS/2 host platforms
* ----------------------------------------------------------------------- */

#elif (defined(_WIN32)) || ((defined(MSDOS)) || defined(OS2))
/* The DJGPP compiler provides a POSIX based standard library */
#if (defined(__DJGPP__))
#include "fileutils-posix.c"
#else /* other compilers */
#include "fileutils-win.c"
#endif /* __DJGPP__ */

It would be nice if someone volunteered testing the fileutils shim library on MS-DOS and OS/2.

thanks in advance

[r***@gmail.com]

Hi,

Post by trijezdci
The library archive fileutils.zip at
https://bitbucket.org/trijezdci/m2c-rework/downloads/fileutils.zip
has now been updated with the following in selector fileutils.c ...
It would be nice if someone volunteered testing the fileutils shim
library on MS-DOS and OS/2.

You mean just replacing the new code and rebuilding? You'll have to
be extremely specific on what (and how) you want me to test.

BTW, I don't have OS/2, but you can get a demo CD of eCS 2.2 beta here:

http://www.ecomstation.com/democd/

[trijezdci]

Post by r***@gmail.com

Post by trijezdci
It would be nice if someone volunteered testing the fileutils shim
library on MS-DOS and OS/2.

You mean just replacing the new code and rebuilding? You'll have to
be extremely specific on what (and how) you want me to test.

No, just the library itself.

initially, if it builds at all, then

- test if file_exists returns true for an existing file, false for a non-existing filename
- test if is_directory returns true for a directory, false for a non-directory file
- test if is_regular_file returns true for a regular file, false for a directory
- test if get_filesize returns the correct file size
- test if get_filetime returns the correct file modification time
- test if new_path_w_current_workdir returns the path of the current working directory

When using the fileutils-win.c implementation the first five functions all use _stat(), while the fileutils-posix.c implementation uses access() for file_exists and stat() for the other four.

Frank Schonjans made a test rig for these tests, if I can find it I will post it.

The fileutils library has no dependencies on any other files, only the standard library (and direct.h for the win implementation).

thanks

[r***@gmail.com]

Hi,

Post by trijezdci
Another question is whether DJGPP can also be used under Windows,
in which case the Windows branch will also need the additional test
for the compiler macro.

DJGPP v2 uses DPMI, which first appeared in Windows 3.0 (1990).
Win9x was DOS-based and also had it. Win2k/XP were not DOS-based,
but they were the first NT variants to be targeted at home consumers,
so MS added FAT32 and LFN support from Win9x (since that was abandoned).

Under NT, at least 32-bit variants, you always have (386+) V86 mode
available, hence the availability of NTVDM. And yes, DJGPP works under
NTVDM (better than raw DOS, actually, since relies too heavily on LFNs).
But it's still using 16-bit DOS and BIOS APIs, so when 64-bit lacks V86
mode, there is no NTVDM, and thus it won't run. (Although DOSEMU can successfully fake it under x64.) Newer VT-X lets DOS stuff run fairly
quickly under a hypervisor (e.g. VirtualBox), but that's not really a
proper subsystem "under" Windows (like the old days).

What I was pointing you to was a cross-compiler. On a 32-bit Windows
(or OS/2), you shouldn't need it (in theory) as DOS stuff is "natively"
supported. But that has fallen out of favor, so it's much harder to
run DOS stuff than it used to be.

[r***@gmail.com]

Hi,

Post by trijezdci
Ok, in this case the POSIX version of fileutils will work on DOS with DJGPP.
How about other C compilers on DOS? Do they also provide the functions that fileutils wraps?

I don't know how many compilers you want to target. But at least OpenWatcom
supports sys/types.h , sys/stat.h , and direct.h .

Post by trijezdci
However, the pathnames library is an entirely different matter. This library parses pathname/filename strings and splits them.
https://bitbucket.org/trijezdci/m2c-rework/wiki/Portable%20Pathnames%20API
The C standard library does not provide this facility and I doubt that DJGPP does.

Perhaps not directly, but it might already have similar functionality.
For instance, fnsplit() is neither ANSI nor POSIX:

http://www.delorie.com/djgpp/doc/libc/libc_336.html

Post by trijezdci

Post by r***@gmail.com
It's extremely rare that anything in Windows is still related to
DOS at all, most of it has been abandoned or reinvented.

The pathname syntax should be the same except for older DOS versions with 8.3 style filenaming.

But all DOSes are 8.3 only. LFNs only came about with Win95 (and were only
available under the GUI, aka Windows mode). You have to use a third-party
loadable driver (TSR, there are several) to access such functionality in
pure raw DOS. (Not counting Datalight ROM-DOS 7, still commercially sold,
which I've never used.)

http://www.delorie.com/djgpp/doc/rbinter/ix/21/71.html

Post by trijezdci
Therefore, when building M2C for DOS, it will require the Windows version of the pathnames library.
NB: The issue of 8.3 filenames on older DOS versions (and DOSbox) will be resolved as a side effect of using a user editable name translation dictionary which is necessary to overcome unlikely but possible ambiguities in filenames on case-insensitive filesystems.

Although I haven't tried it, I already pointed you to a patched version
of DOSBox that supports LFNs. BTW, Windows 2000 and XP (on up) also
natively support "DOS" LFNs (unlike NT 4.0, but there's even a third-party
driver for that). DJGPP v2 has supported LFNs (if available) for decades.

Again, I don't really recommend DOSBox here. If you want to share files
with host OS, you can also use QEMU or VMware (with third-party driver).

Post by trijezdci

Post by r***@gmail.com
The people interested in Windows overwhelmingly dislike DOS.
But Windows is millions of times more popular, so I doubt
you'll have trouble finding someone to help there.

Frank Schonjans has volunteered to do the testing on Windows and he's using MSVC. So we're all clear on the Windows side of things.

Great, but OpenWatcom also runs on Windows. Since it also can host/target
DOS and OS/2, it might make more sense to prefer that.

Post by trijezdci

Post by r***@gmail.com

Post by trijezdci
Therefore, on a Windows/DOS environment without Cygwin,
one needs a Windows/DOS specific pathname parser/splitter library.

You'd almost just need separate versions for Win9x or 2k/XP as
well as a newer version for 7/8/10 or whatever.

The fileutils wrapper library should be backwards compatible as I understand the direct.h header and the _stat() and _getcwd() functions go back a very long way, possibly all the way to Windows 95

Going back doesn't mean much. Even back in DOS days, MS C and Borland
both had proprietary (incompatible but similar) functions. Some of those
functions have been supported in other (newer, better) compilers, for
better compatibility, but just by virtue of being non-standard, you
can't necessarily rely on them being universally available.

Post by trijezdci

Post by r***@gmail.com
DOS doesn't fit
in there at all. It's unlikely to find a suitable version
for all of them (outside of a million #ifdef statements).

I dislike using #ifdef within a single library to cover multiple platforms.
It makes the code cluttered and difficult to comprehend and maintain.

I agree, and that's not what I recommend here. I merely meant that it is
probably naive to assume "Windows" is one version when in fact it's
probably more reasonable to expect a Win9x version, a Win2k/XP version,
and also a newer 7/8/10 version. I don't think you can (usually) target
all of them as one, at least not easily.

Post by trijezdci
From what you are telling me, we have a similar situation with MS-DOS, at least when the DJGPP compiler is used. The question is whether this is only the case with DJGPP or also with other C compilers on DOS.
Depending on that I can modify the fileutils.c selector file such that for DOS it will select fileutils-posix.c if the compiler is DJGPP but select fileutils-win.c for other compilers.
Also, do you happen to know what the story is for other C compilers on DOS that might still be in use today?

I don't recommend supporting every compiler under the sun (just yet).
DJGPP is probably good enough, maybe try OpenWatcom too. There are still
others good ones that are still used, but they are far less robust and
thus less popular.

[trijezdci]

Post by r***@gmail.com
I don't know how many compilers you want to target. But at least OpenWatcom
supports sys/types.h , sys/stat.h , and direct.h .

I do not intend to write any code for any specific compiler, but I am fine adding a compiler to the ifdef in the selector file to select one of the existing implementations.

Any compiler that supports pathconf(), stat() and getcwd() should be able to use the fileutils-posix.c implementation out of the box, and any compiler that supports _stat() and _getgwd() (via direct.h) should be able to use the fileutils-win.c out of the box.

The selector file fileutils.c simply needs to select one of the two implementations. By default, it will select the windows implementation for DOS hosts. But if we know that a compiler provides a POSIXy standard library instead of using direct.h, then it is easy to add it to the ifdef so the POSIX implementation will be selected for it.

For any compilers where neither the one nor the other approach works, the build will simply fail.

Post by r***@gmail.com

Post by trijezdci
However, the pathnames library is an entirely different matter. This library parses pathname/filename strings and splits them.
https://bitbucket.org/trijezdci/m2c-rework/wiki/Portable%20Pathnames%20API
The C standard library does not provide this facility and I doubt that DJGPP does.

Perhaps not directly, but it might already have similar functionality.

I had decided against the use of any platform provided parsers/splitters because it is actually more work to figure out which pathname parsing libraries are available on which platform or which compiler and which version of the OS they are available, or which variant of it is available on which version of the OS, than just writing a universal parsing library from scratch for each OS family.

For example on OpenVMS there are the LIB$PARSE functions and associates but there are variations that depend on which filesystem is used (ODS-2 vs ODS-5) and then you have to also figure out how to test on what type of filesystem the source file is located.

While still experimenting, I had written a skeleton library that would have been using the native API but it soon became apparent that this would have become larger and more complex than writing my own pathname parser and not use any system calls at all.

My parser works for any DEC pathnames/filenames, back to PDP RSTS/RSX-11 even though we won't support those OSes for other reasons. But it saves a lot of hassle not to have to worry about the details of the underlying OS environment.

There is also the issue that filesystems are permitting nonsensical filenames that we do not want to permit. For the purpose of a M2 compiler, filenames generally need to match the identifiers of their respective modules. A module identifier cannot include certain characters, so there is absolutely no need to allow those characters in a filename even if the filesystem permits that. In fact it causes extra hassle to deal with those situations where a source file contains characters that are illegal in a M2 identifier.

Furthermore, using such filename is likely to make the source code non-portable even if it is otherwise perfectly portable.

For these reasons, the Modula-2 approach should also apply to filenames: Anything that is not explicitly allowed is VERBOTEN. The OS may permit all kinds of characters in filenames, but many will be illegal filenames as far as M2C is concerned. Some control over this is available in m2-pathnames-policy.h.

Last but not least, if a filename is rejected, eventually we want to print a diagnostic just as we do for syntax errors in source code where the position of the error in the filename is indicated. This is not always easily doable when using platform provided filename parsing/splitting API because these often don't tell you exactly where the error in the pathname/filename is.

All these are good reasons why M2C now got its very own pathnames library with an OS independent interface.

Post by r***@gmail.com

Post by trijezdci
The pathname syntax should be the same except for older DOS versions with 8.3 style filenaming.

But all DOSes are 8.3 only. LFNs only came about with Win95 (and were only
available under the GUI, aka Windows mode). You have to use a third-party
loadable driver (TSR, there are several) to access such functionality in
pure raw DOS. (Not counting Datalight ROM-DOS 7, still commercially sold,
which I've never used.)

If I am not mistaken, FreeDOS has LFN support and according to a developer's mailing list or forum I had found there is recent work being done on DOSbox to provide LFN support too. Also, I do not really fancy having to learn which OSes support long filenames and which ones don't, which of the ones that don't have utilities to add that support in and what those utilities are called only to be able to answer questions from folks who try to build and run the compiler and find there is a problem with filename length.

In any event, the 8.3 filename restriction can simply be ignored from the viewpoint of evaluating pathnames because we need to implement name translation for case-insensitive filesystems anyway. If there is a name translation to deal with unlikely but possible ambiguous filenames on case-insensitive filesystems, we have to handle the situation. Once we do, it will also solve the 8.3 filename issue.

If you have reason to suspect that your M2 library name ends up ambiguous on the filesystem, be it for reasons that the filesystem is case-insensitive (and you may have a library called Foo and another called FOO) or be it for reasons that the filesystem uses short filenames, then you can enter a translation for the library into a translation dictionary, for example:

MyFooLibrary:FOOLIB

Then if you call M2C on that library's sources, it will read the translation dictionary and translate MyFooLibrary.def to FOOLIB.def and MyFooLibrary.mod to FOOLIB.mod. This will work both for resolving case-insensitivity issues as well as filename length issues.

In turn, we don't need to care whether or not the underlying OS/filesystem supports long filenames. The issue simply goes away. No need to edit an FAQ with entries for every OS/gadget combination like "Yes, you can use M2C with X out of the box, but not with Y unless you have gadget Z installed".

NB: the DEF and MOD suffix testing functions test for both def/mod and DEF/MOD.

Post by r***@gmail.com
Although I haven't tried it, I already pointed you to a patched version
of DOSBox that supports LFNs.

I really don't want to have to become an expert in what combination of OSes works with what patches, utilities, gadgets. If people start emailing me, I can't just ignore the mail, but to give an answer, even if the answer is negative, I have to find out what is going on and why doesn't it work. I don't want that.

Post by r***@gmail.com
Again, I don't really recommend DOSBox here. If you want to share files
with host OS, you can also use QEMU or VMware (with third-party driver).

It is not about recommending anything. The idea is to make it such that "it just works".

Post by r***@gmail.com
Great, but OpenWatcom also runs on Windows. Since it also can host/target
DOS and OS/2, it might make more sense to prefer that.

Here too, no preferences, just a philosophy of "it just works".

And if Watcom provides direct.h, it should just work with the fileutils-win.c implementation.

Post by r***@gmail.com
... I merely meant that it is
probably naive to assume "Windows" is one version when in fact it's
probably more reasonable to expect a Win9x version, a Win2k/XP version,
and also a newer 7/8/10 version. I don't think you can (usually) target
all of them as one, at least not easily.

For the working of the fileutils library, all Windows/DOS/OS2 operating systems fall into three different categories:

(1) those that support pathconf(), stat() and getcwd() as if it was Unix
(2) those that support _stat() and _getcwd() via direct.h
(3) those that don't support either

I am assuming that #1 and #2 covers the vast majority of Windows/DOS/OS2 systems, and those will just work using the -win or -posix implementations of fileutils. Consequently I am assuming that #3 make up a negligible percentage and those will be unsupported.

If that assumption is wrong and there is a third way that represents a larger number of systems and if there is demand for that and the effort to use that third way is justifiable we can look at providing another implementation for fileutils for that group at a later stage.

For the working of the pathnames library all Windows/DOS/OS2 systems are in fact one and the same.

Post by r***@gmail.com
What I was pointing you to was a cross-compiler. On a 32-bit Windows
(or OS/2), you shouldn't need it (in theory) as DOS stuff is "natively"
supported. But that has fallen out of favor, so it's much harder to
run DOS stuff than it used to be.

I am assuming that if somebody has a Windows box and they want to compile M2 sources with M2C, most of the time, they would want to use a native Windows build of M2C, not a DOS build.

However, there are plenty of scenarios where FreeDOS is run on embedded boards. In many cases FreeDOS is used as a maintenance or repair OS when hardware settings need to be changed or when the main BSD or Linux based OS fails to boot. There are other scenarios where FreeDOS is used as the main OS hosting embedded applications.

Most developers will indeed run FreeDOS in a VM on their desktops, be it Windows, Linux or MacOS X in order to build or develop utilities or applications for the embedded system or its repair environment running FreeDOS. But some may also want to use DOSbox, especially when they have a Netbook with limited resources for going on the road to do maintenance on embedded devices in the field.

Keep in mind that retro-computing is not our goal. Retro-computing afficionados can always use the old M2 compilers that were available back in the day and their primary concern isn't portability.

Instead, our goal is to make Modula-2 a viable alternative to C again in the present and in the future. It is precisely in systems programming and system utility programming where that alternative needs to be present. And embedded systems are already a larger market than desktop systems.

Whilst we therefore do not specifically target all Windows and DOS versions going back to the first releases, it is more sustainable and maintainable to provide support that is generic and not written to target one specific OS. In particular I am concerned about people emailing questions like "Can I use M2C on version X of Y or do I need utility Z?" I just want to be able to say "It will just work, any version, with or without patches/utilities". I don't want to have to deal with configuration management.

As for OS/2, there is now a company who apparently have some kind of arrangement with IBM to provide commercial support to corporations still using OS/2 and they have announced a new release of OS/2 for this year. There is actual development being done for this OS. Hence we want to be able to build and run M2C on it.

Hope this makes sense.

[r***@gmail.com]

Hi,

Post by trijezdci
If I am not mistaken, FreeDOS has LFN support

No, not in the kernel, only via third-party TSR. Upcoming FD 1.2
will only use DOSLFN (TSR). AFAIK, there is no VFAT work being done
in the kernel at this time (or soon).

Most (not all) people who expect LFNs only use them under Windows,
e.g. NTVDM, but everything since XP has been less than optimal (if
available at all, e.g. none under 64-bit).

Post by trijezdci
and according to a developer's mailing list or forum I had found
there is recent work being done on DOSbox to provide LFN support
too.

DOSBox hasn't had an official release since 2010. Yes, I told you
that one guy has written patches to add LFN support, but that's
far from official, so you'll "probably" never see that in any
proper release any time soon.

[trijezdci]

Post by r***@gmail.com
In raw DOS, I failed to build this "new" M2C with latest DJGPP,

It would be interesting to know what it choked on.

Post by r***@gmail.com
but an older version (GCC 3.4.6) did build and run it okay
when used under (Linux) DOSEMU (LFNs!). One file of mine seemed
okay (after fixing a few errant semicolons),

is that errant semicolons in the C sources or in M2 test input?

For testing M2 sources, you can use the M2C option --errant-semicolon.

Post by r***@gmail.com
but the other seemingly
had problems with variant records

The parser had a copy-paste artefact in one of the functions that implement variant records and it then called the wrong production but I fixed that last night. Perhaps you want to try again with the latest version from the repo.

Post by r***@gmail.com
(but the switch didn't seem to
help, are multiple switches allowed?).

If you are getting syntax errors on your M2 input, please can you post the output from the parser and the sources or a snippet of the offending sources either here or on the issue tracker on the repo.

Post by r***@gmail.com
Do you want me to host a
binary build of that somewhere?

Hold that thought for the moment until we have settled on a C compiler to use and a DOS target (or two), see further below.

Post by r***@gmail.com
Didn't you mention bootstrapping via M2M? There's also a few others,
e.g. FST or GPM/PC or GPM/DJGPP.

I really don't want to get into the quagmire of having to tell contributors to try this or that Modula-2 compiler and then for some reason they don't get it to work on their environment and have to try yet another and with M2M we then need to add EXPORT statements everywhere just for those who use M2M because its PIM2 and we use PIM4.

I have already lost a couple of contributors simply because they got the impression that the whole Modula-2 thing is a collection of old stuff that never works.

So, we will use a new M2C, rewritten from scratch, and standardise on that as our bootstrap tool. In the long term this will be the least hassle and affords us greater independence too.

The work is mostly overlapping anyway.

This way we can also use Oberon style extensible records to implement AST nodes, which will be far more readable and maintainable than using variant records.

Also, we can use modern prefix literals. One of the things potential contributors coming from C or other languages are most upset about are octal numbers and hex numbers with suffixes, especially when the octal numbers then end up looking like hex numbers because of the B and C suffixes. That really freaks everyone out. So the new M2C supports prefix literals (controlled by compiler switch).

Post by r***@gmail.com
Look, I hate to be so cynical and pessimistic. But I doubt anyone
here really worries about extreme portability to such things as DOS
(or Amiga or whatever else you mentioned, Plan 9?). As much as I
really hate to say it, keep it simple: Mac, Win, Linux (aka, Windows
or POSIX).

There are two goals for M2C.

(1) compile and build any M2 examples from any of Wirth's books, not just PIM.

(2) bootstrap compilers written in Modula-2 across platforms.

Therefore, as I said, it is desirable to get M2C to build and run on DOS.

My priority is certainly on POSIX, then Windows, but the other OSes on the wish list are not going to be scrapped simply because of encountering difficulties. In particular there are likely to be some folks out there willing to contribute the OS specific parts and the testing.

For example Tom Breeden got M2C working now on Amiga OS.

There is also a quality assurance benefit from building across platforms. When building on another platform it is not uncommon that something comes to light that leads to an overall improvement in the code base across the board.

Post by r***@gmail.com
Alas, I'm no great DOS programmer, but I'm willing to
help, if at all possible.

That would be neat. Thanks.

From your comments, it seems there are two issues on prerequisites.

(1) finding/choosing an available C compiler that works

(2) building on DOSbox may not guarantee that the result will also work on other DOS environments.

As for #1, I am using some C99 features, most notably the ability to put an array of indeterminate size at the end of a struct, where the size is determined on allocation at runtime.

struct foo_t {
unsigned int size; /* use for bounds checking */
some_type_t buffer[]; /* indeterminate array */
};

This is a C feature that gradually emerged over time and eventually showed up in ISO C99. It was however already available in many compilers long before that. Yet, depending on the C compiler, especially when using older compilers, it could be unsupported.

The other thing I remember to having had issues on Windows with MSVC around 2007 or thereabouts was initialising structs with struct literals, like so

struct foo_t { int a, b, c; };

struct foo_t bar = { 0, 0, 0 };

Those two features may well be unsupported in some older C compilers that date back to the 1990s.

Support for filenames longer than eight characters is also desirable.


As for #2, given the the goals for M2C that I mentioned further above, the limitations you mentioned for DOSbox do not pose any impediment at all. None of the examples in Wirth's books will need 64 MB of RAM and no compiler bootstrap should need that much either.

Perhaps we will need to think of DOS as two targets: Native DOS (but probably running in some virtual machine) and DOSbox.

thanks
regards

[r***@gmail.com]

Hi,

Post by trijezdci

Post by r***@gmail.com
In raw DOS, I failed to build this "new" M2C with latest DJGPP,

It would be interesting to know what it choked on.

As far as building it in raw DOS, I don't think that's feasible
at the moment (due to LFN driver bugs or whatever other quirks).
It would take more fiddling (which could be fun, but maybe not!)
Using DOSEMU worked fine, so that's probably easier than worrying
endlessly.

I don't have any exhaustive .MOD sources to test with it. The few
I tried did indeed work fine (with my aforementioned DJGPP build).
Using --errant-semicolon and --variant-records works okay. I
haven't rebuilt since the PROCEDURE() fix. Not much else popped up.
There was one quirk that only shows up when using --parser-debug,
related to the NOT keyword, but I don't know why it isn't an error
otherwise. Oh, and whatever you call that PIM3 feature with
("INTEGER[0..255];") choked it on old M2P.MOD.

Other than that, I don't see any obvious problems (yet).

[trijezdci]

Post by r***@gmail.com

Post by trijezdci

Post by r***@gmail.com
In raw DOS, I failed to build this "new" M2C with latest DJGPP,

It would be interesting to know what it choked on.

As far as building it in raw DOS, I don't think that's feasible
at the moment (due to LFN driver bugs or whatever other quirks).

Fair enough. I didn't realise it was related to filenames. It would be a pain to have to rename all the files and then figure out how to keep them in sync, so let's leave that alone for the time being. We can look at this again later.

Maybe I can write a tool some day that scans all the #include directives of the .h and .c files of a project and generate short name versions of all files including changing the names also in the #include directives. That might work, but obviously this is not something I want to get sidetracked with now.

Post by r***@gmail.com
It would take more fiddling (which could be fun, but maybe not!)
Using DOSEMU worked fine, so that's probably easier than worrying
endlessly.

agreed.

Post by r***@gmail.com
I don't have any exhaustive .MOD sources to test with it. The few
I tried did indeed work fine (with my aforementioned DJGPP build).
Using --errant-semicolon and --variant-records works okay. I
haven't rebuilt since the PROCEDURE() fix. Not much else popped up.
There was one quirk that only shows up when using --parser-debug,
related to the NOT keyword, but I don't know why it isn't an error
otherwise.

That would be interesting to know more about.

Post by r***@gmail.com
Oh, and whatever you call that PIM3 feature with
("INTEGER[0..255];") choked it on old M2P.MOD.

Do you have a URL and if so, can you tell which line and column?

thanks and regards

[r***@gmail.com]

Hi,

Post by trijezdci

Post by r***@gmail.com
There was one quirk that only shows up when using --parser-debug,
related to the NOT keyword, but I don't know why it isn't an error
otherwise.

That would be interesting to know more about.

*** simpleTerm ***
@ line: 120, column: 8, lookahead: NOT
line: 120, column: 8, unexpected reserved word NOT found
expected identifier, string, integer, real number, character code, '(' or '{'.

IF NOT Done THEN WriteString("Oops!"); WriteLn; HALT END;

*** simpleTerm ***
@ line: 164, column: 22, lookahead: NOT
line: 164, column: 22, unexpected reserved word NOT found
expected identifier, string, integer, real number, character code, '(' or '{'.

BEGIN NEW(stk); IF NOT dynalloc THEN

C:\tmp>trijezdci\m2c b.mod --pim3 --errant-semicolon | grep "error count"
parse error count: 0
C:\tmp>trijezdci\m2c b.mod --pim3 --errant-semicolon --parser-debug | grep "error count"
parse error count: 2

So, for some reason, it's not complaining unless --parser-debug is used.

Post by trijezdci

Post by r***@gmail.com
Oh, and whatever you call that PIM3 feature with
("INTEGER[0..255];") choked it on old M2P.MOD.

Do you have a URL and if so, can you tell which line and column?

The only URL I could find was this, and it looks the same, so I
hope that helps.

http://www.decuslib.com/decus/uni87a/mod/sources_3/modula_pp

EDIT: It's not quite the same (obviously), somebody changed
it to use a larger integer constants! But the idea's the same,
so whatever. I don't know where else to find it, I forget where
I grabbed it from! Email me if you really want it.

C:\tmp>trijezdci\m2c m2p.mod --pim3
m2c Modula-2 Compiler & Translator, version 1.00
line: 98, column: 19, unexpected symbol '[' found
expected symbol ';'
line: 98, column: 29, unexpected symbol ';' found
expected reserved word END
line: 99, column: 10, unexpected symbol '=' found
expected symbol '.'
parse error count: 3
C:\tmp>sed 96,101!d m2p.mod

TYPE
natural = INTEGER[0..32767];
inrange = INTEGER[0..maxinlen];
outrange = INTEGER[0..maxoutlen];

[j***@gmail.com]

To summarize:

You want to build a new compiler for an obsolete language to run on all obsolete and hardly ever used operating systems, and you cannot find contributors?

Yes, this is a rotten world. Especially when your own contributors have special demands, since they have some non-standard equipment.

I programmed in assembly until 1997. Then it became pretty clear, with everyone running with Pentium class machines, that nobody would ever notice the difference between assembled and compiled languages. So I switched to Modula-2, permanently (until I ran into the obc Oberon compiler).

As of 2011, there is no need for compiled languages anymore. An interpreted language like Python or Perl will do for the majority of programs. Modern hardware is so fast... What's the use of a quad core machine with three cores idle?

So I would suggest: consider to make a Modula-2 interpreter. Forget about DOS, CP/M, Menuet, OS9, OS/2. the lot. Concentrate on Win and Lin. Not even Mac.

I love Modula-2 and Oberon. And still, Modula-2 is obsolete. Oberon is still kicking. In certain circles: the modern days software hippies.

Your efforts would have been great in 1992. But in those days, even Prof Wirth had already abandoned Modula-2 in favor of Oberon.

Again, I like Modula-2. But generating a universal compiler for it, would be similar to building a Trek Domane racebicycle with a carbon fibre frame, Shimano XLR Titanium components, but with octagonal wheels.

Now, creating an interpreter, would be a whole other ball game.

And even that would be a waste of time since nobody will use it.

[trijezdci]

On Saturday, 19 December 2015 18:40:27 UTC+9, ***@gmail.com wrote:

Thanks for the drivel, always amusing.

[Saša Janiška]

Post by j***@gmail.com
As of 2011, there is no need for compiled languages anymore. An
interpreted language like Python or Perl will do for the majority of
programs. Modern hardware is so fast... What's the use of a quad core
machine with three cores idle?

I can agree that supporting ancient OS-es might not be practical, but
cannot agree there is need for compiled languages...Just see: Go, Rust,
Nim, Crystal...to mention just a few.

Moreover, I do not see what would Modula-2 interpreter be good for when
there are several languages (e.g. Nim/Crystal) offering syntaxes similar
to dynamic languages, but with the benefit of static typing.

Despite of having lot of memory and cpu power, software is also getting
bloated. In today's world people are buying quadcore cpu-powered mobile
phones with Gigs of memory in order to send 140chars msgs while some
years ago I was using less powered desktop machines to render video -
strange, but that's reality. :-)


Sincerely,
Gour

-- 
Perform your prescribed duty, for doing so is better than not 
working. One cannot even maintain one's physical body without work.

[j***@gmail.com]

Post by Saša Janiška
I can agree that supporting ancient OS-es might not be practical, but
cannot agree there is need for compiled languages...Just see: Go, Rust,
Nim, Crystal...to mention just a few.

There are a lot of compiled languages and some interpreted. And there are bytecode languages like Java and obc. The advantage of interpreted languages is, of course: no need to compile. Edit, run, edit, run.

For some tasks you need compiled, for other interpreted will do as well.

Post by Saša Janiška
Moreover, I do not see what would Modula-2 interpreter be good for when
there are several languages (e.g. Nim/Crystal) offering syntaxes similar
to dynamic languages, but with the benefit of static typing.

You can ask yourself: why isn't everyone riding a Volvo car or a Van Nicholas bicycle? Because in many instances you just don't need to. The days of Modula-2 are over. Yes it was the best language. But it was not available to the public when it was needed.

It would have been better if Unix was created with Modula-2 compilers. But it wasn't.

Remember Minix? Minix was built with the ACK (Amsterdam Compiler Kit). The ACK is a great compiler with multiple front- and back-ends. Front-ends used to be C, Pascal, Modula-2, Basic, etc). Backends for CP/M, DOS, Minix, CPM86, Linux, you name it. But the ACK is dead as a dodo, just like Minix.

http://tack.sourceforge.net/

Some people are working on it again. Trying to get it compiled on 64 bit architectures.

Post by Saša Janiška
Despite of having lot of memory and cpu power, software is also getting
bloated.

By design of the users. The 'normal' users need flying pigs on their desktop, singing christmas songs. And they want Bluetooth. And USB. And WiFi. And all at once.

What happened to the ACK? The executables generated by the ACK are fast and compact (Pascal frontend creates smallest executables), so why don't people use it? Minix, a full fledged operating system, was created with the ACK.

[Saša Janiška]

Post by j***@gmail.com
You can ask yourself: why isn't everyone riding a Volvo car or a Van
Nicholas bicycle? Because in many instances you just don't need to.

No, the real reason is that people can't afford them.

Post by j***@gmail.com
The days of Modula-2 are over. Yes it was the best language. But it
was not available to the public when it was needed.

That is just proof for above point. ;)

Many people would use Ada which is fine language when
reliability/security is concerned, but simply cannot afford Adacore's
support fee.

Just take a look at Rust - there are almost 15k stargazers and 1.2k
contributors at Github for the language which addresses safety and it
comes with really ugly syntax, imho. However, it comes with liberal
compiler license allowing people to write commercial software without
paying fortune.

So, if someone provides freely available compiler for Modula-2, there
will be people tinkering with it. Iirc, Pascal is still used by lot of
people (TIOBE index even hsows increasing market share).

Post by j***@gmail.com
By design of the users. The 'normal' users need flying pigs on their
desktop, singing christmas songs. And they want Bluetooth. And USB.
And WiFi. And all at once.

And they buy it since they can afford it. :-)


Sincerely,
Gour

-- 
As the embodied soul continuously passes, in this body,
from boyhood to youth to old age, the soul similarly passes
into another body at death. A sober person is not bewildered
by such a change.

[j***@gmail.com]

Post by Saša Janiška
No, the real reason is that people can't afford them.

For some people price is an issue. For most, features and priorities are more important.

Post by Saša Janiška

Post by j***@gmail.com
The days of Modula-2 are over. Yes it was the best language. But it
was not available to the public when it was needed.

That is just proof for above point. ;)

Excellent Modula-2 compilers have been available for over 20 years now. Mocka, XDS. obc, GPM and some more. Free of charge. Obc is still actively maintained and it is cross platform.
All of them for free. But free, as in 'free beer' is seldom an issue. The computer hardware you buy is not for free. And neither is your datalink connection. So, it's personal preference and priorities that determine whether one wants to use software or not.
In the days of DOS there was the shareware principle: try before you buy. Very good software in most cases but people preferred to steal the registered user versions... One tank of gasoline is more important than 5 years of using a very good program. That's setting priorities. It's not a question of affordable or not.

Post by Saša Janiška
Many people would use Ada which is fine language when reliability/security is concerned, but simply cannot afford Adacore's support fee.

Try gnat, the ADA frontend to gcc.

Post by Saša Janiška
Just take a look at Rust -

It looks like the worst of C, combined with the worst of Pascal with a topping of the worst of Python. But it doesn't cost extra money so it must be good.

Post by Saša Janiška
there are almost 15k stargazers and 1.2k contributors at Github for the language which addresses safety and it comes with really ugly syntax, imho.

Yes. People think that ugly syntax is the price you have to pay for a good computer language.

Post by Saša Janiška
However, it comes with liberal compiler license allowing people to write commercial software without paying fortune.

Now you get it. They think it is for free, as in 'free beer' so they CHOOSE to get the free (as in 'free beer') compiler. But if they would have paid one tank-of-gas worth amount for a good compiler, they could have all the benefits for years to come.
If you buy a compiler and you need new features, you tell the manufacturer to put them in the new release. Do the same with a GitHub project and they say: "Here's the source, you put it in yourself".

A86 used to be a shareware assembler for DOS/WIN. After a trial period, I registered by paying a few dollars and Issaacson sent me the registered version that also has support for Pentium-class processors. Plus a lot of goodies.

As long as the value of a compiler exceeds its price, it's a good deal. But, many people will pay any price, to steal the registered versions.

Post by Saša Janiška
So, if someone provides freely available compiler for Modula-2, there
will be people tinkering with it. Iirc, Pascal is still used by lot of
people (TIOBE index even hsows increasing market share).

These compilers already exist and they're not used. Why? Because 'C' is considered a potent and powerful language, possibly because there are a lot of books written around it. And many users. If you can program in a cryptic syntax language, people may consider you a sorcerer. Riding a two wheeled bike gives more esteem than riding a trike.

There are GOOD and FREE compilers for Pascal, Modula-2, Oberon available. People just decide not to use it.

There are also commercial versions around. For example the Astrobe Oberon compiler for ARM. It's an affordable compiler. Unfortunately only for Windows. But at the given price.... you get a lot of compiler.

Post by Saša Janiška

Post by j***@gmail.com
By design of the users. The 'normal' users need flying pigs on their
desktop, singing christmas songs. And they want Bluetooth. And USB.
And WiFi. And all at once.

And they buy it since they can afford it. :-)

No they buy Windows because it was pre-installed. You just cannot buy computers without a Windows pre installed by the manufacturer. And you paid for it. And you didn't object.

Pre-installed Windows is a kind of computer tax. You cannot get around it, unless you buld your own. For a desktop this is no problem. But for a laptop your only option is to pay the tax. And Microsoft doesn't care if you can afford it or not: "swallow or choke in it" is their motto.

Post by Saša Janiška
Sincerely,
Gour

Gour = Saša Janiška ? Is there a third identity as well?

[Marco van de Voort]

Post by Saša Janiška
I can agree that supporting ancient OS-es might not be practical, but
cannot agree there is need for compiled languages...Just see: Go, Rust,
Nim, Crystal...to mention just a few.

Vs C,C++,Java and C#, to just name the most popular ones? I haven't even
heard of the two last ones you name.

The cloud giants (google,facebook etc) invest heavily in scripting language
optimization for their always-on server side systems. And they buy their
hardware in bulk cut down to what they need, and build several new
datacenters per year.

You should ask yourself if that. I pay more for rackspace than what is
actually in the rack, so it better be somewhat efficiently used.

Also because of economic reasons, scaling to two sockets is a lot more
expensive, to 4 four sockets even worse, and to higher socket numbers next
to impossible (except when you land the kind of customers that only appear
in dreams)

So two machines is better than one, and the more I can shoehorn on them the
better.

Post by Saša Janiška
Moreover, I do not see what would Modula-2 interpreter be good for when
there are several languages (e.g. Nim/Crystal) offering syntaxes similar
to dynamic languages, but with the benefit of static typing.

So the whole language and tools matrix is reduced to static typing and native
compilation vs intepretation? Maybe a /tad/ oversimplified ? :-)

Post by Saša Janiška
Despite of having lot of memory and cpu power, software is also getting
bloated. In today's world people are buying quadcore cpu-powered mobile
phones with Gigs of memory in order to send 140chars msgs while some
years ago I was using less powered desktop machines to render video -
strange, but that's reality. :-)

Basically people navigate performance issues the same way they do physical
inconvenience and pain. They can stand surprising levels of it if you let it
creep up on them.

[Pascal J. Bourguignon]

Post by Marco van de Voort

Post by Saša Janiška
I can agree that supporting ancient OS-es might not be practical, but
cannot agree there is need for compiled languages...Just see: Go, Rust,
Nim, Crystal...to mention just a few.

Vs C,C++,Java and C#, to just name the most popular ones? I haven't even
heard of the two last ones you name.
The cloud giants (google,facebook etc) invest heavily in scripting language
optimization for their always-on server side systems. And they buy their
hardware in bulk cut down to what they need, and build several new
datacenters per year.

You should not confuse "scripting" (or batch vs. interactive use, which
is a third consideration) with the implementation strategy.

And there are more than just two implementation strategies "compiled" or
"interpreted".

From an implementation point of view, I find that it's often easier to
write a compiler (targetting a virtual machine, and implementing a VM
"interpreter"), than to write a direct interpreter.

But this is unrelated to the ability of the resulting system to build
programs incrementally and interactively (ie. having a REPL), vs. a more
batch oriented system.

You can write for any language, implementations that are in the cross
product of { interpreted, compiled,
compiled-to-byte-code-interpreted-in-a-vm,
compiled-to-byte-code-translated-just-in-time,
etc, etc } x { interactive, batch, etc }.

And then there are languages that are easier to use to write "scripts"
and other that are easier to use to write other classes of programs,
whatever "script" may mean.


Some people consider that you are writing a script, when your program
makes uses of a lot of external programs. Then having a way to easily
write such invocations (and the afferent combination of input and output
data flows) in the language makes it a "scripting" language.

But between a DSL like a shell command interpreter, and a classic
algorithmic programming language, the only difference will be whether
the language allows you to extend it with a DSL that is easy to use
(ie. with a syntax that integrates well with the language for purpose of
running external programs).

Notice that shell command interpreters are not a panacea or even a local
optimimum in this domain, given the difficulties you can encounter with
them as soon as you need to do anything out of the common case, like
writing a script to run commands running on a remote host thru ssh, or
even locally, if you have to build sql requests to be executed locally.
You quickly reach the limits of the rudimentary syntax and abstration
tools provided by shell command interpreters in terms of meta-programming.

On the other hand shell command interpreters demonstrate the
orthogonality between "scripting"; and interactive vs. batch
programming, since you can use most of them both as interactive shells,
and as batch command interpreters!

Post by Marco van de Voort

Post by Saša Janiška
Moreover, I do not see what would Modula-2 interpreter be good for when
there are several languages (e.g. Nim/Crystal) offering syntaxes similar
to dynamic languages, but with the benefit of static typing.

So the whole language and tools matrix is reduced to static typing and native
compilation vs intepretation? Maybe a /tad/ oversimplified ? :-)

Post by Saša Janiška
Despite of having lot of memory and cpu power, software is also getting
bloated. In today's world people are buying quadcore cpu-powered mobile
phones with Gigs of memory in order to send 140chars msgs while some
years ago I was using less powered desktop machines to render video -
strange, but that's reality. :-)

Basically people navigate performance issues the same way they do physical
inconvenience and pain. They can stand surprising levels of it if you let it
creep up on them.

Or display a progress bar.

[Marco van de Voort]

Post by Pascal J. Bourguignon

Post by Marco van de Voort
The cloud giants (google,facebook etc) invest heavily in scripting language
optimization for their always-on server side systems. And they buy their
hardware in bulk cut down to what they need, and build several new
datacenters per year.

You should not confuse "scripting" (or batch vs. interactive use, which
is a third consideration) with the implementation strategy.

You seem to focus on the concept of shell, something I didn't even hint at,
nor at extensibility of the language.

Modifying running programs might be as simple as modifying the source.
Admitted, that doesn't preclude compiling (JIT and normal) in essence, but
the balance in general goes to the scripting side.

[Pascal J. Bourguignon]

Post by Marco van de Voort

Post by Pascal J. Bourguignon

Post by Marco van de Voort
The cloud giants (google,facebook etc) invest heavily in scripting language
optimization for their always-on server side systems. And they buy their
hardware in bulk cut down to what they need, and build several new
datacenters per year.

You should not confuse "scripting" (or batch vs. interactive use, which
is a third consideration) with the implementation strategy.

You seem to focus on the concept of shell, something I didn't even hint at,
nor at extensibility of the language.
Modifying running programs might be as simple as modifying the source.
Admitted, that doesn't preclude compiling (JIT and normal) in essence, but
the balance in general goes to the scripting side.

It would also be interesting to consider languages like Wolfram's
language, a kind of mega-scripting-language (not meta-).

http://www.wolfram.com/language/elementary-introduction/35-natural-language-understanding.html
http://www.wolfram.com/language/elementary-introduction/44-importing-and-exporting.html

:-)

[trijezdci]

Post by r***@gmail.com
*** simpleTerm ***
@ line: 120, column: 8, lookahead: NOT
line: 120, column: 8, unexpected reserved word NOT found
expected identifier, string, integer, real number, character code, '(' or '{'.
IF NOT Done THEN WriteString("Oops!"); WriteLn; HALT END;

[snip]

Post by r***@gmail.com
C:\tmp>trijezdci\m2c m2p.mod --pim3
m2c Modula-2 Compiler & Translator, version 1.00
line: 98, column: 19, unexpected symbol '[' found
expected symbol ';'
TYPE
natural = INTEGER[0..32767];

I posted links to the relevant commits in the M2C thread because this is not related to DOS and doesn't fit the topic here.

[r***@gmail.com]

Hi,

Post by trijezdci

Post by r***@gmail.com
C:\tmp>trijezdci\m2c m2p.mod --pim3
m2c Modula-2 Compiler & Translator, version 1.00

I posted links to the relevant commits in the M2C thread because
this is not related to DOS and doesn't fit the topic here.

Okay, but technically, I was testing it under DOS(EMU), as indicated
by the "C:\tmp>" prompt. Yes, the same build I made a few days ago.
Irrelevant, I know, but still, I tried!

[trijezdci]

Post by r***@gmail.com

Post by trijezdci
I posted links to the relevant commits in the M2C thread because
this is not related to DOS and doesn't fit the topic here.

Okay, but technically, I was testing it under DOS(EMU)

I am not complaining, I just wanted to leave a reference.

[Martin Brown]

Post by r***@gmail.com
The _stat functions are documented on the Microsoft site.
I also assume those will work on DOS, not only on Windows.

They will work in a DOS environment under Windows. They might work in a
native bare DOS environment with the right DLLs but I wouldn't like to
bet on it. Things can get ugly with modern code on old bare MSDOS.

I don't think it makes sense to support any Windows/DOS environments
prior to WinXP unless it turns out by serendipity that it works on them.

Post by r***@gmail.com
If you move to Windows, best leave your Dos legacy at the door.
Windows NT and Dos are mostly unrelated. Windows 64-bit doesn't
even run dos apps.
Well, BSD, Linux and MacOS X -- 64 bit or not -- do run DOS apps
via a utility called DOSbox which many folks are using and this
allows you to share directories with the host system. It is
therefore desirable to have M2C build and run under DOSbox.

Doesn't it only need to run under DOSbox if you make a trusted signed
executable available for anyone that wants to use it. It could be cross
compiled from a Unix box with flags configured for the DOS runtime.

Post by r***@gmail.com
Turbo C 2.01 is available from the Borland Musuem (via the
Wayback Machine) and is easilly installed under DOSbox.
Okay, so here's the deal: I think talking about DOS (here) is
a waste of time. I seriously doubt that anyone here (besides me)
is interested. I don't think it's worth worrying about, but hey,
some of you did mention it.

Enough Posix function support is available in the Windows environment
that with a bit of creativity any missing features can be emulated. The
only really nasty gotcha is fork() which is notable by its absence.