Re: [Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doi ng stuff with MS-DOS 4.01
> VERY unlikely as "race conditions" require multitasking which they don't. > Btw, "race conditions" usually don't fail reliably, but rather like 10% random > chance of failure. Not necessarily. "Race conditions" can really apply anywhere there are multiple things going on at the same time even if the OS itself is not technically "multitasking" (things like hardware interrupts, USB, SCSI, SMM, background serial communications, networking, buffering/caching, CPU mode-switching, memory management, ...). Those things all apply to DOS just like "more sophisticated" environments and can really screw things up if not handled appropriately. There are a LOT of things a computer does in the background that are not directly related to applications. Exactly how and when a problem crops up may or may not be highly predictable. As you said, it's hard to speculate on exactly what's happening, but I wouldn't discount a possible race (or timing synchronization) problem. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] past and present of sideways scrolling and 3d mice
Interesting. Thanks for the research, Eric. As far as mice and wheels, CTMOUSE is the only driver I know of that allows DOS programs to use the wheel. This is emulated in DOSBox, but the second wheel is simply processed as keystrokes because the second wheel is not even an option with the CTMOUSE protocol. The CTMOUSE wheel-extension protocol is really only designed for one wheel and really didn't even leave room for the possibility of a second wheel. It would be possible to add support for a second wheel (and more buttons), but it would be very klunky compared to a well-designed API that included the possibility of multiple wheels and buttons. The Cyberman is interesting - I hadn't seen that one before. Even the INT 33h extensions included for it in the driver you mentioned don't show up in RBIL, so they must not have been very well known. I certainly didn't know about them. The problem we're getting into is that the Cyberman is really a joystick instead of a mouse and should probably be using INT 15.84 extensions instead of INT 33h extensions. But it also has force feedback which can't be done through a game port (game ports only allow inputs, not outputs). All I can say is the Cyberman is a VERY unique implementation that is not compatible with anything else. It wasn't the only unusual/unique implementation of mice and/or joysticks, though -- almost everybody did it back in the day (including Microsoft). Anyway, one of the things I've been interested in with my USB drivers (particularly the joystick Driver, USBJSTIK) is adding support for force feedback. Several USB joysticks have it, but unfortunately I've never seen a widely-accepted DOS API for controlling the force feedback mechanism of joysticks. The Cyberman has an API that works exclusively with the Cyberman product, and I think the Gravis GRIP protocol also allowed for force feedback (but I'm not 100% sure), and there may be a few other hardware/vendor-specific implementations. Does anybody know of a good "generic" API that could be used for force feedback? ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop
> The versions 0.9.4 - 0.9.8 of 8088_bios [1] seem to be affected by a > bug I described in an GitHub issue [2]. It causes DS:0041 to be > overwritten by the BIOS. Problem is, that DS points to whatever it > is set when entering the BIOS and not to the BIOS data area. The bug > is that the BIOS fails to set DS if it encounteres an unsupported > function request. It sets DS correctly for supported functions. This is a pretty basic thing that a BIOS should never do -- "assume" something about what a segment register is. It makes me wonder how many similar issues might still be in that BIOS? > In the case of Free FDISK, this behaviour trashes INT 10 vector. > This is because FDISK uses the intr() function of the Watcom libc, > and setting the segment values (DS, ES) of the REGPACK structure to > zero before invoking intr(). This is recommended by the Watcom > documentation to prevent loading of garbage segment selectors if > running in protected mode [4]. That doesn't quite make sense, since 0 is just as much of a "garbage" segment as any other random selector, and a value of 0 is almost guaranteed to affect data in the IVT and/or BIOS and/or DOS kernel. I think the recommendation is there more to cause the user to stop and think about what DS & ES need to be when calling RM code (and not necessarily just an ISR). In this particular case, no matter what value you put in DS it would have been a problem, though the fact that it was 0 probably made it easier to find (more reproducible) since it was almost guaranteed to be catastrophic. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Question about edlin
That solves the problem with commas, but it looks like you may still have
issues if there are quotes in the file.
I know one thing I've done in the past with some of my programs is allow the
use of either a double-quote ("), single-quote ('), or grave-quote (`) as
string demarkers, which allows strings to contain any two of the three
quote-types and still be able to identify them properly. Of course, it will
still fail if a string contains all three quote types, but that is a rare
situation.
EDLIN's solution (at least for MS-DOS 7.1) solves all potential problems with
Ctrl-Z since Ctrl-Z (end-of-file) should never appear in the middle of the
kinds of files (plain text) that EDLIN works with.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Question about edlin
> I'm using the "r" (replace) instruction correctly: 1rfrom,to will > start at line 1 and replace "from" with "to". > > But it looks like a leading space is ignored, so edlin treats my > "1rwritten, written" as just "1rwritten,written" and seems to ignore > it because the "from" and "to" strings are the same. > > FYI: I can add a space in the middle of a replaced word, such as: > > *1rtext,te xt > 1: This is a plain te xt file,written in edlin. > > Is "ignore leading spaces after the comma in the 'r' command" the > expected behavior from MS-DOS edlin? I haven't used EDLIN in a LONG time (decades), but just did an experiment with MS-DOS 7.1 EDLIN. Your problem doesn't seem to be unrecognized spaces, it seems to be that you're not using any sort of "escape" character to separate your input and output strings. I believe you think the comma should be the "escape" character and it isn't. There's a similar issue with programs like SED and AWK/GAWK. When I'm in EDLIN (at least the one with comes with MD-SOD 7.1) and I type "?" to get help, the syntax for the Replace command looks like this: Replace [startline][,endline][?]R[oldtest][CTRL+Znewtest] It expects you to use a Ctrl-Z (end-of-file character) as the "escape" character. If I use the Ctrl-Z "trick" I can replace things like you're wanting to do. I do not remember if earlier versions of EDLIN did this or not, nor do I know how FD-EDLIN works. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDISK does not respect DLASortByDriveNo config of the kernel
The thing I would do to speak against it is that because none of the other DOS versions, including older versions of FreeDOS, will be able to use it. I do know different versions of DOS do the ordering of the drive letters differently. I think the best thing to do is try to automate it as much as you can by comparing data from things like the DPB, but even that is not always going to be 100% successful. I know this is the FreeDOS version of FDISK, but I wouldn't make it specifically dependent on some specific feature of the FreeDOS kernel. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Question about USBDOS license
> I would have another question regarding USBDOS' license: what about > manufacturers that sell computers with FreeDOS preinstalled to avoid > the Windows tax? For instance in the Middle-East, many local > manufacturers do that, and even big names like HP because the > Windows license fee isn't negligible in local currencies and > licenses like GNU GPL allow it. > Can they include USBDOS? Yes, that would be OK. They are essentially selling the hardware and throwing in FreeDOS for no charge (what they are actually doing is far more complicated than that, but close enough). The "test" I had for compatibility with the license would be if the software could be distributed from my web site (I won't actually do it, but I'm pretty sure FreeDOS wouldn't have a problem with it if I did). It's kind of similar to what would happen if somebody manufactured a USB device of some sort and wrote a DOS driver compatible with USBDOS for the USB device (which I don't think any hardware manufacturer will ever do). As long as they distributed the driver and documentation freely and provided the source code to whoever wanted it, the fact that you are paying for the hardware does not necessarily mean you are paying for the software. It does get a little convoluted, though, since some of the costs built into the hardware are the costs associated with software development and testing and maintenance, but that is different than distribution and use of the software. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Question about USBDOS license
> Hi Bret, > > > [..] >>> I see the point with item 5. However, the mention of a "..directly >>> from a web site that charges a 'registration fee'.." seems (to me) to >>> be specific to sites that charge a mandatory fee to access files. >> >> That is correct. Voluntary donations to a website owner are fine, as long as >> they really are voluntary. E.g., a site that gives special privileges to >> Patreon donors would be a violation, even if the USBDOS files were not >> "behind" the Patreon firewall since that would be an indirect charge for >> maintaining the website. > >> [..] >>> So, looking closely at item "5" in the license, I think it's okay to >>> keep hosting this on the FreeDOS Files Archive at Ibiblio, and keep a >>> copy on GitLab. >> >> That's fine. > > Ok, now I'm confused. So am I. There is a lot of gray in this discussion and very little black and white. There is a HUGE discussion we can have about Software Copyrights and what's right and wrong with them from a philosophical or moral or historical perspective. That's why I framed my Copyright in a discussion about intent instead of "letter of the law". See below to see why it's not as clear-cut as it should be, and somebody could convince me to change my mind about something. > You say that keeping a copy on ibiblio and GitLab is fine. That is great. :-) > > But earlier in your reply You mention that if a site provides some features > only to paying members, that site cannot provide USBDOS. Even when that site > provides USBDOS to non-paying members and not even membership is required to > download USBDOS. > > I fail to see how GitLab can qualify to provide a copy for download. GitLab > has > many features that are only available to paying members. > > Please explain how this is okay, but a feature provided to a Patreon donator > is > not. To me, it seems to be a contradiction. I think we can divide software into three different aspects: writing/compiling the program, publishing/distributing the program, and using the program. Only the last one, actually using the program, is the one I think should be done without restriction. E.g., if you use the USBDOS keyboard driver to type into the computer, whatever you use what you typed for is irrelevant (whether it's another useful program, a book that you intend to sell, a book you intend to give away for free, or an Internet virus intended to destroy the world). What GitLab is intended to be used for is collaborative software development, not distribution of final software (although you can use it for that). When you pay for things on GitLab, you are paying for extra space on their servers to help you collaborate on bigger projects, not necessarily for other programs. As another level of confusion, if you use the FreeDOS web site to download a program, and lot of them are simply links to ibiblio. I don't use either GitLab or ibiblio, but I don't see a "pay side" of ibiblio (maybe there is one, but it's not obvious -- certainly not as obvious as GitLab). But, for the sake of argument, let's assume there was a "pay-side" to ibiblio and the FreeDOS files were stored there. FreeDOS is paying for the GitLab service, but from my perspective I'm getting them for free (at least if I go through the FreeDOS website). In my mind, this would be somewhat similar to the Patreon analogy -- FreeDOS is voluntarily paying for the GitLab service but is not asking me to contribute anything if I don't want. This would be similar to what I do for my website (bretjohnson.us), where I pay voluntarily for a provider to host the web site but don't require payment from the users/visitors. They can voluntarily contribute if they want, but nothing is required. > Thanks > > :-) > > Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Question about USBDOS license
This Bret, the author of USBDOS (and a few other programs also. I've added a
few comments below to Jim's comments, but basically Jim is right on target.
People have made comments about how this is a non-standard license and would
like to see me incorporate a widely-published one (and there are a lot of
them). Of the ones I've seen, the one that comes closest to my perspective is
the Reciprocal Public License (RPL), even though it's not considered valid by
the Free Software Foundation (FSF). In future releases of programs I may use
RPL instead of my "custom" license, but I haven't decided for sure yet.
Let me summarize why I disagree with the FSF with a relatively pithy statement.
"Freedom" to the FSF means you can do pretty much anything you want with
someone else's stuff that they gave you for free, including the freedom to make
money from it. My definition of freedom is that you can do pretty much
anything you want with the stuff you got for free EXCEPT make money -- free
means perpetually and totally free in every sense. You can leverage the free
stuff to make money ("You can use the programs without restriction"), but you
can't make money from the programs.
Bret
> Someone else asked me about the USBDOS license. This person
> highlighted a note in the USBDOS license that suggested "if your
> website collects money, then you can't distribute USBDOS" - and the
> person asked about the Patreon link on the www.freedos.org website.
>
> So I thought I'd share my reply here, and see if anyone else had
> thoughts on this. Overall: I don't think the Patreon link is an issue
> for the USBDOS license. Let me know if you disagree.
>
> I don't know if Bret still subscribes to the freedos-devel list, but
> maybe he is and can answer more definitely. :-)
>
>
> I downloaded a copy of the USBDOS files from https://bretjohnson.us/
> and evaluated that. In USBINTRO.DOC, I found the "COPYRIGHTED
> FREEWARE" section which said this: (entire copy)
>
>> The accompanying programs are authored by Bret Johnson with suggestions,
>> programming, documentation, and testing help from Richard Bonner
>> (http://www.chebucto.ns.ca/~ak621).
>>
>> This section contains the license for all of the enclosed programs. I'm
>> not going to inject a bunch of legal language in here that a smart
>> lawyer can find a loophole in. I'm writing down the intent of how I
>> want the programs to be distributed and used in my own words, and hope
>> that the intent is clear, no matter how the literal words can be twisted
>> to mean different things (remember when President Bill Clinton, a
>> lawyer, claimed he didn't understand the meaning of "is" during the
>> Lewinsky hearings?).
>>
>> All of these programs, as well as their documentation and source code,
>> are freely available to anyone who wants them. You can use the programs
>> without restriction, but you cannot directly or indirectly use the
>> executable programs, documentation, or source code to create or
>> distribute new programs that are not also freely available. You also
>> cannot distribute the programs, documentation, or source code and charge
>> (even indirectly) for their distribution. You can charge someone enough
>> to cover your actual, direct costs for distribution (disks, shipping
>> materials, postage, etc.), but cannot charge for "handling". This also
>> means that you cannot distribute the programs, documentation, or source
>> code directly from a web site that charges a "registration fee" in an
>> attempt to make a profit or to recover direct or indirect costs for
>> maintaining the web site.
>>
>> If you distribute related or derivative programs, you must use
>> essentially the same license. You must provide and distribute the
>> programs and documentation for free, and you must include the
>> documentation with the program. You must give credit where it is due,
>> and must make the source code freely available to anyone who wants it.
>>
>>
>> Perhaps a good test of whether your program is adhering to the license
>> or not would be if you are willing to let me post the program,
>> documentation, and source code on my web site, to be downloaded by
>> anyone who wants it. In fact, if you create any new related or
>> ancillary DOS USB programs, I would like the opportunity to distribute
>> them from my web site. I won't guarantee that I will necessarily do it,
>> but would like the opportunity. Distribution from my web site
>> (http://bretjohnson.us) is not required by the license.
>
> I see several terms in this license: (some of these are reworded,
> numbers added by me for reference)
>
> (1) All of these programs, as well as their documentation
> and source code, are freely available to anyone who
> wants them.
>
> (2) You can use the programs without restriction, with
> this exception: you cannot directly or indirectly use
> the executable programs, documentation, or source code
> to create or distribute new programs that are not also
> freel
Re: [Freedos-devel] i have a tech question about 286 and XMS
FWIW, Microsoft's HIMEM.SYS is compatible with 286 CPUs (and also with 386+). There's also an EMM286.EXE floating around that provides EMS for 286-class CPUs, but I don't think MS had anything to do with it. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] CD-ROMs was ANSI for DOS
> The first one I can remember was the Mitsumi CRMC-LU005S single speed > drive, which was the one I had. It had its own card because it was > non-IDE despite the fact that the cable and plug looked exactly like > IDE. They did use a proprietary standard. They definitely worked on an > 80286, so I think we can conclude that CDROMs did not require an > 80386. I can remember some early Shareware CD's with stuff I couldn't > use because I only had a 80286. DJGPP springs to mind. The very first CD players that came out for computers were proprietary and required hardware-specific drivers. Later on there were standards like ATAPI. That's at least part of the reason MS divided the CD software into two separate pieces -- the hardware-specific driver (there are tons of those) and MSCDEX and its clones. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
> Yeah, USB and CD/DVD makes only sense for a 386+ ... USB, yes. CD/DVD, no. USB requires PCI which in turn requires 386+. Actually, there were supposedly USB host controllers manufactured for the ISA bus instead of PCI, but I've never actually seen one. But USB protocols assume you're using a 32-bit (and in some cases 64-bit) CPU so USB really only makes sense on 386+, though you could probably make things work on a lesser CPU if you absolutely had to. But CD drivers existed back in the early days and they never required anything special of the CPU. They would sometimes take advantage of special features if they were available, but it wasn't required. AFAIK, there are no DOS DVD drivers anyway since I don't think anything has ever supported UDF. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] set device info
> So (unless I stuffed the test up), it's not just me that says > that stdin isn't stdin - Freedos get device info returns 0. > So freedos reports that stdin is not stdin, and I took its > word for it in my test of set device info. I just tested FreeDOS 1.2 and 1.3 and a couple of other versions of MS-DOS and issuing a Get Device Info (INT 21.4400) for STDIN (BX=0) returns attributes of 80D3h in DX, not 0. I also know that if STDIN is redirected that attributes returned will be those of the device that STDIN is redirected to, but I don't know if you're doing anything like that. In at least some of my programs I actually use INT 21.4400 on the STDOUT device to see if the output of my program has been redirected, and if so I know the output is not going to the screen (and is probably going to a file or to NUL or to PAUSE or something like that). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Interesting behavior with PC Tools
Those extra "spaces" may not really be spaces at all -- they may actually be ASCII 0 or ASCII 255, which look like a regular space (ASCII 32) on the screen even though they aren't. I've ran into similar issues at various times that have caused me all kinds of grief. There are also some DOS Code Pages where other characters (besides 0, 32, and 255) also are blank (they look like a normal space when they aren't). I've even tried to take advantage of this fact in the past when trying to make directories and files formatted for easier reading or keeping users from easily entering a directory I didn't want them to be in for some reason. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] set device info
> mov ah, 044h > mov al, 01h > mov bx, 0 > ;mov dx, 081h > mov dx, 0h > int 021h > mov ah, 04ch > int 021h Looking at this again, I think I see what your problem might be. You have commented out the "mov dx, 081h" which makes me think you are trying to do something with a hard drive (which is normally accessed through various BIOS INT 13h functions) instead of a DOS handle (which is normally accessed with various DOS INT 21h functions). DOS handles and BIOS disk numbers are VERY different things, and I think you are trying to conflate the two. BTW, this also brings up the importance of commenting your code. If you had done that we could have maybe seen what you were TRYING to do and made it easier for us to help you. Without comments, all we know is that what you seem to be trying to do makes no sense at all. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] set device info
Tom is absolutely correct. You are trying to change the attributes of Device 0 (STDIN) to 0 (so that is it is not really even a device any more). After that, for all practical purposes, you have disabled the computer. Apparently, FreeDOS doesn't see this as a problem (it assumes you know what you are doing) but other DOS versions know this will cause problems and automatically reject your request. I personally can't think of a good reason to ever want to change a devices attributes, but there may be some special case I can't see right now. But I can see no reason to ever change the attributes of any standard device (STDIN, STDOUT, STDERR, etc.). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
I've used GEM, GEOS, and DOSShell all in the past and they all have quirks and issues that make them all less than ideal for my use. DOSShell is a really good idea (it supposedly used the same task-switching mechanism that was in Windows 3.x), but I found it very clunky to use. It does work pretty well, though. GEM has some useful applications, but it's very limited and also a little clunky. I think the best of the bunch is GEOS, but even back when it was a commercial application it wasn't all that stable (but it was probably at least as stable as Windows). My first experience with GEOS was back in the early days of the Internet when everybody used dial-up modems. Back then there were really only three viable ISP's with a national presence: America Online, Prodigy, and Compuserve. I thought AOL was the best at the time and used it for a long time and AOL was a GEOS application. As others have noted, I'm not sure how useful a GUI "front end" for DOS really is, but of the ones I've seen I think GEOS has the most potential. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
