Re: [Freedos-user] FDNET missing from FreeDOS 1.3-RC4
> On Mon, Sep 6, 2021 at 10:44 AM Brandon Taylor > wrote: > > > > I've just installed FreeDOS 1.3-RC4 on a virtual machine, and, > > upon running FDIMPLES, discovered that FDNET is nowhere to be > > found. What's the issue here? On Mon, Sep 6, 2021 at 10:58 AM Jim Hall wrote: > > I had asked that we not include FDNET in FreeDOS 1.3 RC4 due to > license confusion in the FDNET package. You can see it documented in > the wiki: > http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages#Networking > > I've been thinking about this since RC4, and I'm starting to think > that the package will be okay to include in RC5. But for now, it's not > in RC4. I've been distracted with other work, and it appears I never followed up on this one. I meant to send this note a month ago. I'd thought a lot about the FDNET issue. Thanks to everyone here for the conversation we've had about it, going back to to June. I especially appreciated the comments from Tom and Eric and Paul. You've convinced me, I agree with you; I now think the license issue for FDNET is actually a non-issue. To recap: Many of the source files have confusing/contradictory license statements. But the sources show that Russ's GPL and public domain claims came first. Most of these are in the PCNTPK directory. For example, many of these files have this disclaimer at the top: ;Copyright (c) 1993 ADVANCED MICRO DEVICES, INC. All Rights Reserved. ;This software is unpblished and contains the trade secrets and ;confidential proprietary information of AMD. Unless otherwise provided ;in the Software Agreement associated herewith, it is licensed in confidence ;"AS IS" and is not to be reproduced in whole or part by any means except ;for backup. Use, duplication, or disclosure by the Government is subject ;to the restrictions in paragraph (b) (3) (B) of the Rights in Technical ;Data and Computer Software clause in DFAR 52.227-7013 (a) (Oct 1988). ;Software owned by Advanced Micro Devices, Inc., 901 Thompson Place, ;Sunnyvale, CA 94088. But the same source files also have this, below the AMD statement: ; Copyright, 1990, Russell Nelson, Crynwr Software ; ; ; This program is free software; you can redistribute it and/or modify ; it under the terms of the GNU General Public License as published by ; the Free Software Foundation, version 1. ; ; This program is distributed in the hope that it will be useful, ; but WITHOUT ANY WARRANTY; without even the implied warranty of ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ; GNU General Public License for more details. ; ; You should have received a copy of the GNU General Public License ; along with this program; if not, write to the Free Software ; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ..or a "public domain" statement like this: ; Copyright 1988-1992 Russell Nelson ; ;put into the public domain by Russell Nelson, nel...@crynwr.com I don't know why the sources later had an "AMD" statement put on them, but you cannot claim "proprietary" or "copyright" on something that was previously released under the GNU General Public License. It appears that somewhere along the line, someone (at AMD?) had access to the sources, probably in a larger source tree, and ran a batch job or script to apply the "AMD" statement to a bunch of source files. And that happened to catch these GPL and public domain source files. I believe that was done in error. The original public domain and GPL declarations trump the latter "AMD" statement. Resolution: (1) Let's re-accept the FDNET package into the next FreeDOS distribution. (2) I'll make a note about this decision in the FreeDOS wiki at http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages (this currently has a red "do not include" note on it .. I'll update to change it a green "include" message) (3) To prevent future confusion, I'll create a new version of these source files that *removes* the "AMD" statement, where a previous GPL or public domain declaration was already made. (I think that's all of the files in question.) I'll also create (or update, if it exists) a README file to note the changes to the source files, and why. I look forward to including networking support again in the next distribution, which should be FreeDOS 1.3 RC5. *If you agree or disagree, I'd appreciate your reply to this email. Agreement can be simply "agree" or "+1". If you disagree, please discuss. (But consensus from the last discussion favored including FDNET, so if no one disagrees now, I'll assume no concerns on this.) Jim ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
On 13/10/2021 21:41, E. Auer wrote: I would not call KSSF experimental, I would just call it rarely used, because most users do have XMS drivers loaded :-) The kswap documentation starts with exactly these words: "This technique is an experimental implementation (...)" Then, the documentation proceeds to list all the limitations of this (clever, but still) hack. Also, to get back to MKEYB: It is tiny both in RAM and on disk and the lack of support for automated codepage magic is perfectly okay for me. Absolutely. That is, in fact, exactly what I was saying earlier. Choice is good, and having a tiny/limited keyboard driver available is definitely cool. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
Hi! While this has nothing to do with MKEYB, Tom is absolutely right about command.com: The more common version of FreeCOM uses XMS to swap, which is faster and available on almost every computer of 2021 FreeDOS fans. But there also is the alternate KSSF style swapping without XMS, which works similar to your description of what MS DOS 3.3 did AND which has been available for years. I would not call KSSF experimental, I would just call it rarely used, because most users do have XMS drivers loaded :-) As you remember, I even suggested that our config / autoexec menu should make sure to load the non-XMS FreeCOM for the boot option "do not load XMS drivers" because that will make a big difference in how much memory is free for apps. For all other boot menu choices WITH XMS, the default FreeCOM with XMS swap of course remains the best choice :-) Also, to get back to MKEYB: It is tiny both in RAM and on disk and the lack of support for automated codepage magic is perfectly okay for me. As said, I could simply write a small batch script to load MKEYB along with the proper font for codepage switches and you can simply unload MKEYB without a reboot, so this even works on the fly. But as mentioned, it is good to have choice, so people are of course welcome to use the full featured FreeDOS KEYB instead of MKEYB for some extra functionality. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
On 13/10/2021 11:49, tom ehlert wrote: I'm 100% certain that MSDOS didn't generate € characters in any codepage. this should end the story of €'s. As explained by others numerous times, the display-talks-to-keyb mechanism is much wider than the one euro symbol. 1'st: 'problems' is the plural of problem. 1 person running a single museum 256K computer and insisting on using a 21'st century OS is still just 1 problem. I must admit that referring to FreeDOS as a "21st century OS" is a hilarious joke. Well played, sir. 2'nd: your machine is perfectly fine with the software that it came with: MSDOS 1.0 or maybe 2.x MSDOS 3.3, to be precise. And yes, it works very well with MSDOS 3.3 and all newest versions as well. Following your line of thought, nobody should install FreeDOS, because it did not came with their machine originally. 3'd: use the non-XMS-SWAP version of FreeCOM. it does exist, and is supposed to swap to/from disk (I never tried). case dismissed. This is an experimental and very limited feature. The xms-swap kludge is a workaround, not an improvement. One could say that FreeDOS' kswap is to MSDOS swapping what mkeyb is to a proper keyboard driver. I am not complaining of course - I am only demonstrating how subjective "real issues" can be. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
Hallo Herr Mateusz Viste, am Mittwoch, 13. Oktober 2021 um 09:15 schrieben Sie: > On 12/10/2021 22:49, E. Auer wrote: >> So at the risk of repeating the obvious: While it is possible to >> construct some problems to justify your desired powerful solution, >> this feels extremely over-designed from my view as Non-US DOS user. > As far as I understand, this is not about designing some new solution to > a possibly rare situation. This is about mimicking what MS did already > 40 years ago... Isn't that the primary objective of FreeDOS? I'm 100% certain that MSDOS didn't generate € characters in any codepage. this should end the story of €'s. >> If you want to address a REAL problem in FreeDOS > Now, about "real" problems: it's highly subjective. You may find the > 2GB-limit thing to be a problem - I don't. I'd say that if there's is > one problem with FreeDOS to pick up, it is COMMAND.COM's memory > footprint: it is *huge*. On my current setup, COMMAND.COM takes up 76K > of RAM. That's 30% of the total memory on this machine... MS-DOS has the > ability to swap out COMMAND.COM at runtime, so it takes roughly 5K (as > per MEM/C output). 1'st: 'problems' is the plural of problem. 1 person running a single museum 256K computer and insisting on using a 21'st century OS is still just 1 problem. 2'nd: your machine is perfectly fine with the software that it came with: MSDOS 1.0 or maybe 2.x 3'd: use the non-XMS-SWAP version of FreeCOM. it does exist, and is supposed to swap to/from disk (I never tried). case dismissed. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
On 12/10/2021 22:49, E. Auer wrote: So at the risk of repeating the obvious: While it is possible to construct some problems to justify your desired powerful solution, this feels extremely over-designed from my view as Non-US DOS user. As far as I understand, this is not about designing some new solution to a possibly rare situation. This is about mimicking what MS did already 40 years ago... Isn't that the primary objective of FreeDOS? If you want to address a REAL problem in FreeDOS I do not think that anyone wants to address any problems in this discussion. The whole thing started merely as an explanation why MKEYB is not a fit replacement for FD-KEYB. While it may be a nice, tiny tool that covers 90+% of cases, it simply lacks more advanced features (dynamic codepage-mapping logic). And that's fine, choice is good. Now, about "real" problems: it's highly subjective. You may find the 2GB-limit thing to be a problem - I don't. I'd say that if there's is one problem with FreeDOS to pick up, it is COMMAND.COM's memory footprint: it is *huge*. On my current setup, COMMAND.COM takes up 76K of RAM. That's 30% of the total memory on this machine... MS-DOS has the ability to swap out COMMAND.COM at runtime, so it takes roughly 5K (as per MEM/C output). Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
