Re: [Freedos-user] New mTCP available
On Fri, Jul 8, 2022, 7:39 PM Michael Brutman wrote: > Just for a little bit ... :) > > Thanks! > That's what I figured. That's why I only hid the mirror, but didn't delete it. :-) Let me know when you're comfortable with it and I'll unhide the mirror directory. Jim ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Assembly Language and BASIC
On 7/8/2022 4:26 PM, Rugxulo wrote:
Turbo Pascal debuted in 1983 with support for CP/M and DOS via .COM
files (max. 64k size). When they dropped CP/M and .COM support in TP 4
(1987), then they were able to use separate "units" and DOS .EXEs for
larger code. (But TP 3 could still address 1 MB with the heap.) There
were other complications, too.
Not quite sure what you are trying to say here.
Anders Hejlsberg deliberately designed Compas Pascal/Poly Pascal (which
was renamed to Turbo Pascal 1.0 on CP/M, then ported from Z80 assembler
to x86 for CP/M-86 and DOS) as a 1-pass compiler, with minimal memory
usage and also forgoing any real linking process, just combining each
and every program with the same, complete run time library and just
adding the actual program code behind that for the rest of the available
memory.
He took the general idea of the UCSD Pascal menu for the new "IDE" (the
predecessor of Compas Pascal, Blue Label Pascal, was just a command line
compiler, but with the same concept of creating the resulting executable
without link, just appending to the standard RTL) but because of the
deliberate decision of the compiling process, there was no ""room" for
including a modular concept.
Once Turbo Pascal reached v3, there was no further room to improvement,
and hence it was decided to re-write the compiler for version 4. At that
point, Hejlsberg made the decision to introduce the unit concept of UCSD
Pascal, and as the goal was to produce native x86 code, dropped the .COM
format and produced .EXE files, which lend themselves nicely to the unit
concept. However, in order to allow for smart-linking, the units would
not be compiled to .obj (which had no provision for the info of the
interface section) but produced proprietary .TPU (Turbo Pascal Unit)
files. That move was also more aided by the speed improvements in PCs
CPUs rather than the available memory.
And as CP/M, in either form, was obsolete and got dumped, using memory
mapped video output became a viable option (the early versions of Turbo
Pascal could actually be used though a serial terminal still!), someone
else at Borland (it wasn't Hejlsberg himself) came up with the full
screen, windowed text UI IDE, which was pretty much unchanged (just
adapted) used for the simultaneously released Turbo C 1.0.
Turbo Pascal 5.0 then (re) introduced overlays, 5.5 first steps in
object oriented programming and an integrated debugger, while 6.0
introduced real inline assembler (instead of inline() with inserting
byte wise opcodes of assembly routines) and a vastly improved debugger.
Byte magazine (issue Dec. 1986) has a comparison of four Pascal
compilers. Modula-2 (with modules) was no stranger as their Aug. 1984
issue covered it extensively. But of those four Pascal compilers (MS,
UCSD, Prospero, MetaWare, with sidenote for TP 3):
64K-byte code/data limit? no, no, no, no, yes
Chaining? no, yes, yes, no, yes
Export abstract data types? no, no, no, yes, no
Modules? yes, no, no, yes, no
External routines? yes, yes, yes, yes, yes
Include files? yes, yes, yes, yes, yes
Overlays? yes, no, yes, yes, yes
Segmentation? no, yes, yes, yes, no
unit libraries? yes, yes, no, no, no
Keep in mind the obvious fact that TP compiles/links in about 2
seconds that which takes about a minute (60 secs.) on most other
compilers. Plus, TP was $70 (while most others, besides $100 UCSD,
were roughly $300, $400, or $600).
As for the speed, see my explanation above. Beside that, there are some
errors in this list. Never used Prospero Pascal, but I did use Metaware
Professional Pascal and UCSD Pascal, beside Turbo Pascal 3.0 (and
Digital Research Pascal MT+ 86, and a little bit of Microsoft Pascal).
Completely false for example is that UCSD would not have modules, as
mentioned before, they are the ones that "invented" the unit concept.
Also, there was a general overlay system common to all p-System
compilers (beside Pascal, there was FORTRAN as well as a rather elusive
BASIC compiler). And without looking at that article, I am not sure
how/why they differentiate between modules and "unit libraries"...
There's a different article (same Dec. 1986 issue) about something
else entirely ("approximating integrals") that has unstructured BASIC
(GWBASIC??) code as an example. It's weird seeing so many competing
languages. There's even an ad for MS QuickBASIC compiler 2.0 bragging
about speed, EGA support, structured constructs (no GOTO required),
and "reusable modules" for $100.
My point is that everything "new" was getting obsoleted by everything
"newer" and then some. Things moved too fast, but progress was
definitely happening.
Well, that "progress" unfortunately might not always for a real world
benefit. A lot of newer programming languages and programming paradigms
do not really help solving real world (end user) problems. And a lot of
"competing" languages was rather a good thing, as it helped to show
which ones provided
Re: [Freedos-user] New mTCP available
Just for a little bit ... :) Thanks! Mike On Fri, Jul 8, 2022, 4:59 PM Jim Hall wrote: > > > > On Fri, Jul 8, 2022 at 6:19 AM Eric Auer wrote: > >> > >> > >> Hi! Forwarding from BTTR: > >> > >> A new mTCP is available (2022-07-01) > >>[..] > > > On Fri, Jul 8, 2022 at 6:33 PM Michael Brutman > wrote: > > > > Hi - yes it is true, a new version is available. > > > > Please hold off on mirroring it at ibiblio for a little bit ... > > I'm trying to gauge how many users I have based on downloads, and that > > falls apart once people start to mirror it. > > > > > I've already mirrored it to Ibiblio earlier today, but I'll take that > down (hide it) and update the news item to not reference the mirror. > > > Jim > > > ___ > 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] New mTCP available
Hi - yes it is true, a new version is available. Please hold off on mirroring it at ibiblio for a little bit ... I'm trying to gauge how many users I have based on downloads, and that falls apart once people start to mirror it. Cheers, Mike On Fri, Jul 8, 2022 at 6:19 AM Eric Auer wrote: > > Hi! Forwarding from BTTR: > > A new mTCP is available (2022-07-01) > > posted by mbbrutman, Washington, USA, 07.07.2022, 00:00 > > Download from: http://www.brutman.com/mTCP/mTCP.html > > Release notes: > http://www.brutman.com/mTCP/mTCP_2022-07-01_Release_Notes.html > > And here is the short version of what you can look forward to: > > - Support for a local HOSTS.TXT file. > - Some minor DHCP bug fixes. > - TCP/IP library improvements for flow control on bad/slow connections. > - HTTP server bug fixes and proper support for default index.html files. > - A slightly more accurate SNTP (simple network time protocol) client. > - Proper Dynamic DNS support for the FTP server > - Other scattered bug fixes and small features. > > As always, yell if you have problems ... > > For the future - I'm working on proper Unicode support for IRCjr and > Telnet. That will come along in a few months. > > > > ___ > 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] Assembly Language and BASIC
Hi,
On Fri, Jul 8, 2022 at 11:37 AM Ralf Quint wrote:
>
> For Pascal, this is +95% wrong. The first widespread version of Pascal,
> UCSD Pascal, also sold for example under names like "Apple Pascal" (on
> Apple II/III) did introduce the concept of "units", which allowed not
> only for modular development, but also for code reuse, as well as basic
> data and code encapsulation, which are all part of the core
> functionality of object oriented programming (before that term and its
> use was totally perverted to today's levels). That was also introduced
> starting with Turbo Pascal 4.0 and is a staple of later Turbo/Borland
> Pascal versions as well Object Pascal implementations like Delphi and
> FreePascal.
> The exception was kind of only the very early versions of Turbo Pascal
> (up to 3.0), which by the overall design of the compiler used "one big
> file" (though you could "include" many different source files). A lot of
> pther compilers, like Digital Research Pascal MT+ 86 or Microsoft Pascal
> allowed for development, compilation and linking of separate modules. As
> far as the various Microsoft compilers of the DOS days are concerned,
> ,while observing a handful of rules, it was even possible to link for
> example FORTRAN, C, Pascal and assembler modules together to one program
> executable. Beside that a lot of compilers allowed for modular
> development and use of such modules via the use of overlays.
The IBM PC debuted in 1981 with PC-DOS and the 1979-era 8088 [sic], a
16-bit cpu addressing 20 bits of RAM (a maximum of 1 MB), but most
computers had much less (for various reasons), e.g. 128 kb. Later,
OS/2 1.x was meant to be a "better DOS" and debuted in 1987 (despite a
RAM shortage). That was still 16-bit (286 pmode, max. 16 MB of RAM)
and mostly Microsoft's work. (32-bit OS/2 2.x came later from IBM in
1992 without MS.) The 386 didn't debut until 1986 or so, and it took a
long time for software to catch up. Actually, the 386 was Compaq (and
Intel) "exclusive" for a while. For example, DJGPP debuted in 1989.
Turbo Pascal debuted in 1983 with support for CP/M and DOS via .COM
files (max. 64k size). When they dropped CP/M and .COM support in TP 4
(1987), then they were able to use separate "units" and DOS .EXEs for
larger code. (But TP 3 could still address 1 MB with the heap.) There
were other complications, too.
Byte magazine (issue Dec. 1986) has a comparison of four Pascal
compilers. Modula-2 (with modules) was no stranger as their Aug. 1984
issue covered it extensively. But of those four Pascal compilers (MS,
UCSD, Prospero, MetaWare, with sidenote for TP 3):
64K-byte code/data limit? no, no, no, no, yes
Chaining? no, yes, yes, no, yes
Export abstract data types? no, no, no, yes, no
Modules? yes, no, no, yes, no
External routines? yes, yes, yes, yes, yes
Include files? yes, yes, yes, yes, yes
Overlays? yes, no, yes, yes, yes
Segmentation? no, yes, yes, yes, no
unit libraries? yes, yes, no, no, no
Keep in mind the obvious fact that TP compiles/links in about 2
seconds that which takes about a minute (60 secs.) on most other
compilers. Plus, TP was $70 (while most others, besides $100 UCSD,
were roughly $300, $400, or $600).
There's a different article (same Dec. 1986 issue) about something
else entirely ("approximating integrals") that has unstructured BASIC
(GWBASIC??) code as an example. It's weird seeing so many competing
languages. There's even an ad for MS QuickBASIC compiler 2.0 bragging
about speed, EGA support, structured constructs (no GOTO required),
and "reusable modules" for $100.
My point is that everything "new" was getting obsoleted by everything
"newer" and then some. Things moved too fast, but progress was
definitely happening.
Relevant links:
* https://archive.org/details/byte-magazine-1984-08/
* https://archive.org/details/byte-magazine-1986-12/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Question about error message
Hi, On Fri, Jul 8, 2022 at 3:11 PM Eric Stein wrote: > > So I get this message when I exit from a certain program: Error reading > from device AUX: write fault. > > Aside from the strangeness of getting a write fault by reading > something, does DOS even still have an AUX device? I think this is a > generic device name like PRN that can be redirected to something else, > but the MODE command doesn't seem to know what it is. AUX is just COM1 (serial), PRN is just LPT1 (parallel). * https://en.wikipedia.org/wiki/DOS#Reserved_device_names * https://en.wikipedia.org/wiki/Device_file#PC_DOS,_TOS,_OS/2,_and_Windows ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS ASM resources
Hello, On Fri, 8 Jul 2022 at 01:28, Rugxulo wrote: > Hi, > > On Thu, Jul 7, 2022 at 5:53 PM Aitor Santamaría > wrote: > > > > On Fri, 8 Jul 2022 at 00:00, Rugxulo wrote: > >> > >> I can send you my local copy (or show you how to get it) of the 3.2.2 > >> cross-compiler (i8086-msdos) that works under latest HX pre-releases. > >> It has a built-in assembler and linker. It supports all memory models. > > > > THe links seem to work, why did you mention to send it? couldn't I > download from that link? > > And what do you mean that works under HX? I don't mind to compile under > Windows11 or Linux if neccessary :) > > The Windows installer isn't DOS friendly. Besides, four target cpus > with six memory models each is VERY bloated (especially because of six > copies of huge "generics.ppu"). My local .7z of "8086 target only" is > thus much, much smaller. > Ahh ok understood! I'll gladly take it. > But yes, it's meant to be a cross-compiler atop modern OSes. (Hey, > since it still works under HX, I'll gladly use that.) > > > But I want it to run in 16-bit (Free)DOS. > > 16-bit host? No luck there. > No no, the assembled files to run under 16-bit :) Aitor ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re (2): Assembly Language and BASIC
Apology for the mis-directed message about land use. ... P. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re (2): Assembly Language and BASIC
P.s. Spoke to M. Sketch around noon today. He mentioned two factors relevant to the GIGARHS project. (1) Obligation to neighbouring landowners to conserve or preserve the natural character. (2) Obligation to not compromise ground water supply of neighbours by exploiting too much or by polluting with sewage. Michael might disagree with my words. I don't know the Trust Policy Statement and bylaws as well as he does. Incidentally, if the picketing materializes you can notify and ask participation of PITPS members with a message to memb...@pitps.org. If you decide to revise the agenda item, send it to me again any time before the meeting. Thx,... P. -- mobile: +1 778 951 5147 VoIP: +1 604 670 0140 48.7693 N 123.3053 W ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Question about error message
Regarding FreeDOS 1.3 release version: So I get this message when I exit from a certain program: Error reading from device AUX: write fault. Aside from the strangeness of getting a write fault by reading something, does DOS even still have an AUX device? I think this is a generic device name like PRN that can be redirected to something else, but the MODE command doesn't seem to know what it is. Also when I start FreeDOS, I get 4 lines of "Can't read parameters from drive 01" after a message that looks like it is adjusting the number of cylinders detected. But the system seems to work fine. Any insights would be appreciated. Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Assembly Language and BASIC
Hi, On Fri, Jul 8, 2022 at 11:37 AM Ralf Quint wrote: > > For Pascal, this is +95% wrong. The first widespread version of Pascal, > UCSD Pascal, also sold for example under names like "Apple Pascal" (on > Apple II/III) did introduce the concept of "units", which allowed not > only for modular development, but also for code reuse, as well as basic > data and code encapsulation, which are all part of the core > functionality of object oriented programming (before that term and its > use was totally perverted to today's levels). That was also introduced > starting with Turbo Pascal 4.0 and is a staple of later Turbo/Borland > Pascal versions as well Object Pascal implementations like Delphi and > FreePascal. The original Pascal was stabilized and "sent off" to standardization in 1977. They didn't add any major features, so it's almost the same as de facto J The standard (ISO 7185) was published in 1982. "Classic" Pascal had no modularity, everything was a single file. (I presume that many people used homegrown preprocessors [e.g. Doug Comer's MAP] like BWK also did in _Software Tools in Pascal_.) Everybody and their brother made Pascal derivatives: Ada, Modula-2, Modula-3, etc. While Dr. Wirth was not directly involved, there was also a newer "Extended" Pascal standard in 1988 (ISO 10206) that also had modules. But even Wirth kept going and started developing Oberon in 1986. "Standard" Modula-2 (N.B. GNU GM2) came in 1996 (ISO 10514). (So it was too many competing languages, honestly.) * https://en.wikipedia.org/wiki/Modular_programming I forget the details, but there's a difference between "separate compilation" and "independent compilation". One is including files (like C) while the other is properly-checked modules. * https://courses.cs.vt.edu/~cs3304/Spring00/notes/Chapter-8/tsld033.htm "Independent compilation is compilation of some of the units of a program separately from the rest of the program, without the benefit of interface information. Separate compilation is compilation of some of the units of a program separately from the rest of the program, using interface information to check the correctness of the interface between the two parts." N.B. It's much slower having to reparse header files over and over again (but many compilers already support precompiled headers). Actually, C++20 added modules! GNU's G++ is close to being fully C++20 compliant (but by default 12.1 is only "gnu++17" by default, I think.) * https://en.cppreference.com/w/cpp/language/modules * https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/C_002b_002b-Modules.html * https://clang.llvm.org/docs/Modules.html * https://docs.microsoft.com/en-us/cpp/cpp/modules-cpp?view=msvc-170 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS ASM resources
On 7/7/2022 2:58 PM, Rugxulo wrote: DeSmet C and IA16-ELF (GCC) both work fairly well (but not necessarily every memory model). * http://desmet-c.com/ DeSmet C has only 2 memory models (small and large, the later from v3.x onwards) and is also using its own object file format and thus linker. (Tough there is an o2obj converter, but that is only intended to link modules written in DeSmet C to other languages/compilers that use the standard .OBJ file format). Ralf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Assembly Language and BASIC
On 7/7/2022 8:54 PM, dmccunney wrote: On Thu, Jul 7, 2022 at 8:30 PM Daniel wrote: I am unfamiliar woththe C languages, but does it also allow one to mix both assembly in with the C source code? Are there any other languages that allows mixing of assembly in with the language code? Not in the manner you are thinking of. A key point here was that programs were modular. There would be more than one C source file making up the completed program, so there wasn't really a need for inline assembler. If performance wasn't what was hoped for, you profiled the C code to see where the problems were, and rewrote the offending C code, or coded it in assembler as needed. Pretty much all actual C compilers I have worked with in the last 40 years supported at least to some degree inline assembler to be used. The ways how to do that were however always implementation dependent and there never was some kind of standard on how to do that... High level language development on DOS in BASIC or Pascal tended to be in one big file, so being able to have Assembler inline was a boon. Also not correct, by a long shot. First of all, BASIC was in most cases an interpreter, so yes, there was most of the time just "one big file", if you disregard things like CHAIN in most MS BASIC derivatives. Pretty much all BASIC compilers (at least on a "real" OS) allowed for separate development, compilation and then linking for those separate modules. The same goes for old style DOS compilers like FORTRAN or COBOL. For Pascal, this is +95% wrong. The first widespread version of Pascal, UCSD Pascal, also sold for example under names like "Apple Pascal" (on Apple II/III) did introduce the concept of "units", which allowed not only for modular development, but also for code reuse, as well as basic data and code encapsulation, which are all part of the core functionality of object oriented programming (before that term and its use was totally perverted to today's levels). That was also introduced starting with Turbo Pascal 4.0 and is a staple of later Turbo/Borland Pascal versions as well Object Pascal implementations like Delphi and FreePascal. The exception was kind of only the very early versions of Turbo Pascal (up to 3.0), which by the overall design of the compiler used "one big file" (though you could "include" many different source files). A lot of pther compilers, like Digital Research Pascal MT+ 86 or Microsoft Pascal allowed for development, compilation and linking of separate modules. As far as the various Microsoft compilers of the DOS days are concerned, ,while observing a handful of rules, it was even possible to link for example FORTRAN, C, Pascal and assembler modules together to one program executable. Beside that a lot of compilers allowed for modular development and use of such modules via the use of overlays. Ralf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New mTCP available
Hi! Forwarding from BTTR: A new mTCP is available (2022-07-01) posted by mbbrutman, Washington, USA, 07.07.2022, 00:00 Download from: http://www.brutman.com/mTCP/mTCP.html Release notes: http://www.brutman.com/mTCP/mTCP_2022-07-01_Release_Notes.html And here is the short version of what you can look forward to: - Support for a local HOSTS.TXT file. - Some minor DHCP bug fixes. - TCP/IP library improvements for flow control on bad/slow connections. - HTTP server bug fixes and proper support for default index.html files. - A slightly more accurate SNTP (simple network time protocol) client. - Proper Dynamic DNS support for the FTP server - Other scattered bug fixes and small features. As always, yell if you have problems ... For the future - I'm working on proper Unicode support for IRCjr and Telnet. That will come along in a few months. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Assembly Language and BASIC
Hello Daniel, I am unfamiliar woththe C languages, but does it also allow one to mix both assembly in with the C source code? Are there any other languages In short, yes, most C compilers allow you to write "in-line" assembly inside a C language source file. However, note that this is not a standardized language feature: different C compilers have different grammars (and semantics) for writing in-line assembly code, so you need to consult the documentation of the specific C compiler(s) you want to use. The GNU C compiler (GCC) in particular has a very powerful inline __asm (...) feature that is designed to play well with the compilers' optimizer. Again, read the documentation. :-) Some C compilers (e.g. the Amsterdam Compiler Kit) do not allow writing assembly code "in-line" as part of a C source file. But even with these, then you can probably still write your assembly language code as a separate module and link it with your C code. Thank you! -- https://gitlab.com/tkchia :: https://codeberg.org/tkchia :: https://github.com/tkchia ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
