Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Rugxulo]

Hi,

On Sun, Jun 7, 2020 at 10:54 AM dmccunney  wrote:
>
> On Sat, Jun 6, 2020 at 9:37 PM Rugxulo  wrote:
> >
> > Make is a fairly useful util and a great idea, but it's also a
> > portability nightmare (isn't everything?). So it's hard to do anything
> > perfectly.
>
> I have unfond memories of trying to build stuff with make, and
> discovering that the make I was using required *tabs* as separators in
> some areas, and would fail if spaces were used instead. (Editors I use
> tend to convert tabs to spaces.)

That depends on your text editor: some are more obvious than others
(e.g. Mined or TDE).

You can also preprocess your makefiles before using them (e.g. JED).

> I don't recall that particular requirement being *documented* anywhere,
> and since tabs are non-printing chars you have to jump through various hoops 
> to
> explicitly display, looking at the makefile was no help, because you
> would see blank spaces and not realize they were generated by tabs
> instead of space chars.

Most "modern" Makes can avoid tabs entirely:  GNU Make (since 3.82),
Dmake, Wmake, TC++ Make, etc.
It's only confusing due to naivete or lack of documentation or
examples. It's easy to get lost in a sea of features and
incompatibilities (among other problems).

> But make can be considered a language, and folks have done stuff in
> make that has nothing to do with building code.

You mean like all the GNU Make extensions? I wouldn't quite call it a
"language" proper, but it does have many extras. It's somewhat useful
but also still problematic.

There are no easy solutions to many problems, or at least "good"
solutions aren't obvious for the first thousand revisions. Thankfully,
some tools help more than they hurt.

Some programming languages don't need outside build tools at all (or
only rarely). But even that varies with implementation. Free Pascal
(like Turbo) does use Makefiles sometimes, but normally it
automatically finds all unit dependencies ("-m" only makes what's
needed else "-b" to rebuild entirely from scratch).

> > GNU only recommends these utilities:
> >
> > * 
> > https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html
>
> And for good reason.  Make may be portable.  The code you build using
> it may not be, and architectural differences in the targets can bite.
> "Make relies on the following tools. Make sure versions of them are
> available on the system  where you are building" is sound advice.  So
> is advice like "Don't create symlinks in make, because they may not be
> available on the target of your build."

That is advised but not mandated. Mostly, you don't want to cut off
contributors just because their host OS is different than yours.
However, time is scarce, motivation is low, so most projects aren't
that portable, even when they could be. "Linux or Windows" seems bare
minimum, and even that is spotty or sometimes avoided.

> C++ has come a *long* way.  Bjarne Sjoustroup created it while at
> AT  AT Unix's first C++ compiler was cfront.  Cfront was a front
> end that parsed your c++ code and converted it to standard C, which
> could be compiled by cc to asm, assembled by as, and linked by ld to
> create an executable.  I asked about that at a talk Sjoustroup gave at
> a Unix users group meeting.

C++ had to abandon that approach for exceptions, IIRC. (Many good
ideas from C++ were later incorporated into "standard" C.)

> He said that people had been wishing for years for a truly portable
> assembly language, and they finally realized that's essentially what C
> was.  C was designed to be portable, and efficient enough that you
> didn't have to write in assembler to get performance.  Unix was
> originally written in the MACRO-11 assembly language provided by DEC
> in the system used to originally develop Unix.  When C became mature
> enough, most of Unix was rewritten in it.  If memory serves, perhaps
> 10% of the really low level code that talked to the hardware remained
> in assembler.

Fortran predates C and was intended to be easier to read/write while
also being as efficient as (non-portable) assembly. Even Algol (etc.)
was meant to be a readable but portable HLL (international algorithmic
language).

But portability is hard, and C has many problems (by default),
especially to those who are inexperienced. It's not that it's
impossible or totally broken, just confusing and not obvious. It's
*very* easy to write code that doesn't work on other cpu architectures
or even compiler-specific (won't work with others). Not that other
languages aren't horribly bad about it, too (TP7 DOS 16-bit specific
code, ugh).

> AT implemented the original C++ as a parser converting to standard C
> because the hardware to support a native C++ compiler wasn't generally
> available.  As more powerful hardware became available, true C++
> compilers appeared.

I believe Walter Bright wrote the first native C++ compiler. But
talking about AT 2.0 "pre-standard" from 1990 versus "ISO standard"

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[dmccunney]

On Sat, Jun 6, 2020 at 9:37 PM Rugxulo  wrote:
> On Tue, Jun 2, 2020 at 12:26 PM dmccunney  wrote:
> >
> > > DJGPP make is mainly just a port of GNU make, is it not?
> >
> > Well, as part of a port of the entire Gnu/Linux toolchain, including
> > GCC.  Things like Scons are displacing make in some contexts, but make
> > isn't going away.
>
> Make is a fairly useful util and a great idea, but it's also a
> portability nightmare (isn't everything?). So it's hard to do anything
> perfectly.

I have unfond memories of trying to build stuff with make, and
discovering that the make I was using required *tabs* as separators in
some areas, and would fail if spaces were used instead. (Editors I use
tend to convert tabs to spaces.)  I don't recall that particular
requirement being *documented* anywhere, and since tabs are
non-printing chars you have to jump through various hoops to
explicitly display, looking at the makefile was no help, because you
would see blank spaces and not realize they were generated by tabs
instead of space chars.

But make can be considered a language, and folks have done stuff in
make that has nothing to do with building code.

> Scons relies on Python, as do many things. POSIX Make seems somewhat
> rare, so many projects just use GNU Make as the "portable"
> alternative. CMake is popular, so is Meson (with NInja). But I'm not
> directly familiar with most of them.

There are other things as well. A partial list is here:
http://texteditors.org/cgi-bin/wiki.pl?UnixMake

> GNU only recommends these utilities:
>
> * 
> https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html

And for good reason.  Make may be portable.  The code you build using
it may not be, and architectural differences in the targets can bite.
"Make relies on the following tools. Make sure versions of them are
available on the system  where you are building" is sound advice.  So
is advice like "Don't create symlinks in make, because they may not be
available on the target of your build."

> I know nothing about C++, but the latest '20 standard has modules,
> which will probably speed up and simplify makefiles in the future
> (hopefully). But I don't think major compilers are quite there yet
> (but fairly close).
>
> * https://gcc.gnu.org/projects/cxx-status.html
>
> This is a big change and important to do correctly. So I don't blame
> them for taking their time (not to mention that C++17 wasn't that long
> ago and is generally fully supported).

C++ has come a *long* way.  Bjarne Sjoustroup created it while at
AT  AT Unix's first C++ compiler was cfront.  Cfront was a front
end that parsed your c++ code and converted it to standard C, which
could be compiled by cc to asm, assembled by as, and linked by ld to
create an executable.  I asked about that at a talk Sjoustroup gave at
a Unix users group meeting.

He said that people had been wishing for years for a truly portable
assembly language, and they finally realized that's essentially what C
was.  C was designed to be portable, and efficient enough that you
didn't have to write in assembler to get performance.  Unix was
originally written in the MACRO-11 assembly language provided by DEC
in the system used to originally develop Unix.  When C became mature
enough, most of Unix was rewritten in it.  If memory serves, perhaps
10% of the really low level code that talked to the hardware remained
in assembler.

AT implemented the original C++ as a parser converting to standard C
because the hardware to support a native C++ compiler wasn't generally
available.  As more powerful hardware became available, true C++
compilers appeared.

> (I did buy a DOS-based, pre-standard C++ book [1995] in 1998 with a
> floppy containing Turbo C++ Lite. How quaint. I half read it but
> didn't stick with it. There are better modern C++ books nowadays,
> obviously.)

More than I can count.

> > > As for the AWK portion, I have tested my script for munging the
> > > GW-BASIC source files with both GNU awk (gawk) and mawk.
> >
> > Were any changes required to your original script to get it to work as
> > expected in gawk *and* mawk?
>
> There's always "dark corners" (as GAWK would call it), but mostly it
> should work okay. Just be sure to rigorously test everything before
> publishing (or at least mention exactly what version and OS you tested
> on somewhere). Yes, I found some avoidable quirks by testing various
> AWK interpreters on some simple scripts. Standards are good, but
> actual testing of existing implementations is more crucial than
> theoretical success. (Don't be a purist! Make it work with what you
> have available.)

The problem with standards is that everyone will have their own take
on how to implement them, and I haven't seen a standard yet that
didn't have grey areas, where people trying to implement them could
come up with things that both adhered to the standard as written, but
were incompatible in practice.  IIRC, POSIX has a lot of areas like
that.

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Rugxulo]

Hi,

On Tue, Jun 2, 2020 at 2:08 PM dmccunney  wrote:
>
> On Mon, Jun 1, 2020 at 5:30 PM Rugxulo  wrote:
> >
> > I don't think this particular BASIC is a compiler, only an
> > interpreter. (The very first BASIC was a compiler.)
>
> Doesn't matter.  You can create an entire application in an
> interpreted language, and people did.  And BASIC being interpreted on
> early machines was likely a matter of hardware available.  Kemeny and
> Kurtz were working on larger multi-user systems. Consider the
> Commodore 64, which had MS BASIC v2 embedded.  When you booted it, you
> were in the interpreter, talking to BASIC.  BASIC on that machine was
> embedded in a 8KB ROM.

Except for graphics and sound (which are apparently missing here), aka
machine specific, I still think AWK is probably "better" than
non-structured GW-BASIC.

Of course, QBASIC (non-standard, well ... "de facto" standard, circa
1988/1991) fixed and added a lot. So, lots of people did cool things
with that. Since it was installed by default in MS-DOS 5 (and others??
OS/2? NT?), it might make more sense to target that than other tools,
if you needed a quick script to do something. But since FreeBASIC's
"lang qb" is imperfect (not that I really tested QB64 either), maybe
relying on "POSIX" AWK is good enough. (N.B. FreeBASIC [since 2004]
compiles itself using auxiliary DJGPP tools.)

> Awk and REXX are script languages, and were generally interpreted.

Not to split hairs, but many of these "interpreters" are byte-code interpreters.

> Awk is used in things like pipelines, where you call awk to query and
> process a text file and pass the results to something else.  REXX was
> the next generation of script language on IBM mainframes, intended to
> provide more power than CLISTs.

REXX was meant to be simple to learn and use, even for
non-programmers. It was, roughly speaking, an easier version of PL/I.
It was meant as both a scripting language and a macro language. No
reserved keywords, no pointer manipulation, automatic garbage
collection (no memory leaks), easy to use stems (associative arrays)
with various built-in functions (BIFs). Or something like that.

> REXX subsequently got brought up under other architectures.  (I have a 
> version that works under Palm OS.)

Yes, Howard Fosdick wrote a nice book on it (that I haven't fully read
yet), also available as an e-book. Not sure when OS/2 first got REXX
(1.3?), but it was very popular there. Even PC-DOS (2000?) dropped
QBASIC for REXX. (The ANSI REXX standard was in '96, but most people
seemingly prefer non-standard ooREXX for Smalltalk-ish OOP. Regina
doesn't support that. So TRL2 is version 4 while ANSI is 5 and OOP is
6. You can check at runtime which standard "version" you're running.)

> > (untested by me, but just FYI)
> > * http://awka.sourceforge.net/index.html
>
> Convert awk to C, then compile to an executable.  I recall hearing
> back when that AT was working on an awk compiler.  I have no idea if
> this bears any relation to that effort.

Maybe BWK wrote a C++ transpiler for it?? Dunno. Anyways, this one is
apparently based upon MAWK, which is a byte-code interpreter
("faster").

I never used classic Visual BASIC, but something like v4 was bytecode,
v5 was 32-bit, v6 was translated to C and compiled behind the scenes.
Something like that, I forget the details. That classic version was
last updated in '98, and then came the .NET versions. (Even VB.NET is
somewhat falling behind these days, allegedly.)

Lots of languages compile to C, and FreeBASIC can optionally do so too
(since it's not very optimizing).

> > I'm actually a bigger fan of Sed, but that's much more limited
> > (intentionally?).
>
> Intentionally.  It has a different use case than awk.  SED is a stream
> editor, explicitly intended to be called in a pipeline to perform
> *scripted* edits on what is fed to it.

Most small Sed interpreters are based upon your friend ESR's work
(e.g. minised). Sed is a very well-designed tool and works great, but
still there are several "dark corners" regarding portability. It's
almost unavoidable in the "real world", but it still works fairly
well. GNU Sed is still built for DJGPP by some volunteers and also
works pretty well.

I honestly wouldn't want to prefer QBASIC to that, but in DOS circles,
if Edlin didn't cut it, QBASIC probably made more sense (rather than
rolling a more limited homegrown tool in C or assembly, although even
that isn't a horrible idea sometimes).

> One bit often missed by DOS folks back in the day was that *EDLIN*
> could be used that way.  Advanced batch programmers in environments
> like corporate installations where they weren't allowed to install
> third party code used EDLIN where they might otherwise have installed
> SED.

Yes, and while I'm somewhat sympathetic there, I still never used
Edlin much. (DR-DOS 7.03 didn't have Edlin nor QBASIC.) My old Vista
32-bit laptop still had DOS versions of Debug and Edlin, though.

> > In recent years, BWK wrote a book 

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Rugxulo]

Hi,

On Tue, Jun 2, 2020 at 12:26 PM dmccunney  wrote:
>
> > DJGPP make is mainly just a port of GNU make, is it not?
>
> Well, as part of a port of the entire Gnu/Linux toolchain, including
> GCC.  Things like Scons are displacing make in some contexts, but make
> isn't going away.

Make is a fairly useful util and a great idea, but it's also a
portability nightmare (isn't everything?). So it's hard to do anything
perfectly.

Scons relies on Python, as do many things. POSIX Make seems somewhat
rare, so many projects just use GNU Make as the "portable"
alternative. CMake is popular, so is Meson (with NInja). But I'm not
directly familiar with most of them.

GNU only recommends these utilities:

* https://www.gnu.org/software/make/manual/html_node/Utilities-in-Makefiles.html

I know nothing about C++, but the latest '20 standard has modules,
which will probably speed up and simplify makefiles in the future
(hopefully). But I don't think major compilers are quite there yet
(but fairly close).

* https://gcc.gnu.org/projects/cxx-status.html

This is a big change and important to do correctly. So I don't blame
them for taking their time (not to mention that C++17 wasn't that long
ago and is generally fully supported).

(I did buy a DOS-based, pre-standard C++ book [1995] in 1998 with a
floppy containing Turbo C++ Lite. How quaint. I half read it but
didn't stick with it. There are better modern C++ books nowadays,
obviously.)

> > As for the AWK portion, I have tested my script for munging the
> > GW-BASIC source files with both GNU awk (gawk) and mawk.
>
> Were any changes required to your original script to get it to work as
> expected in gawk *and* mawk?

There's always "dark corners" (as GAWK would call it), but mostly it
should work okay. Just be sure to rigorously test everything before
publishing (or at least mention exactly what version and OS you tested
on somewhere). Yes, I found some avoidable quirks by testing various
AWK interpreters on some simple scripts. Standards are good, but
actual testing of existing implementations is more crucial than
theoretical success. (Don't be a purist! Make it work with what you
have available.)


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[TK Chia]

Hello Dennis,


As for the AWK portion, I have tested my script for munging the
GW-BASIC source files with both GNU awk (gawk) and mawk.

Were any changes required to your original script to get it to work as
expected in gawk *and* mawk?


To my surprise, no, not at all. :-)

Thank you!

--
https://github.com/tkchia


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[dmccunney]

On Mon, Jun 1, 2020 at 5:30 PM Rugxulo  wrote:
> On Sun, May 31, 2020 at 11:26 PM dmccunney  wrote:
> > On Sun, May 31, 2020 at 10:35 PM Rugxulo  wrote:
> >
> > > So no, I haven't tried rebuilding this (yet?), and I'm no *nix fiend,
> > > but I do think AWK is a cool tool, maybe cooler than GW-BASIC (don't
> > > kill me!).
> >
> > AWK is a cool tool.  But it's not a full programming language for
> > building stand alone apps.  GWBASIC is.
>
> I don't think this particular BASIC is a compiler, only an
> interpreter. (The very first BASIC was a compiler.)

Doesn't matter.  You can create an entire application in an
interpreted language, and people did.  And BASIC being interpreted on
early machines was likely a matter of hardware available.  Kemeny and
Kurtz were working on larger multi-user systems. Consider the
Commodore 64, which had MS BASIC v2 embedded.  When you booted it, you
were in the interpreter, talking to BASIC.  BASIC on that machine was
embedded in a 8KB ROM.

> But there actually are compilers for AWK out there, even REXX! But
> most implementations don't do that. (Why bother? Interpreted is often
> fast enough.)

Awk and REXX are script languages, and were generally interpreted.
Awk is used in things like pipelines, where you call awk to query and
process a text file and pass the results to something else.  REXX was
the next generation of script language on IBM mainframes, intended to
provide more power than CLISTs.  (I was a dab hand at CLIST
programming back when.)  But you got REXX as a component of IBM's
VM/CMS OS.  VM was actually intended as a hypervisor, allowing you to
run other IBM mainframe OSes under it.  It was popular for cases like
taking code written for DOS/VSE and converting it to run under OS/MVS.
You could bring each up in a partition, with a production partition
running DOS/VSE, and a test partition where you handled conversions
and made sure things worked as expected under MVS.  Once you had
completed conversion and testing, with verification that everything
worked as designed, you could take down the DOS/VSE partition and make
the MVS partition the production environment.  (IIRC, VM/CMS imposed
about a 10% overhead, which is remarkably good. REXX subsequently got
brought up under other architectures.  (I have a version that works
under Palm OS.)

But hey, there are compilers for DOS batch files... :-p

> (untested by me, but just FYI)
> * http://awka.sourceforge.net/index.html

Convert awk to C, then compile to an executable.  I recall hearing
back when that AT was working on an awk compiler.  I have no idea if
this bears any relation to that effort.

> I'm actually a bigger fan of Sed, but that's much more limited
> (intentionally?). Also, AWK vaguely reminds me of REXX in
> functionality (although that, too, I only lightly dabbled in).
> Obviously, REXX was more known on IBM mainframes and OS/2.

Intentionally.  It has a different use case than awk.  SED is a stream
editor, explicitly intended to be called in a pipeline to perform
*scripted* edits on what is fed to it.

One bit often missed by DOS folks back in the day was that *EDLIN*
could be used that way.  Advanced batch programmers in environments
like corporate installations where they weren't allowed to install
third party code used EDLIN where they might otherwise have installed
SED.

> In recent years, BWK wrote a book on Go. That language has come a long
> way and done a lot. A lot of people from Plan 9 still work on that.
> Oh, one guy did write a compatible implementation of AWK in Go!

The main honcho behind Go is Rob Pike, with Ken Thompson and Robert
Griesemer contributing.  (Griesmer was a main developer for the V8
JavaScipt engine.)Pike and Thompson were colleagues of Kernighan
back the AT Bell Labs in Murray HILL NJ when Thompson and Kernighan
were designing Unix and Dennis Ritchie was developing the C language.
Go is specifically intended for concurrent programming, and addresses
weaknesses in C/C++ (primarily in memory management) that bite when
you are trying to create concurrent code.  Go's intent is to handle
the memory management for the developer, so they can just develop code
and not have to worry about it.

Open source advocate Eric S. Raymond has largely switched to Go these
days.  A paying project he's technical lead on is updating NTP.  That
was a morass of security holes and being used in DDOS attacks.  The
first challenge was scraping away decades of accumulated cruft in the
form of special case code for various old architectures and
environments.  The last I knew, his current version of the core NTP
code is about 70% smaller than the C code it replaced, and is far more
secure.  Many recent security bugs filed against NTP don't exist on
his code because his code removes the attack surfaces they target.  Go
turned out to be just the thing to use for the project.

> > It was initially written to perform "one liners", where you invoked awk
> > on a command line with the commands to 

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[dmccunney]

On Tue, Jun 2, 2020 at 10:50 AM TK Chia  wrote:
> >> On a side note, you're using GNU Make and AWK (to cross-build?). I do
> >> wonder if DJGPP Make (or even other AWK implementations) would work
> >> for us here.
>
> DJGPP make is mainly just a port of GNU make, is it not?

Well, as part of a port of the entire Gnu/Linux toolchain, including
GCC.  Things like Scons are displacing make in some contexts, but make
isn't going away.

> As for the AWK portion, I have tested my script for munging the
> GW-BASIC source files with both GNU awk (gawk) and mawk.

Were any changes required to your original script to get it to work as
expected in gawk *and* mawk?

> > Awk is still useful on *nix - various things like build recipes may
> > use it in scripts - but for most purposes, perl has replaced it.  (I
> > consider that a pity.  Awk is smaller and faster, and perl may be
> > overkill for a lot of what you might need to do.  Former Busybox
>
> Agreed.  In fact I wrote an earlier version of my source-file-munging
> script in Perl, but later rewrote it in AWK. :-)



On the Linux side, I am seeing distros that no longer use text files
for configuration, and do everything in Python. Python is a cool
language, but if perl was overkill, Python is mass destruction.
Config files in plain text you can look at to see what they say and
how things are configured have attractions.
__
Dennis


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[TK Chia]

Hello Rugxulo, hello Dennis,

>> What exactly does "semi-working" mean? It seems like graphics commands
>> aren't supported? That's no biggie (IMHO) as long as it can do simple
>> file I/O.

Well, direct commands seem to be working quite OK.  But yes, large
chunks of functionality --- graphics, (PC speaker) audio,
serial/parallel ports, etc. --- are simply not there yet.  And, I have
not quite fully tested the parts that are there.

There is still a long way to go, and I can probably use some help here.


Thank you. I never understand when people prefer ancient MASM over modern JWasm.


Well, this GW-BASIC version (1983) was written before JWasm even
existed.  (I guess we cannot fault the Microsoft developers then for not
catering to a build tool that simply wasn't.)


On a side note, you're using GNU Make and AWK (to cross-build?). I do
wonder if DJGPP Make (or even other AWK implementations) would work
for us here.


DJGPP make is mainly just a port of GNU make, is it not?  As for the AWK
portion, I have tested my script for munging the GW-BASIC source files
with both GNU awk (gawk) and mawk.


Awk is still useful on *nix - various things like build recipes may
use it in scripts - but for most purposes, perl has replaced it.  (I
consider that a pity.  Awk is smaller and faster, and perl may be
overkill for a lot of what you might need to do.  Former Busybox


Agreed.  In fact I wrote an earlier version of my source-file-munging
script in Perl, but later rewrote it in AWK. :-)

Thank you!

--
https://github.com/tkchia


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[tom ehlert]

PLONK

am Montag, 1. Juni 2020 um 23:28 schrieben Sie:

> Hi,

> On Sun, May 31, 2020 at 11:26 PM dmccunney
>  wrote:
>>
>> On Sun, May 31, 2020 at 10:35 PM Rugxulo  wrote:
>>
>> > So no, I haven't tried rebuilding this (yet?), and I'm no *nix fiend,
>> > but I do think AWK is a cool tool, maybe cooler than GW-BASIC (don't
>> > kill me!).
>>
>> AWK is a cool tool.  But it's not a full programming language for
>> building stand alone apps.  GWBASIC is.

> I don't think this particular BASIC is a compiler, only an
> interpreter. (The very first BASIC was a compiler.)

> * https://time.com/69316/basic/ (fifty years of BASIC)

> But there actually are compilers for AWK out there, even REXX! But
> most implementations don't do that. (Why bother? Interpreted is often
> fast enough.)

> (untested by me, but just FYI)
> * http://awka.sourceforge.net/index.html

>> AWK (the initials of Alfred Aho, Thomas Weinberger, and Brian
>> Kernighan, the authors)  was a tool intended for querying and
>> modifying the contents of text files.

> * https://en.wikipedia.org/wiki/AWK

> I'm actually a bigger fan of Sed, but that's much more limited
> (intentionally?). Also, AWK vaguely reminds me of REXX in
> functionality (although that, too, I only lightly dabbled in).
> Obviously, REXX was more known on IBM mainframes and OS/2.

> In recent years, BWK wrote a book on Go. That language has come a long
> way and done a lot. A lot of people from Plan 9 still work on that.
> Oh, one guy did write a compatible implementation of AWK in Go!

> * https://golang.org/
> * https://github.com/benhoyt/goawk

>> It was initially written to perform "one liners", where you invoked awk
>> on a command line with the commands to execute and the data to examine.

> I don't think UNIX originally came with a C compiler (except maybe
> add-on?), so all you had was Sh and AWK.

>> I attended a talk given by Weinberger  decades ago where he described his 
>> shock on first
>> seeing a multi-line awk script.

> Yeah, here's a good interview with Alfred V. Aho.

> *
> http://web.archive.org/web/20101119053641/http://www.techworld.com.au/article/216844/a-z_programming_languages_awk/

>> Awk is still useful on *nix - various things like build recipes may
>> use it in scripts - but for most purposes, perl has replaced it.  (I
>> consider that a pity.

> I respect Larry Wall and Perl but never learned it. Honestly, I
> dislike the various versions and non-standard incompatibilities. It's
> a bit too brittle to rely upon (isn't everything? even "standards"
> have many holes, buggy implementations; so, that's not really a Perl
> problem, per se, just "life").

>> Awk is smaller and faster, and perl may be overkill for a lot of what you 
>> might need to do.

> Sed is much lighter than AWK, so yes, even AWK can be overkill. Maybe
> even Sed is overkill for some things. (Sed came from Ed, so I guess
> Edlin would be loosely comparable in DOS circles.)

>> Former Busybox maintainer Rob Landley griped elsewhere about sending patches 
>> to
>> remove the dependency on Perl from Linux kernel builds, since awk did
>> all that was needed, only to find it reappear again.)

> I once told you that he should just use (BSD-licensed) AWK from old
> Minix 2.x for ToyBox. Not sure if that's truly practical advice,
> though.

> Yes, Perl is overkill. You know, I rebuilt old NASM 0.98.39 [2005]
> recently for 8086. (Pre-existing 16-bit DOS binaries were 186 only,
> ugh, heheh.) Actually, I rebuilt it several times and (sometimes) used
> Sed. Regenerating the instruction source files (for instance, to fit
> into Large memory model with Turbo C++ 1.01) required omitting some
> unnecessary things (e.g. MMX, SSE ... not commonly used in DOS). In
> ancient NASM 0.97, there was a quick kludge to use QBASIC to
> regenerate those source files, but it was later dropped (broken?
> unmaintained?). 0.98.39 used Perl, which works but is bloated (and our
> only DOS build still is DJGPP's old 5.8.8 from 2007). So I finagled it
> a bit just to use Sed (only), which is much smaller and simpler (thus,
> no Perl required). Oh, I also used AWK behind the scenes a bit to
> help. (I never properly learned Perl but do have a book on it.)

> Yeah, it's just a mess. Big projects are harder to maintain, and
> unfortunately DOS is not "top tier" for most actively-developed
> projects. Just to show how random it all is, we have three AWKs: MAWK
> (DOS+OS/2 dual bound family .EXE) from 1996, BWK AWK from 2010 (OW
> build), and GAWK (DJGPP) from 2019. This also is why our Python
> (DJGPP) is from 2008 (2.4.2 or whatever). Similarly, Regina REXX
> (3.9.1) doesn't directly compile with DJGPP anymore, and I was too
> lazy to investigate further (stuck at 3.7). Ruby 1.8.4 had DJGPP
> binaries, but after 1.8.7, it dropped source support for a lot of OSes
> (although there was later an ISO standard for that). Even the Lua
> (DJGPP) build is still stuck at 5.2.2 (2013). Oh, one guy did
> apparently make LoveDOS 

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Rugxulo]

Hi,

On Sun, May 31, 2020 at 11:26 PM dmccunney  wrote:
>
> On Sun, May 31, 2020 at 10:35 PM Rugxulo  wrote:
>
> > So no, I haven't tried rebuilding this (yet?), and I'm no *nix fiend,
> > but I do think AWK is a cool tool, maybe cooler than GW-BASIC (don't
> > kill me!).
>
> AWK is a cool tool.  But it's not a full programming language for
> building stand alone apps.  GWBASIC is.

I don't think this particular BASIC is a compiler, only an
interpreter. (The very first BASIC was a compiler.)

* https://time.com/69316/basic/ (fifty years of BASIC)

But there actually are compilers for AWK out there, even REXX! But
most implementations don't do that. (Why bother? Interpreted is often
fast enough.)

(untested by me, but just FYI)
* http://awka.sourceforge.net/index.html

> AWK (the initials of Alfred Aho, Thomas Weinberger, and Brian
> Kernighan, the authors)  was a tool intended for querying and
> modifying the contents of text files.

* https://en.wikipedia.org/wiki/AWK

I'm actually a bigger fan of Sed, but that's much more limited
(intentionally?). Also, AWK vaguely reminds me of REXX in
functionality (although that, too, I only lightly dabbled in).
Obviously, REXX was more known on IBM mainframes and OS/2.

In recent years, BWK wrote a book on Go. That language has come a long
way and done a lot. A lot of people from Plan 9 still work on that.
Oh, one guy did write a compatible implementation of AWK in Go!

* https://golang.org/
* https://github.com/benhoyt/goawk

> It was initially written to perform "one liners", where you invoked awk
> on a command line with the commands to execute and the data to examine.

I don't think UNIX originally came with a C compiler (except maybe
add-on?), so all you had was Sh and AWK.

> I attended a talk given by Weinberger  decades ago where he described his 
> shock on first
> seeing a multi-line awk script.

Yeah, here's a good interview with Alfred V. Aho.

* 
http://web.archive.org/web/20101119053641/http://www.techworld.com.au/article/216844/a-z_programming_languages_awk/

> Awk is still useful on *nix - various things like build recipes may
> use it in scripts - but for most purposes, perl has replaced it.  (I
> consider that a pity.

I respect Larry Wall and Perl but never learned it. Honestly, I
dislike the various versions and non-standard incompatibilities. It's
a bit too brittle to rely upon (isn't everything? even "standards"
have many holes, buggy implementations; so, that's not really a Perl
problem, per se, just "life").

> Awk is smaller and faster, and perl may be overkill for a lot of what you 
> might need to do.

Sed is much lighter than AWK, so yes, even AWK can be overkill. Maybe
even Sed is overkill for some things. (Sed came from Ed, so I guess
Edlin would be loosely comparable in DOS circles.)

> Former Busybox maintainer Rob Landley griped elsewhere about sending patches 
> to
> remove the dependency on Perl from Linux kernel builds, since awk did
> all that was needed, only to find it reappear again.)

I once told you that he should just use (BSD-licensed) AWK from old
Minix 2.x for ToyBox. Not sure if that's truly practical advice,
though.

Yes, Perl is overkill. You know, I rebuilt old NASM 0.98.39 [2005]
recently for 8086. (Pre-existing 16-bit DOS binaries were 186 only,
ugh, heheh.) Actually, I rebuilt it several times and (sometimes) used
Sed. Regenerating the instruction source files (for instance, to fit
into Large memory model with Turbo C++ 1.01) required omitting some
unnecessary things (e.g. MMX, SSE ... not commonly used in DOS). In
ancient NASM 0.97, there was a quick kludge to use QBASIC to
regenerate those source files, but it was later dropped (broken?
unmaintained?). 0.98.39 used Perl, which works but is bloated (and our
only DOS build still is DJGPP's old 5.8.8 from 2007). So I finagled it
a bit just to use Sed (only), which is much smaller and simpler (thus,
no Perl required). Oh, I also used AWK behind the scenes a bit to
help. (I never properly learned Perl but do have a book on it.)

Yeah, it's just a mess. Big projects are harder to maintain, and
unfortunately DOS is not "top tier" for most actively-developed
projects. Just to show how random it all is, we have three AWKs: MAWK
(DOS+OS/2 dual bound family .EXE) from 1996, BWK AWK from 2010 (OW
build), and GAWK (DJGPP) from 2019. This also is why our Python
(DJGPP) is from 2008 (2.4.2 or whatever). Similarly, Regina REXX
(3.9.1) doesn't directly compile with DJGPP anymore, and I was too
lazy to investigate further (stuck at 3.7). Ruby 1.8.4 had DJGPP
binaries, but after 1.8.7, it dropped source support for a lot of OSes
(although there was later an ISO standard for that). Even the Lua
(DJGPP) build is still stuck at 5.2.2 (2013). Oh, one guy did
apparently make LoveDOS (Lua, DJGPP) in 2017 for simple 2D games.

It's not that dire. Anybody interested could clean up and fix some of
these. I might even do it myself, but it's not pressing. There's
always more to do.

Sorry 

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[dmccunney]

On Sun, May 31, 2020 at 10:35 PM Rugxulo  wrote:

> So no, I haven't tried rebuilding this (yet?), and I'm no *nix fiend,
> but I do think AWK is a cool tool, maybe cooler than GW-BASIC (don't
> kill me!).

AWK is a cool tool.  But it's not a full programming language for
building stand alone apps.  GWBASIC is.

AWK (the initials of Alfred Aho, Thomas Weinberger, and Brian
Kernighan, the authors)  was a tool intended for querying and
modifying the contents of text files.  It was initially written to
perform "one liners", where you invoked awk on a command line with the
commands to execute and the data to examine.  I attended a talk given
by Weinberger  decades ago where he described his shock on first
seeing a multi-line awk script.

Awk is still useful on *nix - various things like build recipes may
use it in scripts - but for most purposes, perl has replaced it.  (I
consider that a pity.  Awk is smaller and faster, and perl may be
overkill for a lot of what you might need to do.  Former Busybox
maintainer Rob Landley griped elsewhere about sending patches to
remove the dependency on Perl from Linux kernel builds, since awk did
all that was needed, only to find it reappear again.)
__
Dennis


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Rugxulo]

Hi, TK,

On Sun, May 31, 2020 at 9:37 AM TK Chia  wrote:
>
> Thank you for the information.  Building on Spinellis's work, I managed
> to get the source files to build under JWasm and JWlink,

Thank you. I never understand when people prefer ancient MASM over modern JWasm.

> after some source code munging (https://github.com/tkchia/GW-BASIC).
> Many of the needed OEM-specific routines are (still) simply missing from the 
> sources
> though, and must be filled in somehow.

What exactly does "semi-working" mean? It seems like graphics commands
aren't supported? That's no biggie (IMHO) as long as it can do simple
file I/O.

I'll admit, I'm no BASIC guru (I prefer Pascal), so my skills are
limited. But I'm still sympathetic (mostly to QBASIC and FreeBASIC).
Well, your build of this is the only interesting thing so far!

On a side note, you're using GNU Make and AWK (to cross-build?). I do
wonder if DJGPP Make (or even other AWK implementations) would work
for us here.

* https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
* https://www.gnu.org/software/gawk/manual/
* http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/awk/

So no, I haven't tried rebuilding this (yet?), and I'm no *nix fiend,
but I do think AWK is a cool tool, maybe cooler than GW-BASIC (don't
kill me!).


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[TK Chia]

Hello Jim Hall,


Looks like this person is trying to get the source to build. You can follow
or contribute here:
https://github.com/dspinellis/GW-BASIC

On Sat, May 23, 2020, 2:29 PM Random Liegh via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:


I tried it with some old, old versions of MASM and got exactly nowhere.

But then again, I have no idea what I'm doing.

Please let us know how it goes!


Thank you for the information.  Building on Spinellis's work, I managed
to get the source files to build under JWasm and JWlink, after some
source code munging (https://github.com/tkchia/GW-BASIC).  Many of the
needed OEM-specific routines are (still) simply missing from the sources
though, and must be filled in somehow.

Thank you!

--
https://github.com/tkchia


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[dmccunney]

On Sat, May 23, 2020 at 3:28 PM Random Liegh via Freedos-user
 wrote:
>
> The point about MS only open sourcing early and irrelevant versions is valid; 
> but there's another explanation. Those are the versions they have clear legal 
> rights to. On Hacker News someone was saying they wished MS would open source 
> Windows 2000. I strongly suspect that they couldn't even open source Windows 
> 3.1 without stepping into a legal minefield of other people's code.

Very likely.  Current OSes and applications are huge, and the vendor
of the code is vanishingly unlikely to have *written* all of it.
Third party libraries will be rampant.  They may *have* source to
them, but being allowed to *distribute* it is another matter.

An example is Libre Office, an open source, platform independent
office suite that can use and create MS Office compatible files, and
runs on Windows, Linux, and OS/X.

Once upon a time, what became LO was StarOffice, a freeware office
suite from a German vendor that could also  create and use MS Office
files.  It included equivalents of Word, Excel, PowerPoint, and
Access.

Sun Microsystems bought StarOffice gmbh and rebranded StarOffice as
Open Office.  They wanted to make it open source, but ran into a
roadblock.  The database component of StarOffice was provided by a
version of a DBMS from Software AG called Adabas.   (I dealt with
Adabas long ago because the bank I worked for ran a version on a
mainframe.)  StarOffice had a  license from Software AG that woulds
let them distribute a free *binary* of the product, but they could
*not* provide source.  Sun substituted the Java language they had
created to handle database creation and updates, and you needed a
current Sun JRE installed to be able to *use* Base.  (LO will let you
*install* Base with no JRE present, but return odd errors if you try
to use it.)

Oracle bought Sun, and the status of Open Office was in question.
Various players who simply didn't trust Oracle forked the OO code to
create Libre Office.  Oracle finally got around to what they should
have done in the first place, and formally handed to OO code over the
the Apache Foundation, but the damage was done and development had all
shifted to LO.

I understand why someone would wish on Hacker News that MS would open
source Win2K.  What I don't understand is why MS *would*, even if they
had rights to offer source to all of the code.  What would be in it
for MS?  Note that MS *is* open sourcing other current stuff, notably
the .NET framework.  MS engineers are principal contributors to the
Linux Mono project to implement .NET under Linux.  A lot of other
stuff MS is doing now is being released as open source.

But *growth* these days is in cloud services like Azure, and Windows
hasn't been a main driver in MS revenues and profits for a while.  MS
continues to support and develop Windows because Windows runs on a lot
of what you use to *get* to Azure cloud services.

> MS dropped the ball with DOS in 95, and including GWBasic would be symbolic 
> of the way that FreeDOS has carried the torch for approaching 30 years now. I 
> feel like that's another reason to include it -symbolic continuity.

I don't think MS "dropped" the ball so much as *abandoned* it.  MSDOS
was a product specifically intended to run on on older and less
powerful 16 bit machines.  As 32 bit machines with proper hardware
memory management and virtualization, that could *run* multi-user,
multitasking OSes like Windows, OS/2, and Linux, and programs that
could take advantage of the hardware became available, MSDOS became
irrelevant.  How long has it been since DOS was actually *sold* as a
stand alone product, or major applications were still sold for DOS?
Development all migrated to Windows.

(I worked, years back, for a market research firm specializing in high
tech. A client was Lotus Development.  They thought there were still
lots of machines running DOS out there.   I had occasion to talk to
one of their reps and said "I understand you believe there is still a
substantial base of MSDOS users out there, but where are they?  The
*businesses* we call on your behalf to ask what they are using are all
running Windows and Windows programs. If you can tell us where to
*find* DOS users, we'll happily call them to chat.")

The people *running* FreeDOS these days are hobbyists playing with
retro tech for fun, people who still want to play old DOS games (but
you can use emulators like DOSBox to do that), or old timers who got a
DOS setup that worked and you will pry it from their cold, dead
fingers. :-p
__
Dennis


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Harald Arnesen]

Random Liegh via Freedos-user [23.05.2020 21:26]:

> I agree with this being a better alternative to bwbasic, of course since
> both are small and open source I'd request that you include both.

Not better (since bwbasic is cross-platform), but an alternative. And
more compatible with old BASIC programs.
-- 
Hilsen Harald


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Jim Hall]

Looks like this person is trying to get the source to build. You can follow
or contribute here:
https://github.com/dspinellis/GW-BASIC

On Sat, May 23, 2020, 2:29 PM Random Liegh via Freedos-user <
freedos-user@lists.sourceforge.net> wrote:

> I tried it with some old, old versions of MASM and got exactly nowhere.
>
> But then again, I have no idea what I'm doing.
>
> Please let us know how it goes!
>
> On 5/22/2020 6:32 AM, Louis Santillan wrote:
> > I think you're wrong dpirate. I haven't had time to test, but, I would
> > expect [0] to be able to use MASM & LINK from MS-DOS 2.0 [1] to build
> > this.  I plan to throw some cycles at this.
> >
> >
> > [0] https://news.ycombinator.com/item?id=23269345
> > [1] https://github.com/microsoft/MS-DOS/tree/master/v2.0/bin
> >
> > On Fri, May 22, 2020 at 7:08 AM Andy Stamp  wrote:
> >> It looked like this was the x86 output of the meta compiler.  I'm going
> to try to coax the Watcom Assembler into building it this evening.
> >>
> >> On Fri, May 22, 2020 at 8:38 AM Deposite Pirate <
> dpir...@metalpunks.info> wrote:
> >>> This cannot be compiled to machine code because it's some kind of meta
> assembler to generate assembler for various processor architectures and
> this meta assembler is apparently not available. So unless someone goes
> through the pain of reverse engineering this meta assembler this is pretty
> much useless shit, just like MS-DOS 1.x and 2.x.
> >>>
> >>>
> >>> ___
> >>> Freedos-user mailing list
> >>> Freedos-user@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/freedos-user
> >>
> >>
> >> --
> >> --Andy
> >> ___
> >> Freedos-user mailing list
> >> Freedos-user@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/freedos-user
> >
> > ___
> > Freedos-user mailing list
> > Freedos-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Random Liegh via Freedos-user]

I tried it with some old, old versions of MASM and got exactly nowhere.

But then again, I have no idea what I'm doing.

Please let us know how it goes!

On 5/22/2020 6:32 AM, Louis Santillan wrote:

I think you're wrong dpirate. I haven't had time to test, but, I would
expect [0] to be able to use MASM & LINK from MS-DOS 2.0 [1] to build
this.  I plan to throw some cycles at this.


[0] https://news.ycombinator.com/item?id=23269345
[1] https://github.com/microsoft/MS-DOS/tree/master/v2.0/bin

On Fri, May 22, 2020 at 7:08 AM Andy Stamp  wrote:

It looked like this was the x86 output of the meta compiler.  I'm going to try 
to coax the Watcom Assembler into building it this evening.

On Fri, May 22, 2020 at 8:38 AM Deposite Pirate  wrote:

This cannot be compiled to machine code because it's some kind of meta 
assembler to generate assembler for various processor architectures and this 
meta assembler is apparently not available. So unless someone goes through the 
pain of reverse engineering this meta assembler this is pretty much useless 
shit, just like MS-DOS 1.x and 2.x.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user



--
--Andy
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Random Liegh via Freedos-user]

I agree with this being a better alternative to bwbasic, of course since 
both are small and open source I'd request that you include both.


The point about MS only open sourcing early and irrelevant versions is 
valid; but there's another explanation. Those are the versions they have 
clear legal rights to. On Hacker News someone was saying they wished MS 
would open source Windows 2000. I strongly suspect that they couldn't 
even open source Windows 3.1 without stepping into a legal minefield of 
other people's code.


It's probably the same with later versions of DOS and with QuickBasic.

MS dropped the ball with DOS in 95, and including GWBasic would be 
symbolic of the way that FreeDOS has carried the torch for approaching 
30 years now. I feel like that's another reason to include it -symbolic 
continuity.


On 5/22/2020 4:17 AM, Jim Hall wrote:
I saw that! Interesting to see Microsoft releasing more stuff as open 
source, including more of their DOS catalog. I'd really like to see 
them release Word for DOS source code too.


As for GW-BASIC, FreeDOS already includes other BASIC interpreters and 
compilers with equivalent or better functionality, so I don't know 
that we need to add GW-BASIC. I'm not a BASIC programmer, so I'm open 
to suggestion on this. There's pros and cons either way (a big pro is 
compatibility, a big con is I suspect no one has GW-BASIC files laying 
around).


But either way, nice to know it's there. And it should be an 
interesting experiment for someone to get this to assemble using open 
tools.


I wonder if they'll release QuickBasic as open source. That would be 
REALLY interesting!


Overall, it's good to see Microsoft doing this. Especially so because 
of the company president last week saying that he now recognizes 
Microsoft was on the wrong side of history on open source. Seems like 
they really do recognize the importance of open source and are taking 
steps to be more open (they've released other things as open source 
via GitHub that hasn't hit the news)


On Fri, May 22, 2020, 2:42 AM Geraldo Netto > wrote:


Hey Folks!

How are you doing?

Microsoft just open sourced gw-basic
https://devblogs.microsoft.com/commandline/microsoft-open-sources-gw-basic/

the source code on github
https://github.com/microsoft/GW-BASIC

news from phoronix:

https://www.phoronix.com/scan.php?page=news_item=Microsoft-Open-Source-GW-BASIC

from Microsoft dev blog:
"We are excited to announce the open-sourcing of Microsoft
GW-BASIC on GitHub!

Yes, seriously 

Why?

Since re-open-sourcing MS-DOS 1.25 & 2.0 on GitHub last year, we’ve
received numerous requests to also open-source Microsoft BASIC.

Well, here we are! 

The Source

These sources, as clearly stated in the repo’s readme, are the 8088
assembly language sources from 10th Feb 1983, and are being
open-sourced for historical reference and educational purposes. This
means we will not be accepting PRs that modify the source in any way.

A little historical context

The GW-BASIC source code being published is dated Feb 10th 1983. That
was quite a while ago, so just to set a little historical perspective:

The week this source was created Men At Work topped the US and UK
singles charts with “Down Under”, Dustin Hoffman starred in the #1 US
box-office movie, “Tootsie”. In 1983, “Star Wars Episode VI – Return
of the Jedi” was released, as was “War Games”! And, Emily Blunt, Kate
Mara, Jonah Hill, Chris Hemsworth, and Henry Cavill, were born! Ronald
Reagan was President of the USA, and Margaret Thatcher was the UK’s
Prime Minister.

That same year, Bjarne Stroustrup was in the middle of developing the
first version of the C++ programming language, ARPANET standardized
TCP/IP. Borland announced Turbo Pascal, created by Anders Hejlsberg
(who went on to join Microsoft, and create J++, C# and TypeScript).

1983 was also the year AT released UNIX System V R1, and BSD 4.2 was
released, introducing the pseudoterminal for the first time (the
progenitor to Windows’ ConPTY we introduced to Windows in 2018 )

I was 13, and spent every spare second that I wasn’t finishing my
homework or doing my chores, writing BASIC and assembly code on one of
the hottest home computers of the time – the BBC Micro sporting 32KB
RAM (yes, 32,768 bytes, total!), powered by a MOS Technology 6502
processor running at a BLAZING 2MHz. When not coding, I was usually
playing one of the most groundbreaking games of all time: “Elite” by
David Braben & Ian Bell.

In 1983, Apple launched the 1MHz 6502-powered Apple IIe for US$1,395
(> $3,500 in 2020). Apple also launched the first commercially
available computer with a GUI – the Apple Lisa. The Lisa contained a
staggering 1MB RAM, and ran the awesome Motorola 68000 processor at an
astounding 

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Harald Arnesen]

Jim Hall [22.05.2020 14:17]:

> As for GW-BASIC, FreeDOS already includes other BASIC interpreters and
> compilers with equivalent or better functionality, so I don't know that
> we need to add GW-BASIC. I'm not a BASIC programmer, so I'm open to
> suggestion on this. There's pros and cons either way (a big pro is
> compatibility, a big con is I suspect no one has GW-BASIC files laying
> around).

Oh yes, there are tons of old GW-BASIC games and other stuff around.
-- 
Hilsen Harald


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[TK Chia]

Hello Ralf,


But still, nobody should get their knickers in a twist just yet, as it
is an older version of GW-BASIC from 1983, while the latest version
(3.23) is from 1988. And the license kind of disallows to re-use the
code from the files, similar to that of the DOS 1.x/2.0 source they
published last year...


Did I miss something?  The LICENSE file in the GitHub repository
(https://github.com/microsoft/GW-BASIC) says that it is released under
the MIT License.

The *.H files and *U files (GIO86U etc.) contain macros needed by the
*.ASM files, but I have not checked how complete they are.

Thank you!

--
https://github.com/tkchia



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[C. Masloch]

On at 2020-05-22 07:58 -0700, Ralf Quint wrote:
> And the license kind of disallows to re-use the
> code from the files, similar to that of the DOS 1.x/2.0 source they
> published last year...

That's incorrect. Note that in the blog post they're referring to
"re-open-sourcing" the old MS-DOS files. The *original* release was not
FLOSS. However, that "re" open sourcing was under the MIT license. The
same is also used for this GW-BASIC release:

https://github.com/microsoft/GW-BASIC/blob/master/LICENSE

What is more of a problem is that the MS-DOS 2.x sources are missing
most of the IO.SYS (BIO) source, and I also can't find SYS or their boot
sector loaders anywhere. And the COMMAND.COM does not entirely work with
subdirectories yet.

Regards,
ecm


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Ralf Quint]

On 5/22/2020 5:17 AM, Jim Hall wrote:


As for GW-BASIC, FreeDOS already includes other BASIC interpreters and 
compilers with equivalent or better functionality, so I don't know 
that we need to add GW-BASIC. I'm not a BASIC programmer, so I'm open 
to suggestion on this. There's pros and cons either way (a big pro is 
compatibility, a big con is I suspect no one has GW-BASIC files laying 
around).
Well, BW-BASIC (which you are likely eluding to) is more an excuse of a 
BASIC interpreter. And you would be surprised how much of GW-BASIC 
source code is still out there.


But either way, nice to know it's there. And it should be an 
interesting experiment for someone to get this to assemble using open 
tools.
I had started as a pet project of mine a work alike clone of GW-BASIC 
but got stuck with a couple of internals, like the MBF floating point 
format used by the early M# programming languages, so I hope that this 
released code can shed some light on this things that got me stuck so I 
can easier continue on my project. After all it has been released for 
educational purposes... ;-)


But unfortunately, I just recently started to work on a project that is 
a bit of a complement to your "programming in C" videos you put out as 
well have volunteered for a part-time job at a local food bank/soup 
kitchen through the end of June, so I will see how much time I can find 
for this before the lockdown around here really get lifted and real work 
(for a living) starts again...


I wonder if they'll release QuickBasic as open source. That would be 
REALLY interesting!

That might be debatable... ;-)


Overall, it's good to see Microsoft doing this. Especially so because 
of the company president last week saying that he now recognizes 
Microsoft was on the wrong side of history on open source. Seems like 
they really do recognize the importance of open source and are taking 
steps to be more open (they've released other things as open source 
via GitHub that hasn't hit the news)


Don't bet your farm on this. All that they have released so far are 
always the oldest versions of everything (same for DOS and Windows too), 
which have very little practical use, so I see this rather as a teasing 
token than a real change in policy...



Ralf


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Ralf Quint]

On 5/22/2020 5:10 AM, Deposite Pirate wrote:

This cannot be compiled to machine code because it's some kind of meta 
assembler to generate assembler for various processor architectures and this 
meta assembler is apparently not available. So unless someone goes through the 
pain of reverse engineering this meta assembler this is pretty much useless 
shit, just like MS-DOS 1.x and 2.x.

It is plain an d simple Intel/MASM 8086 assembler code, so that is not a 
problem. However, even though I had only a cursory look over it 
yesterday, it seems to be missing some macro files in order to 
recompile/reassemble.


But still, nobody should get their knickers in a twist just yet, as it 
is an older version of GW-BASIC from 1983, while the latest version 
(3.23) is from 1988. And the license kind of disallows to re-use the 
code from the files, similar to that of the DOS 1.x/2.0 source they 
published last year...


Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Louis Santillan]

I think you're wrong dpirate. I haven't had time to test, but, I would
expect [0] to be able to use MASM & LINK from MS-DOS 2.0 [1] to build
this.  I plan to throw some cycles at this.


[0] https://news.ycombinator.com/item?id=23269345
[1] https://github.com/microsoft/MS-DOS/tree/master/v2.0/bin

On Fri, May 22, 2020 at 7:08 AM Andy Stamp  wrote:
>
> It looked like this was the x86 output of the meta compiler.  I'm going to 
> try to coax the Watcom Assembler into building it this evening.
>
> On Fri, May 22, 2020 at 8:38 AM Deposite Pirate  
> wrote:
>>
>> This cannot be compiled to machine code because it's some kind of meta 
>> assembler to generate assembler for various processor architectures and this 
>> meta assembler is apparently not available. So unless someone goes through 
>> the pain of reverse engineering this meta assembler this is pretty much 
>> useless shit, just like MS-DOS 1.x and 2.x.
>>
>>
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
>
> --
> --Andy
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[geneb]

On Fri, 22 May 2020, Deposite Pirate wrote:

This cannot be compiled to machine code because it's some kind of meta 
assembler to generate assembler for various processor architectures and 
this meta assembler is apparently not available. So unless someone goes 
through the pain of reverse engineering this meta assembler this is 
pretty much useless shit, just like MS-DOS 1.x and 2.x.




"These sources, as clearly stated in the repo's readme, are the 8088 
assembly language sources from 10th Feb 1983..."


So yeah...


--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby.  Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Andy Stamp]

It looked like this was the x86 output of the meta compiler.  I'm going to
try to coax the Watcom Assembler into building it this evening.

On Fri, May 22, 2020 at 8:38 AM Deposite Pirate 
wrote:

> This cannot be compiled to machine code because it's some kind of meta
> assembler to generate assembler for various processor architectures and
> this meta assembler is apparently not available. So unless someone goes
> through the pain of reverse engineering this meta assembler this is pretty
> much useless shit, just like MS-DOS 1.x and 2.x.
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>


-- 
--Andy
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Deposite Pirate]

This cannot be compiled to machine code because it's some kind of meta 
assembler to generate assembler for various processor architectures and this 
meta assembler is apparently not available. So unless someone goes through the 
pain of reverse engineering this meta assembler this is pretty much useless 
shit, just like MS-DOS 1.x and 2.x.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Microsoft Open-Sources GW-BASIC

[Jim Hall]

I saw that! Interesting to see Microsoft releasing more stuff as open
source, including more of their DOS catalog. I'd really like to see them
release Word for DOS source code too.

As for GW-BASIC, FreeDOS already includes other BASIC interpreters and
compilers with equivalent or better functionality, so I don't know that we
need to add GW-BASIC. I'm not a BASIC programmer, so I'm open to suggestion
on this. There's pros and cons either way (a big pro is compatibility, a
big con is I suspect no one has GW-BASIC files laying around).

But either way, nice to know it's there. And it should be an interesting
experiment for someone to get this to assemble using open tools.

I wonder if they'll release QuickBasic as open source. That would be REALLY
interesting!

Overall, it's good to see Microsoft doing this. Especially so because of
the company president last week saying that he now recognizes Microsoft was
on the wrong side of history on open source. Seems like they really do
recognize the importance of open source and are taking steps to be more
open (they've released other things as open source via GitHub that hasn't
hit the news)

On Fri, May 22, 2020, 2:42 AM Geraldo Netto  wrote:

> Hey Folks!
>
> How are you doing?
>
> Microsoft just open sourced gw-basic
> https://devblogs.microsoft.com/commandline/microsoft-open-sources-gw-basic/
>
> the source code on github
> https://github.com/microsoft/GW-BASIC
>
> news from phoronix:
>
> https://www.phoronix.com/scan.php?page=news_item=Microsoft-Open-Source-GW-BASIC
>
> from Microsoft dev blog:
> "We are excited to announce the open-sourcing of Microsoft GW-BASIC on
> GitHub!
>
> Yes, seriously 
>
> Why?
>
> Since re-open-sourcing MS-DOS 1.25 & 2.0 on GitHub last year, we’ve
> received numerous requests to also open-source Microsoft BASIC.
>
> Well, here we are! 
>
> The Source
>
> These sources, as clearly stated in the repo’s readme, are the 8088
> assembly language sources from 10th Feb 1983, and are being
> open-sourced for historical reference and educational purposes. This
> means we will not be accepting PRs that modify the source in any way.
>
> A little historical context
>
> The GW-BASIC source code being published is dated Feb 10th 1983. That
> was quite a while ago, so just to set a little historical perspective:
>
> The week this source was created Men At Work topped the US and UK
> singles charts with “Down Under”, Dustin Hoffman starred in the #1 US
> box-office movie, “Tootsie”. In 1983, “Star Wars Episode VI – Return
> of the Jedi” was released, as was “War Games”! And, Emily Blunt, Kate
> Mara, Jonah Hill, Chris Hemsworth, and Henry Cavill, were born! Ronald
> Reagan was President of the USA, and Margaret Thatcher was the UK’s
> Prime Minister.
>
> That same year, Bjarne Stroustrup was in the middle of developing the
> first version of the C++ programming language, ARPANET standardized
> TCP/IP. Borland announced Turbo Pascal, created by Anders Hejlsberg
> (who went on to join Microsoft, and create J++, C# and TypeScript).
>
> 1983 was also the year AT released UNIX System V R1, and BSD 4.2 was
> released, introducing the pseudoterminal for the first time (the
> progenitor to Windows’ ConPTY we introduced to Windows in 2018 )
>
> I was 13, and spent every spare second that I wasn’t finishing my
> homework or doing my chores, writing BASIC and assembly code on one of
> the hottest home computers of the time – the BBC Micro sporting 32KB
> RAM (yes, 32,768 bytes, total!), powered by a MOS Technology 6502
> processor running at a BLAZING 2MHz. When not coding, I was usually
> playing one of the most groundbreaking games of all time: “Elite” by
> David Braben & Ian Bell.
>
> In 1983, Apple launched the 1MHz 6502-powered Apple IIe for US$1,395
> (> $3,500 in 2020). Apple also launched the first commercially
> available computer with a GUI – the Apple Lisa. The Lisa contained a
> staggering 1MB RAM, and ran the awesome Motorola 68000 processor at an
> astounding 5MHz, but it cost $9,995 (> $25,000 in 2020 dollars), so
> all I could do was peer at it through the window of the one computer
> store in our town authorized to sell Apple’s products … and dream.
>
> And, in 1983 Microsoft released MS-DOS 2.0 (source here), and GW-BASIC
> for the IBM PC XT and compatibles.
>
> What IS GW-BASIC?
>
> GW-BASIC was a BASIC interpreter derived from IBM’s Advanced
> BASIC/BASICA, which itself was a port of Microsoft BASIC.
>
> Microsoft’s various BASIC implementations can trace their origins all
> the way back to Bill Gates & Paul Allen’s implementation of
> Microsoft’s first product – a BASIC interpreter for the Altair 8800.
>
> During the late ’70s and 80s, Microsoft’s BASIC was ported to many
> OEM’s specific platform and hardware needs, and for several processors
> popular at that time, including the 8088, 6502, 6809, Z80, and
> others."
>
>
>
> Semper Fidelis,
>
> Geraldo Netto
> Sapere Aude => Non dvcor, dvco
> site: http://exdev.sf.net
> github: