Re: [Freedos-devel] Back at it with DOG
Welcome back! :D My setup is a Linux desktop machine under which I edit code with Sublime Text and compile with the Linux versions of NASM and/or Watcom C, for whichever the current project calls. I test frequently while implementing a new feature or what-have-you, and for that I use DOSBox. My more periodic, more "release" based testing is done in a pair of virtual machines - one in VirtualBox and the other in AQEMU, though you can read that as plain QEMU, as it's simply a GUI front end to ease configuring the emulator's numerous options. Happy coding! :) Mercury Sent with [Proton Mail](https://proton.me/) secure email. On Wednesday, May 29th, 2024 at 9:21 PM, Wolf Bergenheim via Freedos-devel wrote: > Hi everyone, > > After ~22 years I got back into coding on DOG. I'm working my way towards a > new release, 0.8.4b, in the ~soon timeframe. I'm also working on moving the > source code to GitHub and fixing the website. It had apparently broken > several years ago... > > So far I've been fixing the code and implementing missing bits. It's a lot of > fun, and I really enjoy that the coding is so different from my day job > coding. :) Earlier this year I found Jim's great YT channel, and I think that > was a big part of me picking up DOG again, so thanks for that! > > Now a question: > What are your dev setups like? I'm on a linux host computer and I've been > using both DOSBox and QEMU to build and test in. I find though that it's a > bit of a chore, since DOSBox crashes randomly (like when compiling), or QEMU > segfaults when I mount my dog source directory as a virtual FAT drive. So now > I'm looking at setting up Dosemu2 (I remember using doemu ~20 years ago). > > What do your dev environments look like? How do you make an efficient > edit-build-test cycle? Has anyone tried using watcom as a crosscompiler? > > --Wolf > > -- > > |\_ > | .\---. > / ,__/ > / /Wolf <[wolf+...@bergenheim.net](mailto:wolf%2b...@bergenheim.net)> Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Where is the source code?
Thanks for that! I'm always on the lookout for new retro-adjacent channels, so I'll definitely be checking out Root42 in the near future. Sent with Proton Mail secure email. On Wednesday, May 8th, 2024 at 12:53 PM, Danilo Pecher via Freedos-devel wrote: > Probably the best DOS programming channel is root42: > https://www.youtube.com/@root42 > > He also has other retro computing stuff going on, but he does an good > lot of videos on DOS programming as well. > > Cheers, Hippo > > On Wed, 8 May 2024 at 17:57, Jim Hall via Freedos-devel > freedos-devel@lists.sourceforge.net wrote: > > > On Wed, May 8, 2024 at 10:28 AM Bernd Böckmann via Freedos-devel > > freedos-devel@lists.sourceforge.net wrote: > > > > > > I like that idea. I think a good place to add these would be in the > > > > "Technical information" section on that page, maybe as another row of > > > > "info boxes" before (or after? not sure) the row that has RBIL, VGA > > > > programming, and the Graphics Programming book. > > > > > > I would put it below Technical Information as another row. > > > > Sounds good! I'll probably use this as a comment right before it: > > "Looking to get started in DOS programming? These YouTube videos show > > you how to write your first programs:" > > > > > > What are some good YouTube channels about DOS programming that I > > > > should point to? > > > > > > I like the following playlist. He uses Turbo C, PowerBasic, NASM. While > > > he does it on DosBox, the skills are transferable. Be aware: heavy german > > > accent :) > > > > > > https://www.youtube.com/playlist?list=PLGJnX2KGgaw2L7Uv5NThlL48G9y4rJx1X > > > > Thanks for that! I'll be sure to include that one. > > > > Anyone else have other recommendations? > > > > ___ > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FETCH4FD
Exactly. I, too, never heard of it until maybe a month ago - I always used INXI for that on my machines lol Sent with Proton Mail secure email. On Thursday, March 21st, 2024 at 9:32 PM, Jerome Shidel via Freedos-devel wrote: > Hi > > > On Mar 19, 2024, at 6:33 PM, Ladislav Lacina via Freedos-devel > > freedos-devel@lists.sourceforge.net wrote: > > > > Hello! > > I write own port of utility NeoFetch known from UNIXes. > > [..] > > > Never used NeoFetch. > > What is it for? > > Looking at the screenshot and features you listed, my guess is it reports > some general system information. > > Like RAM, CPU and Drives. > > :-) > > Jerome > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS wiki updates + questions
Personally, I'm a big fan of keeping information in one easy to access place. If it were me, I would put the articles in their own section on the wiki under a helpful title, where they could also be linked to from other articles in the wiki, e.g. an article on how to install FreeDOS could link to How-Tos detailing how one would partition and format their drive. I'm no SEO expert by far, but I would think that the fact that the articles are not simply copy-pasted but are also linked to from other pages on the site - not to mention that there is a ton of other content on the wiki, making it more than a simple copy-paste ripoff of the source site - would mitigate the down-ranking which Google et al. may otherwise do. Sent with Proton Mail secure email. On Wednesday, March 20th, 2024 at 10:09 AM, Jim Hall via Freedos-devel wrote: > I've been moving the FreeDOS wiki content over by copy/paste. And I've > finished almost all of the tricky pages .. then it's a collection of > small pages (mostly usage pages for programs) which I think should go > quickly. Then I'll add wiki editor accounts for anyone who wants them. > > The new wiki will be here: > https://wiki.freedos.org/w/index.php?title=Main_Page > > (don't bookmark that yet .. the "w" part in the URL will likely go away) > > > Question: > > What to do about the "Networking How-to"? This is a collection of > pages that wasn't written as a typical "wiki" page (every page in a > wiki should stand on its own, with links to other pages for more info) > but as a series of pages that follow step 1, step 2, .. etc. > > Should I just copy/paste those pages into the new wiki, or move them > out into a new kind of "how-to" article? > > We have another collection of pages for an "Installation Guide" and I > have the same question there. > > > Related: > > I (and others) wrote a bunch of articles about FreeDOS for > Opensource.com before they stopped publishing (about a year ago). > Opensource.com is still up, and I'd like to copy/paste the FreeDOS > articles into a website that we control in case Opensource.com goes > away. At least the articles I wrote, and I can ask permission of other > authors if I have their contact info. > > Again, these aren't written to be "wiki" pages, they are standalone > articles about how to do something in FreeDOS (like how to use CD and > DIR, other useful commands, conio programming, .. etc) in 800 to 1000 > words. > https://opensource.com/tags/freedos > > Should I just copy/paste those into the new wiki, or should I create a > new website to republish these, like a howto.freedos.org website .. or > maybe a "howto" directory on the new wiki website (but outside the > "wiki" itself) like wiki.freedos.org/howto .. or a "howto" directory > on the main website, like www.freedos.org/howto .. what's the best > plan? Since Google's "SEO" ranking generally "down-ranks" websites > that copy/paste content from other websites, creating a new website > name like howto.freedos.org seems like a good idea, but I don't want > to create a bunch of work for myself if others have a better idea > > > Jim > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: lspci (pciutils) for freedos
Good to know that (Free)DOS has lspci support. Thanks for the info! And now, for my two cents lol My ListPCI application (https://mercurycoding.com/downloads.html) does essentially the same thing, although it shows only the manufacturer and device type, not the specific device name; e.g. "Intel Corporation IDE Mass Storage Controller" and not "Intel Corporation 82371AB/EB/MB PIIX4 IDE". This has proven to be good enough for my purposes (and hopefully other users' as well!) and results in a much smaller binary - 52.2 kB versus lspci's 191.5 kB. Sent with [Proton Mail](https://proton.me/) secure email. On Saturday, March 9th, 2024 at 8:14 AM, Bernd Böckmann via Freedos-devel wrote: > Hi Pali, > > I will forward your message regarding lspci to the FreeDOS mailinglist. > Thanks for sharing this information! > > Greetings, Bernd > >> Anfang der weitergeleiteten Nachricht: >> >> Von: Pali Rohár >> Betreff: lspci (pciutils) for freedos >> >> Datum: 9. März 2024 um 12:49:53 MEZ >> An: Bernd Boeckmann >> >> Hello, >> >> I read the freedos wiki page contribute >> https://freedos.sourceforge.io/wiki/index.php/Contribute >> >> and I would like to let you know that the "lspci" tool known from the >> linux which lists and prints information about all PCI devices connected >> in the system, works also on freedos and the last version now has >> pre-compiled binaries in the pciutils project page. They are in windows >> download section, but are compiled with DJGPP toolchain. >> http://mj.ucw.cz/sw/pciutils/ >> >> I saw more questions from users if there is a lspci-like tool for >> freedos to list PCI devices, so I think that the original lspci can be >> useful for freedos. Would you consider including it into distribution CD? >> Note that pciutils library is used by flashrom which is already present. >> >> Pali___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Website has moved to new hosting
Nice, the new site is working for me. :) One (minor) thing I would suggest, however, is that the What's New items should each at the bottom span the entire width of the window in all cases. The do behave this way on small screens (or in small windows) but on large ones they show up side-by-side. In my mind, they have better logical flow when there's a single item per line. Sent with [Proton Mail](https://proton.me/) secure email. On Wednesday, March 6th, 2024 at 10:37 AM, Jim Hall via Freedos-devel freedos-devel@lists.sourceforge.net wrote: > FYI that the www.freedos.org website has moved to new hosting. It's > still at the same website hosting company, but on a new server. (This > was the web hosting company doing a planned replacement of the old > hardware.) Things look like they have moved over okay, I don't see any > issues. > > They are keeping the old web server running for a while, to respond to > any requests on the old server (for example, with the old hostname in > your DNS cache). I've posted the announcement about the upcoming > get-together on both servers. > > If you're curious if you're accessing the new server or the old one, I > added this temporary file on the new server. It tells you if you are > using the new server or the old one: > https://www.freedos.org/new.txt > > If you can see the contents of that file, you're using the new web > server. If you get a "404" error, then you are using the old web > server (try again in a few days). > > Jim > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Merry Christmas to everyone
Thank you, and a Merry Christmas to you and your family! Sent with [Proton Mail](https://proton.me/) secure email. On Sunday, December 24th, 2023 at 11:16 PM, Jim Hall via Freedos-devel wrote: > I just wanted to wish everyone a Merry Christmas, to all who celebrate! > > Also looking forward to 2024!___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Phishing attack - warning!
...as did I. Mine was as follows. From: webmas...@propstei-marien.de Subject: Re: [Freedos-devel] Logger v0.3-BETA Content: Hi There, Please look into the the document in the web-link down the page. LINK BUTTON Enjoy a good afternoon! Where "LINK BUTTON" links to a page in the https://bone-shed.net/ domain. It seems it was sent as a reply to a message I posted to the mailing list myself, which is likely how it's getting past the spam filters of my email provider. Sent with [Proton Mail](https://proton.me/) secure email. On Thursday, November 2nd, 2023 at 7:27 AM, Steve Nickolas via Freedos-devel freedos-devel@lists.sourceforge.net wrote: > On Thu, 2 Nov 2023, Harald Arnesen via Freedos-devel wrote: > >> Jim Hall via Freedos-devel [02/11/2023 11.12]: >> >>> So now phishers are pretending to be FreeDOS emails. That's pretty >>> targeted phishing (aka "spear phishing" where attackers customize the >>> email to be very specific to the recipient). >>> >>> Thanks for sharing. I haven't seen this, but I'll watch for it now. >>> >>> On Thu, Nov 2, 2023, 4:39 AM Wilhelm Spiegl via Freedos-devel >>> >> mailto:freedos-devel@lists.sourceforge.net> wrote: >>> >>> Hi all, >>> I only wanted to tell you that I had a "FreeDOS" phishing attack >>> yesterday. >> >> I got one as well. Same subject and link. > > I got one from an Argentinian address - figured it was a hack rather than > a phish, but with the same idea. > > -uso.___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updating/moving the wiki
On Saturday, August 26th, 2023 at 12:37 PM, Jim Hall via Freedos-devel freedos-devel@lists.sourceforge.net wrote: > ... > > But I'm concerned about walking into another situation down the road where we > need to relocate the wiki once again. When we used the shared wiki at SF, > that was a good idea at the time .. until they stopped offering it. Could the > same happen with a GitLab-hosted wiki? > > ... As I always say, "A task outsourced is a vulnerability opened." :) >___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Happy 29th anniversary to FreeDOS!
Looks great! Except I was referring to [this logo](https://freedos.org/images/logos/freedos-logo2-lg.png), not the Seinfeld-esque one. :) Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Sunday, July 2nd, 2023 at 4:15 PM, Jim Hall via Freedos-devel freedos-devel@lists.sourceforge.net wrote: >> On 6/29/2023 4:24 PM, Jim Hall via Freedos-devel wrote: >> >>> I've been experimenting with an updated website, and I'm considering >>> going back to the original 1990s logo. We can use Blinky elsewhere on >>> the website, but maybe a "throwback" logo would be cool? > > On Sun, Jul 2, 2023 at 2:07 PM Ralf Quint via Freedos-devel > freedos-devel@lists.sourceforge.net wrote: > >> Well, as I have never been a fan of that cross-eyed pregnant guppy, I >> would say go got it... >:) > > I admit I thought of you when I was experimenting with the new design > mock-up. :-) > > An experimental version of the new design is at > https://test.freedos.org/ but it's (very incomplete (most links > don't go anywhere, "Lorem Ipsum" placeholder text, etc). > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Happy 29th anniversary to FreeDOS!
+1 And lol, btw. :) Sent with Proton Mail secure email. --- Original Message --- On Sunday, July 2nd, 2023 at 3:07 PM, Ralf Quint via Freedos-devel wrote: > On 6/29/2023 4:24 PM, Jim Hall via Freedos-devel wrote: > > > I've been experimenting with an updated website, and I'm considering > > going back to the original 1990s logo. We can use Blinky elsewhere on > > the website, but maybe a "throwback" logo would be cool? > > Well, as I have never been a fan of that cross-eyed pregnant guppy, I > would say go got it... >:) > > > Ralf > > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Happy 29th anniversary to FreeDOS!
--- Original Message --- On Thursday, June 29th, 2023 at 7:24 PM, Jim Hall via Freedos-devel freedos-devel@lists.sourceforge.net wrote: > ... > > I've been experimenting with an updated website, and I'm considering > going back to the original 1990s logo. We can use Blinky elsewhere on > the website, but maybe a "throwback" logo would be cool? > > Jim > > ... Yes! I was about to suggest that before I even read this part of your email, but yeah... [that 90s logo](https://freedos.org/images/logos/freedos-logo2-lg.png) not only looks cool but really embodies the DOS era as a whole. It definitely gets my vote. Not that we're voting. But you get what I mean. :D___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] EXIST NUL
On Tuesday, June 13th, 2023 at 4:30 PM, Jose Senna jasse...@mail.com wrote: > ... > > Jim Hall said: > >> We should still fix the FreeDOS behavior to match > >> the MS-DOS behavior. > > Shall this be an absolute rule, even when the > behavior is a bug ? Unfortunately, in many cases, it has to be an absolute rule. I totally get the mindset (and semi-subscribe to it myself)of wanting FreeDOS to be a kind of MS-DOS but improved in every way possible including fixing Microsoft's bugs, but realistically that cannot be in all cases since some legacy software out there may very well be relying on a specific behavior present in MS-DOS and us fixing that bug - even when normally be the right thing to do - may break compatibility in those cases. >___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS & LOGGER
Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Friday, June 9th, 2023 at 1:48 PM, jer...@shidel.net wrote: > Hi All, > > Logger version 1.00 was released several weeks ago. That should have been > sufficient time those who are interested in it to have a chance to try it > out. I feel it is now time to pose a few questions and get your opinions on a > couple things. > > - Should a package for LOGGER be included on the FreeDOS release media? Yes. > - If so, should LOGGER be installed with FULL or BASE? Or, possibly just > available as an EXTRA? (However, I assume it should not automatically be > started on an installed system. Possibly, having a REM’ed line in the > FDCONFIG.SYS file.) Both. It's small (and useful!) enough to warrant the extra tiny bit of space used. > - Should LOGGER be included and possibly started automatically when booting > the FreeDOS USB or CD release media? I could see developers opting to install it while most "average" users would likely forgo this, so I would say no to auto-start. Or, even better, let the installer leave the choice up to the user. > - If so, I assume integrating logging into the FreeDOS installer would be > desired. See above :) > Once again, there is a boot floppy that can be used with either the FreeDOS > 1.3 Live CD or any of the interim builds. That boot floppy brings up a Live > Environment that has LOGGER running. The example floppy can be retrieved from > https://fd.lod.bz/redist/system/ > > Jerome___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Logger v0.3-BETA
Nice work! Sent with Proton Mail secure email. --- Original Message --- On Friday, May 12th, 2023 at 3:52 PM, jer...@shidel.net wrote: > Hi All, > > With all the changes I made since v0.2-BETA, I decided to do another beta > release of Logger. Here is an overview of the changes: > > * Addition of an API function (and demo program) for reading the log. > * Removal of fairly useless “JAM” mode (Stop when full support). > * Dropped mostly useless ANSI output support. > * Removed VERSION command, just displayed with INFO now. > * Lots of improvements to HTML log output. > * Some general improvements to shave a few bytes. > > Package download - https://fd.lod.bz/repos/current/pkg-html/logger.html > Demo Boot - https://fd.lod.bz/redist/system/ > > I’m going to go through and remove some “dead” code. Since the API provides > support for everything needed to interact with the log, I’m going to make > some changes to the interface portion to utilize that functionality. Most of > which is straight forward and easily testable. There may or may not be an > additional beta before the 1.0 release. > > :-) > > Jerome > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I wish I had a boot.log file
Right, same basic idea. I guess the main difference is using the spare video memory as a starting buffer, but regular ol' RAM would be fine too. :) Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Monday, March 20th, 2023 at 7:23 PM, jer...@shidel.net wrote: > Hi, > >> On Mar 20, 2023, at 6:35 PM, Mercury Thirteen via Freedos-devel >> wrote: >> >> I realize this may be more trouble than it's worth, but it's technically >> possible to write up a small "shim" program which simply hooks the character >> printing interrupts and copies any characters passed to a small memory >> buffer* before forwarding them to the regular printing interrupt. This shim >> would need to be named COMMAND.COM so that it is loaded first after the >> kernel, and once this hook is established the shim would then pass control >> on to the real COMMAND.COM. >> >> * As I recall, the basic text mode offers multiple - what is it, eight? - >> pages of text, and this extra video memory could possibly be used as amemory >> buffer to avoid cutting into the available memory which applications could >> otherwise use. Once an XMS driver is loaded, the contents could be copied to >> an XMS block, freeing up the video memory for use by applications who >> actually use it for its intended purpose. >> >> Ok, all done. Now you're all free to shoot that idea full of holes! haha > > Same basic Idea as what I was saying. :-) > > Although, I’d do it as a device driver that you could load first, then switch > from temp storage to XMS when the memory drivers have been loaded. Finally, > after the boot process is complete, you could turn off logging or switch to > StdErr only logging. But, most programs don’t use that device and just output > errors to StdOut. > > Anyhow, the driver method would also capture messages by other device drivers > before the command shell is even loaded. > > It is not actually very difficult to do. But, like everything, it still would > take at least some time to make and test. > > Maybe I’ll whip one up if I get bored or just want to work on something other > than my current project for a little while. > > :-) > > Jerome > >> Sent with [Proton Mail](https://proton.me/) secure email. >> >> --- Original Message --- >> On Monday, March 20th, 2023 at 9:45 AM, jer...@shidel.net >> wrote: >> >>> Hi Paul, >>> >>>> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel >>>> wrote: >>>> >>>> So many messages on boot I cannot scroll back. >>>> If only the boot process would also copy everything in a boot.log file! >>> >>> At present, that is not really practical. Actually for a lot of the boot >>> processes on the LiveCD, not currently even possible. >>> >>> When the LiveCD boots, the system is an unknown state. During the startup, >>> it needs to figure out a lot of different things. There is no known >>> location it could write any such messages that could be later viewed. >>> During the early stages of the boot process, it is simply not reliably >>> possible at present. >>> >>> As things progress and it works out some stuff, it “could” write such a log >>> to the a hard drive if present. But being a LiveCD, that would be a very >>> bad idea and counter to user expectations. It should not modify the >>> contents of any drive unless explicitly told to do so. >>> >>> Therefore, it tries to bring up a RAM drive for the purpose of having >>> temporary storage for things like I/O redirection and extracting software >>> packages. By this point, a “boot.Log” would be of little use, would >>> complicate the process and possibly eat up precious RAM disk space. >>> >>> All that being said, it would be possible to create fairly simple device >>> driver that could trap and log all displayed text to XMS memory (when >>> present). But, I’m very busy on other things for the moment. >>> >>> Maybe after I finish the next stage of my current project, I’ll whip one up. >>> >>> Jerome >>> >>>> ___ >>>> Freedos-devel mailing list >>>> Freedos-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel >> >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I wish I had a boot.log file
I realize this may be more trouble than it's worth, but it's technically possible to write up a small "shim" program which simply hooks the character printing interrupts and copies any characters passed to a small memory buffer* before forwarding them to the regular printing interrupt. This shim would need to be named COMMAND.COM so that it is loaded first after the kernel, and once this hook is established the shim would then pass control on to the real COMMAND.COM. * As I recall, the basic text mode offers multiple - what is it, eight? - pages of text, and this extra video memory could possibly be used as amemory buffer to avoid cutting into the available memory which applications could otherwise use. Once an XMS driver is loaded, the contents could be copied to an XMS block, freeing up the video memory for use by applications who actually use it for its intended purpose. Ok, all done. Now you're all free to shoot that idea full of holes! haha Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Monday, March 20th, 2023 at 9:45 AM, jer...@shidel.net wrote: > Hi Paul, > >> On Mar 19, 2023, at 11:29 AM, Paul Dufresne via Freedos-devel >> wrote: >> >> So many messages on boot I cannot scroll back. >> If only the boot process would also copy everything in a boot.log file! > > At present, that is not really practical. Actually for a lot of the boot > processes on the LiveCD, not currently even possible. > > When the LiveCD boots, the system is an unknown state. During the startup, it > needs to figure out a lot of different things. There is no known location it > could write any such messages that could be later viewed. During the early > stages of the boot process, it is simply not reliably possible at present. > > As things progress and it works out some stuff, it “could” write such a log > to the a hard drive if present. But being a LiveCD, that would be a very bad > idea and counter to user expectations. It should not modify the contents of > any drive unless explicitly told to do so. > > Therefore, it tries to bring up a RAM drive for the purpose of having > temporary storage for things like I/O redirection and extracting software > packages. By this point, a “boot.Log” would be of little use, would > complicate the process and possibly eat up precious RAM disk space. > > All that being said, it would be possible to create fairly simple device > driver that could trap and log all displayed text to XMS memory (when > present). But, I’m very busy on other things for the moment. > > Maybe after I finish the next stage of my current project, I’ll whip one up. > > Jerome > >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I wish I had a boot.log file
It would be nice if FreeDOS had something like *nix's DMESG. Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Sunday, March 19th, 2023 at 11:29 AM, Paul Dufresne via Freedos-devel wrote: > So many messages on boot I cannot scroll back. > If only the boot process would also copy everything in a boot.log file!___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
If it was in fact removed from the "official" MS-DOS, and one wanted to (re)implement it anyway, perhaps browsing the code of the open-source recreation of OS/2 would help? It has a FAT32 driver which is compatible with the OS/2 IFS and, as I recall, OS/2 was more of a direct successor to MS-DOS than Windows ever was, so perhaps its code would be more helpful to a DOS dev as opposed to the Windows versions. Not sure, I haven't dug too deeply into that myself, but hope it possibly helps. https://www.arcanoae.com/wiki/fat32/ Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Monday, February 20th, 2023 at 2:58 PM, Aitor Santamaría wrote: > Thanks, Ralf!! > > So I thought, but I have read a couple of references (such as the following > in Wikipedia, but not the only one) by which the IFS was present in MS-DOS > 4.X, of course as well as in OS/2 and Windows: > > [Installable File System - > Wikipedia](https://en.wikipedia.org/wiki/Installable_File_System) > > Apparently, there was some support for it that was probably removed for > MS-DOS 5.0 and later. Part of the mystery (to me) of MS-DOS 4.X! :) > > In RBIL, the only reference I've found is to IFSHLP.SYS, which was a Windows > mean to guess what has been installed before getting into protected mode, so > I am not sure is if this has to be with the IFS that was planned and > implemented in MS-DOS 4.0. > > Aitor > > On Mon, 20 Feb 2023 at 18:27, Ralf Quint wrote: > >> On 2/19/2023 5:38 PM, Aitor Santamaría wrote: >>> Hello, >>> >>> Does anyone know if the IFS (Installable File System) API is >>> documented anywhere? >>> >> Just checked in my archive of docs, and there is a MSCDEX.TXT, which >> describes the interface for the CD-ROM "network redirector". >> >> It can apparently be found online at https://cybermax.tripod.com/mscdex.txt >> >> Ralf >> >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Where to start and continue?
Actually, someone has already done some work on that. :) Check this out: https://www.codeproject.com/Articles/894522/The-Low-Level-M3ss-DOS-Multicore-Mode-Interface Sent with Proton Mail secure email. --- Original Message --- On Sunday, January 15th, 2023 at 9:17 AM, Knedlik wrote: > Okay, I’m still even a few days after very confused. I came into DOS with my > only programming knowledge being on modern 64-bit systems and I didn’t even > go lower-level than C++. > I have no idea where to start - I would love to learn how to do all the cool > stuff like graphics and then extending the base stuff with more bits (a bit > theoretical, but would a 64-bit extender be possible?) and a GUI desktop, but > where do I learn this stuff? What should I learn as a prerequisite? > -Knedlik > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Linking asm with C
Watcom's Debugger is amazing for that. You can single-step your code, set breakpoints, monitor variable names, everything. It'll even work (albeit a little less robustly) on applications not made in Watcom C. Sent with Proton Mail secure email. --- Original Message --- On Friday, January 13th, 2023 at 10:22 AM, Knedlik wrote: > I think I’ll stick to inline assembly. > Now onto solving my divide by zero problem which I managed to create somehow. > Help there would be appreciated as well, even if getting a bit off topic. > Mainly knowledge on how to debug on dos will be appreciated. > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Since what you need to know is which Ethernet card is being virtualized, perhaps it would be sufficient to simply scan the PCI bus to see what class 2 devices reside there? My ListPCI tool can do just that (as well as some other stuff) and I believe Eric Auer's PCISleep may do something similar, albeit without the "specificness" my tool offers as far as only listing certain devices for which you are looking. Of course, if the majority of cards for which you need to search are non-PCI (e.g. some old ISA stuff) then this wouldn't be suitable at all, but if not... hey, maybe it could help? It weighs in at a mere 53 KiB, but maybe this is beyond what you wish to spend, space-wise. Feel free to read a little more about it [here](https://mercurycoding.com/blog.html?tag=ListPCI). Hope this helps! :) Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Tuesday, October 25th, 2022 at 11:24 PM, Bret Johnson bretj...@juno.com wrote: >> Jerome's V8Power Tools will detect some VMs, IIRC: > > Yes, I checked that out. In the version I looked at, it detects 3 different > VMs all using the same method (looking for a specific identification string > in BIOS memory). That method works with some VMs, but not all. > >> Although I never truly needed to know what VM > > Sometimes I do. I have my machine set up for lots of different kinds of > testing. I have several VMs installed and several different manufacturers and > versions of DOS that can be used in them. Some VMs just virtualize the > hardware and the BIOS and let you install whatever DOS (or Windows or ...) > you want. Others have a virtual DOS already built into them (sometimes based > on FreeDOS and sometimes something unique). > > One of the main things that started me down this rabbit trail was the need to > know which Ethernet card is being virtualized in a particular VM so I can > load the correct packet driver. I have a single ETHERNET.BAT file I run to > install the packet driver, and since detecting which network card is > installed is a tricky proposition I do it indirectly by detecting the VM (or > lack of VM if I'm running on real hardware). > >> the naive ways to detect (from my limited experience) are >> a). check DOS version > > Can work in some VMs, but mostly not. > >> b). check VESA version string >> c). check BIOS string. > > Those are essentially the same method. If VESA is supported in the VM (some > do and some don't), the VESA version string is also in BIOS (usually in > segment C000h or C800h). The "BIOS string" I think you're referring to is > usually somewhere in segment F000h. Again, this only works with some VMs. > >> (You could also check the cpu, but that's messy. DOSBox is a "fast >> 486" DX2 by default, IIRC.) > > Some VMs (like PCem and 86Box) will virtualize different kinds of CPU's, so > detecting the CPU is not a good method. Also, most VMs will simply "pass > through" the host's CPU and report it as their own instead of accurately > identifying the virtualized CPU. Some VMs report the CPU accurately, but most > don't. > >>> DOSBox >> >> "Only for games". (Maxes out at 64 MB RAM, meh. "Slow Pentium" is >> best it can emulate, IIRC.) > > No, it can run "real" applications also. But you're correct that its primary > focus is compatibility with games. > >>> DOSBox-X >> >> It's quite interesting (esp. running atop FreeDOS itself). But I >> haven't tested it too heavily. > > Similar in many respects to DOSBox. > >> DOSEmu / DOSEmu2 >> >> Is this available in any repos? I'm very naive. Didn't the original >> used to be in "multiverse"? I'm not sure it's there anymore. > > Not sure about DOSEmu, but I just downloaded and installed DOSEmu2 in the > last few weeks in Ubuntu 22.04 (and my Ubuntu is running under Hyper-V in > Windows 10). > >> I still haven't tried DOSEMU2 yet, but it uses its own modified FDPP >> (DOS) kernel, right? > > It does. I'm not sure exactly what's different between the DOSEmu "FreeDOS" > and real FreeDOS, though. > >> Hyper-V >> >> So Hyper-V does actually support DOS? > > It does. You just need to make sure you tell it you're installing a > Generation 1 VM (which includes a BIOS so you can virtualize DOS and older > versions of Windows). > > I also have Ubuntu installed under Hyper-V in Windows 10 and VMs (currently, > DOSEmu2 and KVM) installed in Ubuntu. I did need to do some manipulation in > Windows to allow hypervisor capabilities to pass through Hyper-V so that > Ubuntu could support VMs inside it (virtualization-inside-virtualization). > >>> JPC >> >> The Java one?? > > Yes. I needed to install the Java Runtime Engine in Windows to get this to > work. > >>> KVM >> >> This is just QEMU using VT-X, right? > > I'm not sure exactly how it works. I do know that the "official" name now is > QEMU/KVM, so they are interlinked at some level. I also know the Red Hat is > somehow involved in the mix, but am unsure of the details. >
Re: [Freedos-devel] Editing the FreeDOS 28th Anniversary Ebook
I did some editing and sent you a merge request. [/headsup] Sent with Proton Mail secure email. --- Original Message --- On Monday, August 22nd, 2022 at 7:16 PM, Jim Hall wrote: > I wanted to share an update on the ebook. Editing is going a little > slower than expected, because the other volunteer editors were not > available. So I'm editing the ebook on my own. If anyone has technical > editing experience and wants to help, let me know. > > I have finished a rough first draft of the ebook. This is a copy/paste > of all the interview responses, and assembled into the ebook by > question, where each interview question effectively starts a new > "chapter." This should be a good way to organize the ebook. I'll write > some additional commentary for each question to set a context. In > "draft 2," I may also write some additional text to "weave" the > responses into more of a story. But for "draft 1," this is a good > start. > > The ebook project is here: > https://gitlab.com/freedosproject/freedos28 > > You can find the "draft 1" ODT and PDF here: > https://gitlab.com/freedosproject/freedos28/-/tree/main/draft1 > > You can find additional editing notes on page 2 in the PDF, describing > planned edits for "draft 2." For example, the table of contents will > get updated (it currently shows author names, the updated TOC will > likely include just the interview questions as "chapter" titles). > > I AM LOOKING FOR COMMUNITY REVIEW AND FEEDBACK. Do you see any obvious > errors? (I only did light editing in this draft. I'll do closer > editing in draft 2 - but don't assume I'll spot errors, let me know if > you see any problems.) For this round of editing and feedback, please > focus on text, not formatting. > > If you have a GitLab account, feel free to enter issues in the > project's issue tracker. Or you can email me with any fixes or edits > (please use the email subject "Edits for FreeDOS-28 book" so I can > keep them organized in my inbox, and so they don't get lost). > > ** If you responded to the interview, check that your text is correct. > > ** If you responded to the interview but don't see your responses in > the draft, I didn't mean to ignore you. Your interview probably got > lost in my inbox. Email your interview response to me again and I'll > include it in "draft 2." > > > Next step: late August to early September - second draft > > Goal to publish final version: mid September > > > > On Mon, Jul 25, 2022 at 1:45 PM Jim Hall jh...@freedos.org wrote: > > > Hi everyone > > > > I wanted to share an update on the FreeDOS 28th Anniversary Ebook. You > > may remember this is the book of interviews with FreeDOS developers > > and users. > > > > I've started a GitLab project for the ebook. You can find it here: > > https://gitlab.com/freedosproject/freedos28/ > > > > I've uploaded plain text copies of the interviews I've received so > > far. If you are interested in participating in the ebook, and > > ESPECIALLY IF YOU ALREADY RESPONDED TO THE INTERVIEW, please take a > > look at the project. If you responded to the interview, but you don't > > see your interview listed, THAT MEANS I DON'T HAVE A COPY OF YOUR > > INTERVIEW (I may have missed it in my Inbox, or it was caught by a > > spam filter, etc.) If your interview isn't there, LET ME KNOW so I can > > get your interview response added. > > > > If you want to contribute to the ebook, but haven't responded to the > > interview, this is your last opportunity to do so. You can find the > > list of questions in the GitLab project. > > > > I originally planned to have other technical editors help me with the > > editing process, but that didn't work out due to timing. So I will do > > the editing myself, with input from the community! I'll plan to edit > > everything in the open on GitLab. > > > > The first phase was to get everyone's raw interview responses into > > GitLab. The next phase is to organize the responses into a structure > > or format. I'll do those edits in LibreOffice, which is how I'll > > publish the ebook. Drafts will get posted as ODT and PDF files. > > > > The updated (expected) schedule is: > > > > July to early August - edit > > early to mid August - first draft > > community review opportunity > > mid to late August - second draft > > community review opportunity > > late August - final (published) > > > > Jim > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Toy CPU simulator
Cool! Reminds me of Professor Kelly's EASy68K simulator for 68K CPUs. Sent with Proton Mail secure email. --- Original Message --- On Tuesday, August 9th, 2022 at 7:49 PM, Jim Hall wrote: > Hi everyone > > Some of you know that I also teach a "100" level university course > about technology. This year, I decided I wanted to show off a simple > computer, to demonstrate how a CPU works. I was looking for something > simple and "old school" like an Altair 8800, where you enter > instructions and can watch it execute, and see the accumulator update. > But I couldn't find a hardware kit on sale in the price range I was > looking for. > > So I wrote a simple CPU emulator to use in class. I call it the "Toy CPU." > > I intentionally kept this as a very simple implementation. My goals > were to make it easy to write and easy to understand. > > The Toy CPU implements 256 bytes of program memory, and an > accumulator. You program the Toy using binary opcodes. When you run a > program, the Toy CPU starts at zero for the first instruction. This is > a Minimal Instruction Set Computer with a limited set of instructions > (similar to a CPU from the 1960s or 1970s) but it can do enough real > work that I can use it in class to explain how computers work. > > Version 1.0 is a working (but incomplete) prototype that runs on DOS > (compile with OpenWatcom). Emphasis on prototype - I wrote this in > an afternoon without a design. > > I rewrote most of it to create Version 2.0. This currently runs on > Linux under ncurses, but I plan to port it back to DOS. This version > also supports entering a program using the "front panel" using > "switches and lights" similar to the 8800. > > If you're curious, you can find it here: > > https://github.com/freedosproject/toycpu > > MIT license > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Unstable - interim development builds
In addition to "unstable", another practice commonly used by other software projects for interim builds like those you're discussing here is to title them based on their frequency, e.g. "nightly" or "weekly", etc. Perhaps this would be the way to go? Sent with Proton Mail secure email. --- Original Message --- On Sunday, July 17th, 2022 at 7:00 PM, Jim Hall wrote: > > > On Jun 22, 2022, at 1:05 PM, Jim Hall jh...@freedos.org wrote: > > > > > > I like the idea of the interim development builds. This should be a > > > great way to test new changes that everyone can experiment with! > > > Thanks for doing this. > > > > > > I'm thinking about how people will (mis)interpret the "FreeDOS > > > Unstable" name. I wonder if "FreeDOS Test" might be a better name for > > > this. > > On Wed, Jun 22, 2022 at 1:22 PM Jerome Shidel jer...@shidel.net wrote: > > > I don’t think “Unstable" would cause much confusion. I think it > > is a well understood and established term for such releases. Many > > users are familiar with it from the Linux world. However, it is not > > a big deal to switch it from using the “Unstable” to “Test” > > or “Devel”. Maybe it’s a good question to put to your usability > > class. > > > The usability course is in the Spring semester, so that's a long time. :-) > > But in my experience, I think "test" or "devel" is a better label than > "unstable." While "unstable" may be a term well known by other > developers, remember that ordinary users will find it, and will get > confused by "unstable." > > > > The benefit of "Test" is that it is short enough to combine with > > > the "year+month" label and stay conveniently within an "8.3" filename, > > > so you have "TEST2207" and "TEST2208" and so on. (I know "8.3" names > > > aren't necessary for the web server, but it's a nice symmetry for > > > FreeDOS.) > > > > Actually, not quite… For example, each of the media get’s it’s > > own volume label to help differentiate them. For example, with 1.3 the > > CD boot floppy was “FD13-BOOT” but the image to boot directly from > > the LegacyCD is “FD13-LBFI”. So for all of those, they get labeled > > things like U2206-BOOT and U2206-LBFI. > > > I guess the 8.3 filename doesn't matter as much to me, that was just a > suggestion because "test" was conveniently short. But I'll add that we > probably don't need to worry about 8.3 filenames for the download zip > file. "FD13-LiveCD.zip" and "FD13-BonusCD.zip" from FreeDOS 1.3 didn't > use 8.3 filenames for the download. So the interim build download > files could have longer names that are more descriptive. > > I'm not sure what "LBFI" stands for, though. I'm bad at remembering > acronyms. (I live by the old 1990s joke, "PCMCIA stands for People > Can't Memorize Computer Industry Acronyms.") > > > > Also: I'd prefer to keep the repository for this separate from the > > > FreeDOS official 1.3, 1.2, and and 1.1 distributions. If we put the > > > interim development builds in the same "repositories" path as the > > > official distributions, I think people could easily be confused about > > > the status of the interim development builds. I think a better > > > location is under the ".../distributions/unofficial" parent location: > > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/ > > > > I’m not sure about the “unofficial” label. It suggests it is > > not an official version of FreeDOS and is akin to a 3rd party fork of > > the OS. > > > Good point on "unofficial." And that would allow me to delete the > "unofficial" directory tree (which is empty anyway). > > I'm okay keeping it in the > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ > directory on Ibiblio, if the name is clear. Something like > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/devel/ > or > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ > would be okay, for example. > > > > The path for the "FreeDOS Test" interim development builds would be: > > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/ > > > > I was thinking go just > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable > > and only keeping the latest one around. > > > How about "latest plus 1 previous" instead? I take your other point > (below) that the builds could be quite large, so it's probably not a > good idea to keep every single build. > > But I'm thinking about the use case where someone reports a bug on the > interim test build, and a day later we put out a new interim test > build (which may or may not have fixed the bug on its own .. or maybe > the "bug" wasn't really a bug, but something else) and now we can't go > back to compare what happened in the version that the bug was reported > against, to make sure the bug is really fixed in the current version. > Keeping "latest plus 1 previous" seems like a good solution without >
Re: [Freedos-devel] The 386MAX source code has been released :)
It's been awhile since I've needed to use Git at the command line so I can't
tell you the exact syntax to use but, once you have Git installed, you can run
the command from within your project's root directory and it will upload
everything on its own, maintaining the same folder and file structure you have
in the root folder. Personally, I use the excellent GitKraken front-end, which
makes this even easier.
Sent with Proton Mail secure email.
--- Original Message ---
On Saturday, July 2nd, 2022 at 5:09 PM, Bob Smith
wrote:
> On 7/2/2022 4:05 PM, Jim Hall wrote:
> [...]
>
> > > On Sat, Jul 2, 2022 at 1:07 PM Bob Smith bsm...@sudleyplace.com wrote:
> > > As it took a long long time to upload these files, I'm hoping you all
> > > know of a quicker way to make mass changes. Perhaps there is a GUI
> > > interface for this. As I'd like to stay out of the maintenance of this
> > > project, I'd be happy to give some of you write access to the repository
> > > in order to accomplish the above changes.
> >
> > My desktop system is Linux, so I can suggest the "Linux way" to do
> > this. You can change any instance of "All rights reserved" to "GNU
> > General Public License version 3" in all files in a directory called
> > "386max" by starting with this 3-line shell script: (save this as
> > changetext.bash)
> >
> > #!/bin/bash
> > cp "$1" /tmp/tempfile
> > sed -e 's/All rights reserved/GNU General Public License version 3/g'
> > /tmp/tempfile > "$1"
> >
> > ..and then you run this command:
> >
> > $ find 386max -type f -name '*.INC' -exec bash changetext.bash {} \;
> >
> > What that does:
> >
> > The "changetext.bash" script is just a quick way to batch up two
> > commands: make a copy of the file (I used quotes so variable expansion
> > would preserve spaces) then use sed to change the text from the copy,
> > and overwrite the original file. (The "#!" line is technically not
> > needed here, because the "find" command calls it with "bash" anyway.)
> >
> > The "find" command starts at the "386max" directory, and for every
> > *.INC file that it finds, it executes the command "bash
> > changetext.bash {}" where "{}" gets replaced by the filename. You will
> > need to re-run this for any plain text file (like TXT or DOC or SRC or
> > ..) that has the string you want to change.
> >
> > After you run each "find" command, you can check what other files have
> > the string with this command:
> >
> > $ find 386max -type f -exec fgrep -q 'All rights reserved' {} \; -print
>
>
> My problem is not with making the changes, it's with uploading the
> changed files. Unfamiliar with Github as I am, the only way I saw to
> upload files is through their "Add file/Upload files" method. This
> limits me to 100 files and some small number of MBs per upload.
>
> This project has 580+ dirs, 4800+ files, and 200+ MB of data.
>
> Trying to upload an entire directory failed many times for one of the
> above reasons, so I had to split the directory into several (sometimes
> many) pieces. I don't care to experience that pain again.
>
> If you know of some trick to speed up the upload process, I'll be glad
> to give you the appropriate permissions to do it.
>
> --
> ___
> Bob Smith - bsm...@sudleyplace.com
> http://www.sudleyplace.com - http://www.nars2000.org
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Update on website usability test
I had some spare time, so I took some liberties with Paul's text. Hopefully I didn't slice-n-dice it too badly from your original intent! :) FreeDOS is a free re-implementation of Microsoft's MS-DOS, the de-facto operating system for many computers available in the 80s and 90s. As FreeDOS is open source, anyone can get the[source code](https://freedos.org/source/)and has the liberty to use, redistribute and propose modifications to it. Having already achieved its original goal of full MS-DOS compatibility, FreeDOS has since evolved past MS-DOS with many new features, such as APM power management, the FDNPKG network-enabled package manager, LBA large disk support, Long File Name support, as well as several tools and commands from the Linux world, such asgrep,cal,head,teeandless. FreeDOS is a complete operating system and, if so desired, can be installed over top of any operating system your computer currently has, replacing itand all of your datacompletely. Because of this, as opposed to installing directly on the computer you use daily, we recommend instead installing it into a "virtual machine" - a simulation of a complete computer system inside your existing PC - upon which you may[install FreeDOS](http://wiki.freedos.org/wiki/index.php/VirtualBox).[Emulators](https://www.freedos.org/links/)are available (and often totally free to use!) for all modern computer platforms which allow you to set up and configure these virtual machines. Alternatively, if you have an old and otherwise unused computer taking up space, you can[install FreeDOS directly on real hardware](http://wiki.freedos.org/install/)as well. FreeDOS comes packaged with a[base collection](https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/group-base.html)of programs which duplicate the commands offered by MS-DOS and, as such, operates using a traditional text-based[command](http://wiki.freedos.org/wiki/index.php/Dos_commands)line interface. Like other DOS systems, FreeDOS does not include a graphical desktop by default, although for a more contemporary environment you can install one of the[graphical interfaces](https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/group-gui.html)available. Of course every application available cannot fit in the default FreeDOS installation, but we have made available[a large collection of other programs](https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/index.html)which provide features akin to those found on modern computers, and there are other websites which showcase[additional programs](https://www.freedos.org/links/)made to run in any DOS-compatible system, including FreeDOS. As FreeDOS provides 100% compatibility, you can even run any MS-DOS-era applications or games you already own. If you have questions or encounter problems while using FreeDOS, help is always available at the[FreeDOS Wiki](http://wiki.freedos.org/wiki/index.php/Main_Page)knowledge base. If a solution cannot be found there, you may communicate with FreeDOS developers and users directly using the[FreeDOS Mailing Lists](https://www.freedos.org/forums/). Although FreeDOS has spent years of its life under test in real-world conditions, there's always the possibility of unintended behavior in any software. To aid in exterminating bugs, the FreeDOS project maintains a[list of known issues](https://www.freedos.org/bugs/)where you can report any bugs you may encounter. What do y'all think? Sent with [ProtonMail](https://protonmail.com/) secure email. --- Original Message --- On Tuesday, May 3rd, 2022 at 1:45 PM, Paul Dufresne via Freedos-devel wrote: > Precedently suggested web site should have at the beginning: > > "I know all this" links to the following: > > News (link to news) > > Let's talk ( https://www.freedos.org/forums/ ) > > Wiki ( http://wiki.freedos.org/wiki/index.php/Main_Page ) > > Bugs ( https://www.freedos.org/bugs/ ) > > Gitlab (link to https://gitlab.com/FreeDOS ) > Github (link to https://github.com/search?q=freedos) > Ibiblio ( link to https://www.ibiblio.org/pub/micro/pc-stuff/freedos/ ) > Ibiblio What's included ( > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/official/report.html > ) > Kernel ( https://github.com/FDOS/kernel ) > > The downloads ( https://test.freedos.org/download/ ) > > Other links ( https://www.freedos.org/links/ ) > > Visit web page for newcomers (link to previously suggested page)___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Update on website usability test
A "Developers" link would be a nice place to showcase libraries or other topics of use to devs, showing how FreeDOS may be a perfect fit for deploying their next project/BIOS update/whatever. Sent with ProtonMail secure email. --- Original Message --- On Monday, April 25th, 2022 at 3:58 AM, Parodper wrote: > O 24/04/22 ás 21:56, tom ehlert escribiu: > > > how do I locate binaries (or even source) for fdisk, format, keyb, > > himem, (command and kernel are possible), edlin(the most ever relevant > > dos program), sort, find? > > Contribute -> FreeDOS GitLab > > > Maybe there should be a text under «Download» to link to this. Something > like «For expert users and developers» > > There should also be a section, under «Learn More», about what software > (from ibiblio and in the images) FreeDOS contains. That should include > info about FDIMPLES (which, IMHO, should probably have network > capabilities) and FDNPKG. Those are the easier ways to get sofware into > FreeDOS. > > Compare to the external archives under «Applications», for which there > is no info on how to get the software into FreeDOS, either under > physical (floppy disks seem to be hard to come by these days) or virtual > machines. > > Also, maybe there should be a way to access the HTMLHELP pages from the > front page. > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Update on website usability test
This looks way better! What an improvement over the current site! :) Sent with ProtonMail secure email. --- Original Message --- On Friday, April 22nd, 2022 at 7:05 PM, Jim Hall wrote: > I mentioned in February that I've been working on a new website > redesign as a "back-burner" project for a while. I also shared that I > was working with undergraduate students in Usability Testing, at the > University of Minnesota and Michigan Tech University, to do a > usability test of the "new" website. > > The students have been working on their usability tests over the > semester. This week, the first group (MTU) presented their results. > > > Brief background: > > The new website design was proposed to us for free by a professional > website designer based in Germany. I modified the design slightly (the > web designer wanted to change the colors and logo and some other > things .. I changed these back) and I used that to create a > mostly-working version of the new design at https://test.freedos.org/ > > The student groups designed, executed, and analyzed a usability test > of the test website from late February (or early March?) to mid April. > The MTU students presented their results this week. (U of M students > will present their results on May 3.) > > MTU usability test: (my summary) > > The MTU student group focused their usability test on these scenarios. > Each scenario involved one or more tasks: > > 1. Browse the website to find where to download FreeDOS > 2. Find instructions to install FreeDOS > 3. Find the FreeDOS wiki (the wiki was not part of the test - that's a > whole other cleanup project - but I wanted to know if people could > find the wiki) > 4. Find how to join the FreeDOS email list > 5. Find recent news about FreeDOS > > MTU used 5 testers (you need a minimum of 5 testers to get feedback > that's good enough to make design changes .. but we had other groups > doing usability tests too) who were between 21-29 years old, and rated > themselves as more technical users. > > Results: (my summary) > > 1. Browse the website to find where to download FreeDOS (3 tasks) > > Easy. Testers had little to no problems completing all three of these tasks. > > 2. Find instructions to install FreeDOS (2 tasks) > > Hard. Two testers were completely unable to complete either task. The > other three testers had trouble finding the install instructions (but > found them). > > 3. Find the FreeDOS wiki (1 task) > > Very easy. No issues here. > > 4. Find how to join the FreeDOS email list (1 task) > > Hard. All testers struggled with this task. > > 5. Find recent news about FreeDOS (1 task) > > Easy. Testers had little to no problem completing this task. > > > Additional comments (my summary): Testers thought the website reminded > them of other websites about software, so it felt familiar. But > testers also commented that the design seemed pretty minimal (this was > a mock-up that was 90% complete, so I'm not surprised by that). > Testers reported they could usually find what they needed, and the > website was fast, and they felt they had an overall "positive" > experience on the new website. > > Recommendations (my summary): > > * Make installation instructions easier to find: There's a "How to > install" link on the front page - this was going to be a button, but > it was just a link in the test website. However, testers said they > expected the "How to install" link to be on the "Download" page, and > they wouldn't have expected it to be on the front page. They also had > recommendations to change some other text, like replacing "What you > need" with a more direct call to action like "Get started with > FreeDOS." > > * Make the email lists easier to find: Testers said they expected > there to be a separate "Email list" link on the website, either at the > top of the page or in the footer. They eventually found it in the > "Contribute" page. Once they found it there, they said it made sense, > but that wasn't where they thought to look for it. > > * Add a "Home" button in the top navigation bar. Testers said they > didn't realize at first that the logo was a link back to the home > page. Once they tried clicking on it, they said the "logo as link" > made sense, but they would expect to find a link called "Home" > somewhere on the page, like at the top of the page. > > * Use "News" to describe what's new. The test site has a "News" page, > so they found it. But I think the recommendation here was that once > you clicked on the page, it was called "What's New" and not "News." > > * Add bullet points in the news page for new software updates. The > general comments here are that people don't like reading a lot of > text, so they'd prefer just to see text like "IA-16 GCC Toolchain And > Libi86 Library, Jan 2022 Version" or "Updated DWED Editor For DOS" as > "bullet points" and have some other way to show details. > > > __ > > My comments: > > Overall, the results are good. I'll need to update the
Re: [Freedos-devel] "FreeDOS Next" packages
+1 100% Sent with [ProtonMail](https://protonmail.com/) secure email. --- Original Message --- On Saturday, April 2nd, 2022 at 3:41 AM, Maarten Vermeulen wrote: > I never really say anything here, but I feel like I should here. > > I do agree with Mike here. When I install a DOS, I just want it to be DOS, so > I always install just the base option with FreeDOS. Having less packages also > means you have more control over the software and the project. > > Yes, you have the choice between installing base, full, etc. However, if you > install full, you will get a lot of stuff that you will probably never use. > So the packaging people here are taking a lot of effort to make extra sure > more people will use less of their packaging work. > > There is some chart, I believe it's a bit of a joke, but it shows that people > only use like 10% of any software on a regular basis. That is a low amount. > And if that's already the case with base (which for me it is), then how about > full? > > Like Mike said, isn't it easier to just offer base and then provide a > repository with open source packages that people can choose from? It also > offers control over the project. And then there's the added benefit that > people who install the software from that repository, always get the newest > release of that software. > > Also, if someone has some proprietary text editor they really like, and want > to use it, it won't be in full. Those people will never install full, because > they will get six other editors installed on their system too. Or they will, > and they'll get those six other editors which they will never use and are now > using up precious disk space. > > When I use FreeDOS, I feel like a lot of choices are made FOR me. That's not > how I think software should be. Certainly not DOS. Six editors installed with > full? Why? Who is going to use all six editors? What is the chance that > someone will choose not to use those editors? Why does FreeDOS choose my > editors for me? I know I can choose not to use them, but they are installed > now, so what do I do? Delete them? You're introducing a lot of extra work and > thinking steps for the user this way. > > Even Windows 10, which installs games and software on first start-up, that no > one has asked for, at least is nice enough to install only one from each > category. > > If you want one package from full, you have to install the entire category > and uninstall the rest, or uncheck them from a screen. I don't want to. > > There are a lot of people that use FreeDOS just because it's a DOS, and not > because it's libre or free. Libre also means freedom. To me that also refers > to having the libre to choose your own packages. > > Less is more. > > - Maarten > > PS: I used editors in my examples but pick any category you like.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS wins award from SourceForge
Thanks, Jim! :) Sent with ProtonMail Secure Email. --- Original Message --- On Thursday, March 3rd, 2022 at 12:14 AM, Jim Hall wrote: > If you'd like to download one of the SourceForge badges to add to your > > own site, you can find them here: > > https://www.freedos.org/images/sfbadges/ > > (Use right-click and "Save As" to download the image. These are SVG > > files, so will scale nicely to smaller or larger sizes.) > > On Tue, Mar 1, 2022 at 6:19 PM Jim Hall jh...@freedos.org wrote: > > > Hi everyone > > > > I received this email from SourceForge and wanted to share it. I'd > > > > guess this is partially to recognize the recent FreeDOS 1.3 > > > > release. Either way, this really belongs to the community here. Grab > > > > a copy of the badges from our SF project page and put them in your > > > > own website. > > > > I'm away from my computer today, but I'll put copies on the website > > > > tomorrow and link to them from a news item. > > > > Jim > > > > --- forwarded message > > > > Congratulations! The FreeDOS Project has just been recognized with > > > > the following awards by SourceForge: > > > > Community Leader > > > > Community Choice > > > > Open Source Excellence > > > > Open Source Excellence > > > > SourceForge Favorite > > > > These honors are awarded only to select projects that have reached > > > > significant milestones in terms of downloads and user engagement > > > > from the SourceForge community. > > > > This is a big achievement, as your project has qualified for these > > > > awards out of over 500,000 open source projects on > > > > SourceForge. SourceForge sees nearly 30 million users per month > > > > looking for, and developing, open source software. These award > > > > badges will now appear on your project page, and the award assets > > > > can be found in your project admin section. > > ___ > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Status of NightDOS kernel?
"Officially" Night is in fact still an ongoing project. The problem is that I haven't had much time to devote to it for a while now, and I know Maarten and Antony have a lot going on as well. After completing a handful of other projects that have popped up, I will definitely be going back to Night. As it stands, the Night kernel can actually multitask random chunks of code already in memory, but as of yet there's no protected memory, no API for loading actual COM or EXE applications, nor is there any implementation of the DOS API. Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, January 16th, 2022 at 5:52 PM, Jim Hall jh...@freedos.org wrote: > Does anyone know the current status of the NightDOS kernel effort? > > This is (was?) a project to create a 32-bit drop-in replacement for > > the FreeDOS kernel. Mercury was a key developer on this. But the > > "official dev thread" discussion on Google Groups seems to have > > stalled out in 2020, although there was some discussion about PDOS/386 > > in 2021: > > https://groups.google.com/g/night-dos-kernel?fbclid=IwAR2Pg7wDqhKO8VsXrYCipKxgdEE1dvjVPmEPJyUI0oY2O5stpMPfBuZYooQ > > I was curious if NightDOS kernel was still ongoing. > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Contemplations, Considerations and some Conclusions
On Sunday, January 16th, 2022 at 3:34 PM, Jim Hall wrote: > ... > I run Linux, and use Fedora on my PC. When I download a new version of > [Fedora Workstation](https://getfedora.org/en/workstation/download/), it > comes as a DVD ISO image. But my PC doesn't have a DVD drive (my previous > laptop didn't have an optical drive either) so I write the ISO image to a USB > fob drive using [Fedora Media > Writer](https://developers.redhat.com/blog/2016/04/26/fedora-media-writer-the-fastest-way-to-create-live-usb-boot-media#how_does_it_work__). > I think you can do the same with [Rufus](https://rufus.ie/en/). It writes > the image and makes the USB fob drive bootable. > > So my question is really: what about using Rufus to write the FreeDOS 1.3 CD > ISO image to a USB fob drive - instead of providing a 32MB "Lite" USB image > and a 512MB "Full" USB image. > ... FWIW, when I need to boot FreeDOS on real hardware, I almost always do it this way using the built-in tools of Linux Mint. Works great for me, so I see no reason why the average FreeDOS user couldn't do something similar.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: ACPI auto power ON
Well, I may as well throw my two cents in here. :) On computers using a standard ATX power supply, pin #9 on the connector provides power to the motherboard at all times as long as the PSU itself has AC wall power power coming in. Modern motherboards use this "Standby" power to run small always-on power management circuitry (I believe this is integrated directly into the chipset these days) which monitors all sources of a "power on" signal, be it the power button on the case, or a LAN controller, or a built-in watchdog timer, or what-have you. When such a signal is received, this power management circuitry pulls pin #16 low to power up all the other voltage lines of the PSU, which fully turns on the computer. Optionally, some BIOSes allow the user to choose whether or not to instantly power up when this pin begins outputting voltage (e.g. when wall power is restored). So yes, the motherboard does fire up some circuitry as soon as it gets power, but it doesn't boot per se. Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, January 13th, 2022 at 5:12 PM, Bret Johnson bretj...@juno.com wrote: > there is absolutely nothing complicated to have a > > "on power return, boot computer" > > option. it used to be the default. You all are missing the point. As soon as the motherboard gets power, it starts booting. That is how it has always worked. The problem is how to get the appropriate power to the motherboard in the first place. If you lose power to the motherboard, either because the power supply lost its external (wall) source or because something in the power supply went bad, the computer will boot when power is supplied to the motherboard again. The problem is, the BIOS and the ACPI are on the motherboard and need power in order to function, and they can't tell the power supply to turn on if the power supply is not already supplying power to them. It's a circular regress (or a "Catch 22"). There is no setting to tell the computer start booting when it first gets power -- it does that automatically and you can't disable that "feature". The problem is how to get the power to the motherboard in the first place, and you can't do that with software that doesn't do anything unless it already has power being supplied to it and the computer has already started booting. Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: ACPI auto power ON
This feature was nonstandard across various BIOS implementations, so it is highly likely that if the BIOS does not support it via its built-in interface (the "Press to enter SETUP" prompt) it is probably entirely unavailable. Just to be sure, I checked the [CMOS Memory Map document](https://fd.lod.bz/rbil/cmos/power/index.html) in Jerome's excellent online version of the Ralf Brown Interrupt List - the feature is not listed. Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, January 13th, 2022 at 4:47 AM, Ladislav Lacina wrote: > Hello experts here! > I am forwarding you a question abou ACPI interface. Although I am the author > of ACPITOOL I am not able to answer it. > Thanks > -- Původní e-mail -- > Od: retro devices > Komu: la...@seznam.cz > Datum: 13. 1. 2022 0:36:10 > Předmět: ACPI auto power ON > >> Hi and thank you for your ACPITOOL. I decided to ask you because I cannot >> find the answer myself and you seem to be very experienced in ACPI >> programming under DOS. >> >> Is there a way via the ACPI\s API to tell ACPI to automatically power on >> after power loss AND when the BIOS SETUP does not include such setting? >> >> Kindest regards, >> George___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Pushing source code to Github
Personally, I've never used the VMDK format. I always use a preallocated VDI. Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, January 10th, 2022 at 10:57 AM, Tyson Oswald wrote: > Alright I have tried to Crete a VMDK virtual hard disk in Box but when I go > to format the disk I get an error > > DOS Diver error (hex) 01 > > [Error 129] > > Here is a link to the image. > > [https://www.dropbox.com/s/pi8oz7gs0cbnamu/Screen%20Shot%202022-01-10%20at%2010.54.58%20AM.png?dl=0](https://www.dropbox.com/s/pi8oz7gs0cbnamu/Screen > Shot 2022-01-10 at 10.54.58 AM.png?dl=0) > > Any idea what this means? > > Thanks, > Tyson > >> On Jan 10, 2022, at 6:01 AM, Liam Proven wrote: >> >> On Mon, 10 Jan 2022 at 01:51, Jim Hall wrote: >> >>> When you edit with Pico, you're really editing with an email composer. >>> Pico stands for the Pine Composer. Pine was an email client that replaced >>> another email client called Elm. Pine stands for Pine Is Not Elm. >> >> Oh cool! I knew the editor but not the connection. Thanks! >> >> FWIW there is a great free Linux text editor called Tilde that I like. >> It's basically the same UI as later-era DOS editors, so you can use >> the same keystrokes. Ctrl+O to open, Ctrl+S to save, etc. I find it >> easier than Pico, Nano, Joe etc. >> >> It's in the repos for openSUSE and Ubuntu and can easily be installed >> on other distros. >> >> -- >> Liam Proven ~ Profile: https://about.me/liamproven >> [Email: lpro...@cix.co.uk](mailto:lpro...@cix.co.uk) ~ gMail/gTalk/FB: >> lpro...@gmail.com >> Twitter/LinkedIn: lproven ~ Skype: liamproven >> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) >> 702-829-053 >> >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Pushing source code to Github
On Sunday, January 9th, 2022 at 12:51 PM, Tyson Oswald oswa...@charter.net wrote: > There is supposedly a way to mount the virtual disk on macOS when it is > unmounted from the VM but I haven’t been able to get it to work. VB comes > with MacFuse for that purpose but have never been able to get it to work. > Basically it can’t find the MacFuse library. > > ... On Linux (I'd think something similar would work on Mac) I create my virtual machine with a disk image which is pre-allocated, as Jerome mentioned. This creates what is basically a complete hard disk image, albeit with a header of some size (2 MiB, I think? Not sure off the top of my head.) slapped on the front. You can then use a Linux loopback device to mount this and write to it directly as you would with any other drive when your VM is not running. Granted, it's been awhile since I've needed to do this,but that's the general procedure. For the exact method I used, see the [Makefile](https://github.com/mercury0x000d/NightKernel/blob/Development/Makefile) in my Night Kernel repo. Regarding my workflow, I use the excellent application Sublime Text as my editor of choice, then compile under NASM/ Open Watcom in the Linux terminal. For applications, I use DOSBox for testing from build-to-build, then a FreeDOS VM to test major milestones, however for lower-level code I test both in the VM and by booting from a FreeDOS-formatted USB stick on various real machines. As far as the files themselves, I use SyncThing to synchronize all my work between my machines, and I use the GitKraken frontend for uploading to GitHub. Hope this helps! :)___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] REMember a bug
On Saturday, January 8th, 2022 at 7:17 PM, Jerome Shidel jer...@shidel.net wrote: > ... > > Personally, I think it should be fixed. No one should be using that. > > ... Agreed 100%. :)___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Devel-Philosophy [was: blocking bugs/issues for FreeDOS 1.3]
Yep, language names like German, French, Spanish, et. al are all considered "proper nouns" and as such should be capitalized. :-) Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, August 6th, 2021 at 2:05 PM, tom ehlert t...@drivesnapshot.de wrote: > Hi Robert, > >>> attaches the german resources to fdisk.exe, and makes german the >>> >>> default language for fdisk.exe. > >> Minor note: AFAIK, correct spelling of "german" in English is "German" >> >> with a capital "G". Same for all other language "names". > > really? Like in 'Could you provide the German resources?' > > if true, I have done that wrong for the last 50 years. > > Insights from native english/american (English/American) people? > > Tom > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] video FreeDOS running Windows 3.1
This is awesome! :D Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, July 24th, 2021 at 2:01 AM, wrote: > Hello all, > > I thought some of you might enjoy this (others may really dislike it). > > Link is to a (posted to YouTube) about 2 minute video of (version > > 2043+patches) FreeDOS kernel running Windows 3.1 in Enhanced and > > Standard mode. I haven't pushed the changes to the public GitHub > > repository yet as there are still some rough edges to fix (all the > > changes are technically there, just in the old unstable branch). I > > will make a test version (with source) available later this week along > > with steps to run Windows. [I need to go to sleep now.] > > https://youtu.be/35OQjLYdvJ0 > > (I apologize for anyone that can't view the video - it is just FreeDOS > > kernel booting in VirtualBox, me running a bunch of ver /r commands > > and WIN along with a dos prompt, and showing both enhanced and > > standard mode.) > > For the technical aspect - the changes are minimal to the kernel, > > added support for a few int 2F function calls that were never merged > > in was about all it took. All significant changes behind a > > WIN31SUPPORT #ifdef so doesn't need to be compiled in if unwanted. > > Enjoy, > > Jeremy > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] MEM command curiosities
During some recent development work, I noticed that the FreeDOS MEM command reports the TSR I'm writing is using one less paragraph than its MS-DOS counterpart - it seems it does not account for space occupied by the MCB at the start of the TSR's heap, while the MS-DOS MEM command does. I'm unsure if this was this intentional (e.g. maybe MCB memory is counted somewhere else in the output of the FreeDOS MEM command) or simply an oversight, but... there you have it. lol If anyone wants a deeper dive into the topic, feel free to check out [my blog post](http://mercurycoding.com/blog.html?date=7/13/2021) on the matter. Sent with [ProtonMail](https://protonmail.com/) Secure Email.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] A new UHDD release! :D
Hey all! I've packaged up the most recent version of UHDD, which you can find at MercuryCoding.com/downloads.html#DOS. The new version supports Read-Ahead and DMA/Caching Overlap for all cache sizes from 5 to 4093 MiB, which should help make all the work done by Jerome's FreeDOS installer happen faster than ever. Enjoy! :) Sent with [ProtonMail](https://protonmail.com/) Secure Email.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] What a good MBR should do
I would add: else ERROR 'No partitions detected' to the bottom of that as well. :) ‐‐‐ Original Message ‐‐‐ On Thursday, June 24th, 2021 at 2:57 AM, Paul Dufresne via Freedos-devel freedos-devel@lists.sourceforge.net wrote: > I was thinking what a modern MBR should do and come to the following > pseudo-code: > > If GPT exist > > If BIOS_Boot_Partition exist > > Give control to it (probably second stage GRUB) > > else if a GPT bootable partition exist > > Give control to it (could be many things) > > else Error 'No GPT bootable partition!' > > else (MBR partition) > > if an MBR bootable partition exist > > give control to it > > else ERROR 'No MBR bootable partition' > > I think in most cases, it would do the right thing. > > And could be better than most MBR already present. > > Not sure it could be coded in such a small place however. > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re : Got a working gnuchess 5.05
Thanks for this! Always nice to see new/updated software for FreeDOS. :) Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, June 23rd, 2021 at 6:23 PM, Paul Dufresne via Freedos-devel wrote: > made a package for GNU CHESS 5.05 called GCHES, at: > https://gitlab.com/dufresnep/gches/-/tree/main/GCHES1_0 > > Feel free to test for virus ( I did not ), and try.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Why games have bad color in VirtualBox
This wouldn't be the first thing VirtualBox doesn't implement fully/correctly. Another notable omission is the "direct" mode of creating sound by writing values straight to a SoundBlaster-compatible card; VirtualBox only supports DMA transfer for sound. Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, June 17th, 2021 at 8:56 AM, Paul Dufresne via Freedos-devel wrote: > DOSEMU2 seems to report itself almost exactly as VirtualBOX, that is: > VBE 2.0, D1=0:VGA compatible D1=0, D0=1:DAC is fixed with 6 bit by primary > color > > This destroy my hypothesis about games USING VGA Set palette function... > rather than the VBE one (AL=9... had wrongly written AH=9 in previous mail). > Because games works fine about palette in DOSEMU2. > > So the new hypothesis is: VirtualBox does not handle correctly direct > manipulation > of VGA palette registers, although claiming VGA compatibility would suggest > it should.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Additional notes on Games
On Wednesday, June 16th, 2021 at 8:18 PM, Jim Hall jh...@freedos.org wrote: > ... > >> [..] >> >> Sorry but that thread about which games may or may >> >> not work is frustrating me given that there always >> >> seems to be SOME context in which some games fail. > > Ending up with weird graphics on VirtualBox is okay if it's just a > > VirtualBox config. That's why I was asking if someone who knows more > > about VirtualBox can suggest a config for me to use. I don't use > > VirtualBox most of the time, so I'm unfamiliar with it. I've tried > > changing the graphics controller option in VirtualBox - there are only > > a few options - but I'm not getting it. As my bare-metal DOS hardware is down at the moment, at this point in time I use FreeDOS exclusively in VirtualBox. Perhaps I can poke around in the video settings in the coming days and see if I can uncover anything. > ...___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] UIDE package - new release
Hey, all! (Namely Jerome :] ) There's a new UIDE package which contains some small modifications to the accompanying documentation as suggested by Jack. There are no binary changes. It can be found in the [DOS Library at Mercury Coding](http://mercurycoding.com/downloads.html#DOS). Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
On Monday, May 31, 2021 6:36 AM, Steve Nickolas usots...@buric.co wrote: > On Mon, 31 May 2021, Mercury Thirteen via Freedos-devel wrote: > >> +1 >> Personally, I always thought it would be best to have this "phantom >> drive" feature disabled by default and allow the user to enable it if >> they need. But that's just me. :) > > Personally, I'd go with the opposite: behavior compatible with MS-DOS 3.3 > ought to be the default because it's what most people would expect from > software that has as its primary compatibility target Compaq MS-DOS 3.31 > (not sure if that's still accurate, it's certainly been a long time since > I checked). > ... Right! I wasn't suggesting FreeDOS change - I get why it was originally done, and that FreeDOS has to do it to mimic the behavior of any other DOS. I simply meant that I've always thought it should be optional, even back in the MS-DOS days.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Time to end with diskette DJ system? (aka famtom drives?)
+1 Personally, I always thought it would be best to have this "phantom drive" feature disabled by default and allow the user to enable it if they need. But that's just me. :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, May 31, 2021 3:46 AM, Carsten Strotmann wrote: > Hi Ladislav, > > On 30 May 2021, at 23:44, Ladislav Lacina wrote: > > > Maybe is a time to consider whether to break the MS-DOS compatibility > > about > > handling the one physical diskette drive as two logical drives - A: > > and B: > > It maybe had some reason in 1982 but now? > > the same reason that was valid in 1982 is still valid today: machines > with only one floppy drive and no harddisk. I have a couple of these > machines where I use FreeDOS on (not only old machines, even some > relatively modern machines where the hard drives have been removed). > > The function is important when working in such environments. > > However it might be possible to introduce a configuration option in > config.sys that disables this function if users wish (or even inhibit > the phantom drive B: by default in case FreeDOS detects at least one > usable hard-drive partition during boot-up). > > Greetings > > Carsten > > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Cleanup on FreeDOS Ibiblio
On Monday, May 10, 2021 1:00 PM, Robert Riebisch r...@bttr-software.de wrote: > Hi Mercury, Hello there! > > I'd say we really /do/ need a set standard for versioning. The > > frustration Eric mentioned in his email has hit me once or twice as well > > when combing through archives to compare versions. > > The format I propose is: > > > > - The date in ISO 8601 format > > ISO 8601 has various formats. You specifically mean: MMDD I wasn't aware it has various formats, but yes - MMDD specifically. > (And "The date" means the date, when a version was released by its > developer, not the upload date to Ibiblio.) Correct, the date of the version's release. > > - Two digits for the major version > > There probably will be some software needing three digits. Firefox, > although not available for (Free)DOS), is already at version 88.0. Right, but I was basing this on the majority of FreeDOS software which jumps to mind. I don't think we have any applications which are quite so liberal with their version numbering. A side note/gripe here: Traditionally (at least the way I have learned it) you only increment the major version when making a major change to the application - e.g. changing the structure of files saved by the application or perhaps a major overhaul of how things work internally. With that in mind, how, pray tell, could Firefox possibly be at 88.0? Mozilla, do you mean to tell me you made sweeping, application-wide changes eighty eight times? I think not lol :) > There also already is FreeDOS kernel 2042. Gah, ok you got me there. I hadn't thought of the kernel at all. Off the top of my head, though, I'm not certain; is 2042 a version number in and of itself or just a revision/build number? > > - Two digits for the major version > > You mean "minor" here, I think. Correct, I did mean to say minor. > > - Two digits for the revision > > In general, these are four digits sometimes. Good point. Now that you mention it, since many applications use a short integer for their revision/build number, this in theory could yield version numbers up to five digits long. Perhaps that would be a better choice for future-proofing? Or would that be overkill? > > - A character for the packaging identifier (this would be changed in > > cases where the packaging of the application has changed but the > > application itself has not) > > > > Your screenshot doesn't include such an example. > Would that be "20210510-010101-a-b"? Yes, exactly. I haven't yet decided on whether to leave this blank when there's no package identifier or to make everything default to "a". I'm leaning towards the latter. > > - A character for the type of archive (Perhaps something like: a = All, > > b = Binary only, s = Source only) > > > > - Hyphens between all fields for clarity > > > > > > For the hypothetical application /GeeWhiz/, this would give us the > > following structure: > > GeeWhiz > 20180117-010001--b > 20180117-010001--s > 20190202-010002--b > 20190202-010002--s > 20201110-010005--b > 20201110-010005--s > 20210509-010100--b > 20210509-010100--s > For computers that's easy to read, but for humans? > How about that, if we already break 8.3? > 2018-01-17_01.00.01__b > 2018-01-17_01.00.01__s > 2019-02-02_01.00.02__b > 2019-02-02_01.00.02__s > 2020-11-10_01.00.05__b > 2020-11-10_01.00.05__s > 2021-05-09_01.01.00__b > 2021-05-09_01.01.00__s > With 3 or 4 digits for the version numbers: > 2018-01-17_001.000.0001__b > 2018-01-17_001.000.0001__s > 2019-02-02_001.000.0002__b > 2019-02-02_001.000.0002__s > 2020-11-10_001.000.0005__b > 2020-11-10_001.000.0005__s > 2021-05-09_001.001.__b > 2021-05-09_001.001.__s > Or in condensed layout, if sorting by date is enough: > (Then the number of digits for the version numbers doesn't matter.) > 2018-01-17_1.0.1__b > 2018-01-17_1.0.1__s > 2019-02-02_1.0.2__b > 2019-02-02_1.0.2__s > 2020-11-10_1.0.5__b > 2020-11-10_1.0.5__s > 2021-05-09_1.1.0__b > 2021-05-09_1.1.0__s Yes, that could work also. Accepting that, I would take it a step further and simply use spaces between the fields: 2018-01-17 001.000.1a b 2018-01-17 001.000.1a s 2019-02-02 001.000.2a b 2019-02-02 001.000.2a s 2020-11-10 001.000.5a b 2020-11-10 001.000.5a s 2021-05-09 001.001.0a b 2021-05-09 001.001.0a s I find it more intuitive to leave the fields expanded so that the numbers easily flow visually, not to mention it would make for easier code writing if the programmer knew the same range of characters would represent the same piece of data in every package name. Also, on the odd chance an author has two versions come out in a single day (some bug fixes happen fairly fast) then condensing puts us right back in the same boat. For these reasons, I vote no on condensing. But that's just me. :) > > ... > > For an online repository that would be okay, but not for the distros. > Space on physical media is still limited. Web
Re: [Freedos-devel] Cleanup on FreeDOS Ibiblio
I'd say we really do need a set standard for versioning. The frustration Eric mentioned in his email has hit me once or twice as well when combing through archives to compare versions. The format I propose is: - The date in ISO 8601 format - Two digits for the major version - Two digits for the major version - Two digits for the revision - A character for the packaging identifier (this would be changed in cases where the packaging of the application has changed but the application itself has not) - A character for the type of archive (Perhaps something like: a = All, b = Binary only, s = Source only) - Hyphens between all fields for clarity For the hypothetical application GeeWhiz, this would give us the following structure: Note that there is no program name at all in the individual archives - the parent folder has that instead. Programs which simply use the date as their version number would leave the version field as "00". Also, in my opinion, the package type (A, B, or S character ) could be omitted since every archive should have all components - all source code, all binaries, all documentation, etc. It should be up to the installer/archiver to only extract what the user requests from the archive. The only drawback (if you can call it that) with this specification is that the resulting filenames are most definitely not 8.3 compliant. My fix for that - that is, if we even care about this issue - would be to have one ZIP for each application, then have all versions of that program in that single ZIP. I know, I know, that doesn't make it easy to download a single version, but is that really an issue since the majority of our applications are so tiny to begin with? Also, doing so would allow archivers to achieve a much higher compression ratio, and ultimately saving space in the end. This concludes my feedback on the issue :) I'm interested to hear everyone else's thoughts on this as well. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, May 1, 2021 11:53 AM, Robert Riebisch r...@bttr-software.de wrote: > Hi Jim, > >> Just wanted to let you know that I did a little cleanup on the FreeDOS >> files archive at Ibiblio. > > Okay. > >> Over the history of using the files archive on Ibiblio, I haven't really >> done a great job at keeping things clean. For example, there was one >> directory for FreeDOS Choice at /files/dos/choice >> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/choice/ and >> /all/ of the releases for FreeDOS Choice lived there, just dumped in one >> directory listing: >> >> choice201.zip >> choice20.zip >> choice30.zip >> choice31.zip >> choice33.zip >> choice35a.zip >> choice35b.zip >> choice35.zip >> choice36a.zip >> choice36b.zip >> choice36c.zip >> choice36d.zip >> choice36e.zip >> choice36.zip >> choice37.zip >> choice38a.zip >> choice38b.zip >> choice38.zip >> choice41.zip >> choice42a.zip >> choice42b.zip >> choice43a.zip >> choice43.zip >> choice44s.zip >> choice44x.zip >> >> If you wanted to get the latest version of FreeDOS Choice, what file >> would you download? Would you grab the first one on the list >> (choice201.zip) or the last file in the list (choice44x.zip)? If you >> know the history of FreeDOS Choice, you would know that choice201.zip is >> version 2.01, and choice44x.zip is version 4.4. > > I would have hoped to find "files" named latests.zip and latestx.zip (or > something like that), which always link to the latest version. > >> 4.2: >> alt_TE/ choice42a.zip choice42b.zip >> 4.3: >> alt_TE/ choice43a.zip choice43.zip > > What is "alt_TE"? > >> I haven't finished going through /all/ the directories on Ibiblio yet .. >> that will take months. But wanted to let folks know I was doing it. > > "Even the longest journey..." You know it. ;-) > Cheers, > Robert > --- > > +++ BTTR Software +++ > Home page: https://www.bttr-software.de/ > > DOS ain't dead: https://www.bttr-software.de/forum/ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Cleanup on FreeDOS Ibiblio
+1 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, May 1, 2021 2:56 PM, Eric Auer wrote: > Hi Jim and Robert, > > indeed I have slowly moved to more "sorted directory listing > friendly" date formats, but it would not be a problem for me > if you decided to rename all files lbacache_-mm-dd.zip > style and put them all in ONE directory. Then one can see > at one glance what is available, without having to go up > and down to go in and out each of a pile of subdirectories. > > Regards, Eric :-) > > > For the programs that used a "date" instead of a version number, I > > have been doing that. For example, LBACACHE used dates instead of a > > version number. I organized that directory like this: > > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/lbacache/ > > lbacache/2002: > > lbacache-10nov02.zip lbacache-12nov02.zip > > lbacache-11nov02.zip lbacache-28aug02.zip > > lbacache/2003: > > lbacache-01apr03.zip lbacache-25aug2003.zip lbacache-27aug2003.zip > > lbacache-23apr2003.zip lbacache-26jun2003.zip lbacache-31jul2003.zip > > lbacache/2004: > > lbacache-01may2004.zip lbacache-16apr2004.txt lbacache-22sep2004.zip > > lbacache-01sep2004.zip lbacache-16apr2004.zip lbacache-24jul2004.zip > > lbacache-09may2004.zip lbacache-17jun2004.txt > > lbacache-15jul2004.zip lbacache-17jun2004.zip > > lbacache/2005: > > lbacache-2005jun19.txt lbacache-2005jun19.zip > > lbacache/2006: > > lbacache-2006aug31.txt lbacache-2006aug31.zip > > lbacache/2008: > > lbacache-2008apr07.zip lbacache-2008jan18.zip > > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] RC4
On Monday, May 3, 2021 3:45 PM, Robert Riebisch r...@bttr-software.de wrote: > ... > Most is explained here: > http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages > ... Speaking of "here", at that link I happened to see this question regarding DJGPP: "license ok **Question: did DJGPP release a DOS port of GCC 8.2.0? Should we update?" And according to [this](https://en.wikipedia.org/wiki/DJGPP) it seems that the DJGPP project has GCC 9.3.0 with a note that 10.2.0 is also available. Hope that helps!___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Distro autoexec/config wishes for 1.3rc4 (CPULEVEL and CALLVER updates)
A quick side-note; I sent Ralf a quick email a while back simply asking if he was still accepting updates to the RBIL and he kindly affirmed he was, although he did indicate slight surprise that anyone was working on new DOS applications these days and would be interested in contributing additional data . :) Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, May 7, 2021 1:07 PM, Jerome Shidel wrote: > Hi, > >> On May 6, 2021, at 11:00 AM, C. Masloch wrote: >> >> On at 2021-05-06 01:10 +0200, Eric Auer wrote: >> [..] >> A HMA version string (with segment h, FFFEh, or any other HMA segment) >> is supported by my method. I think it is solid enough to check for non-zero >> dx. The string is expected in a data or code segment of the kernel, so there >> is no reason to ever use a zero segment. >> >>> And if somebody from any RBIL update project is listening, >>> the classic RBIL does not yet list int 21.33ff at all? >> >> I don't know of any such projects yet. If someone does want to document it >> elsewhere, they can of course add my support detection condition of >> returning a nonzero value in dx. > > Eric was referring to my very detailed RBIL2HTML project. You can view the > most recent HTML output at: > > https://fd.lod.bz/rbil/ > > If someone wants to provide me with some update text, I’ll stick it into a > file called “SUPPLMNT.LST”. > > Like the existing > https://gitlab.com/DOSx86/rbil2html/-/blob/master/source/CONFIG.LST file, it > uses the RBIL document format with > some additions. The additional section types are described in that file as > well. > > Next time I build the HTML docs, it will get incorporated into it. > > Please note, any submissions are required to agree the content they provide > is covered by the RBIL license agreement. To summarize, any one will be > permitted to copy, redistribute or publish the content with only a few minor > restrictions. See https://fd.lod.bz/rbil/copyright.html > > If you desire credit for the additions, you can simply create a BIBLIOGRAPHY > section (like in BIBLIO.LST). COPYRIGHT or CREDITS sections (like in > INTERRUP.1ST) can be used as well. Your new sections will be automatically > appended to the corresponding web pages. > > Additionally, you an give yourself credit directly in the new sections as > well. > > :-) > > Jerome___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] caps lock remapping TSR
I'd be very interested in that! I need to make a 68000 based computer myself one day to start playing with. Or buy a good kit to assemble lol Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, February 7, 2021 2:51 PM, John Tsiombikas nucl...@member.fsf.org wrote: > On Sun, Feb 07, 2021 at 05:52:58PM +0000, Mercury Thirteen via Freedos-devel > wrote: > >> Very cool! Almost as cool as that 68000 SBC you made awhile back. :) > > Thanks! > That was a fun project too, and I certainly intend to revisit it :) > --- > > John Tsiombikas > http://nuclear.mutantstargoat.com/ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] caps lock remapping TSR
Very cool! Almost as cool as that 68000 SBC you made awhile back. :) Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, February 7, 2021 11:50 AM, John Tsiombikas nucl...@member.fsf.org wrote: > It was indicated by jhall in his fosdem talk earlier today that this > would be the appropriate place to post this little utility I wrote a few > years ago, and that it might be of interest to the people here: > https://github.com/jtsiomb/capsmap > I usually remap caps lock to something more useful (ctrl) on all my > systems, and since I've been doing some retrocoding under DOS in the > past few years, it was annoying me that I didn't have that > functionality. > So I wrote this simple TSR to do caps-lock remapping. It basically sets > up a keyboard interrupt handler which handles capslock keypresses, by > either changing the BIOS modifier flags or appending to the BIOS > keyboard buffer (mapping is a compile-time option). For any other key > event, it just jumps to the original interrupt handler to let the BIOS > deal with it. > I placed the code in the public domain, so there shouldn't be any > licensing issues if you decide this is useful enough to include in the > FreeDOS distribution. > Also I'm only ever using it for remapping caps->ctrl, so for me the > compile-time choice of the mapping is sufficient and I did not have much > incentive to make it more complicated than that, but if more people are > interested in using it, I could improve it to make that a command-line > option. Either way, let me know if you try it and have any feedback. > Builds with nasm and make, but pre-compiled binaries are included in the > 1.0 release on github. > --- > > John Tsiombikas > http://nuclear.mutantstargoat.com/ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] New Debug and JWasm versions from Japheth
Hey all, I packaged up some of Japheth's newer releases of software we already have in the list: Debug 1.25 - > 1.27 JWasm 2.12 -> 2.14 They can be found at [the usual place](http://mercurycoding.com/downloads.html#DOS). Enjoy! Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New HiMemX version
"640K of memory should be enough for anybody." lol :) Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, January 13, 2021 4:47 PM, Andreas Berger andr...@thebergerclan.org wrote: > On 13/01/2021 18:18, Eric Auer wrote: > >> Hi! >> >>> I don't receive gigabytes at once. I have multiple serial lines using a >>> RS485 similar communications method (Master - Slave). The peers can be >>> up to 1KM away. Each line can have up to 50 peers. Each peer is >>> interrupted when it's 9-bit address is called and it starts >>> communicating. All peers are remote from each other but are one system >>> that must work synchronized. The large RAM usage is because the DOS >>> program (the big boss) must make fast decisions depending on things that >>> can have happened some time ago. Also, many peers have so little memory >>> that most of their status is stored by the DOS program and must be >>> available at any time. A disk is too slow. >>> Still... What needs more than 2 GB of data in that scenario? >> >> You can now have M2 SSD with between half a million and 1 million >> I/O per second, both for reading and writing. Even if you consider >> that single-threaded DOS I/O will perform significantly worse, >> you still get plenty of time for a bit of I/O unless you require >> nanosecond reaction times on a RS485 line where it takes at a few >> microseconds to transmit a single bit given your cable lengths. >> You could also use a multi level system with ramdisk, disk cache, >> fast SSD as disk, compressed swap memory etc. but of course I do >> not know which types of data access you need :-) >> I remember that when working with data acquisition in DOS, even >> the BIOS USB support for mice or keyboards had significant lag >> and jitter in the order of milliseconds, so there certainly is >> a point in using RAM for the fastest bits of your task - I just >> see an interesting challenge here to reduce footprint below the >> 32 bit pointer limit of a few gigabytes. Because beyond that, >> you will either make your whole app 64 bit or have to work by >> copying memory areas in and out your accessible few GB space, >> which is what HIMEMX with ultra extended XMS 3.5 would offer >> unless you also have a matching ultra extended long mode DOS >> extender to run the whole app in 64 bit address space. >> Another idea could be "ultra EMS" which just maps memory into >> accessible address space with a not-too-bad delay, giving you >> more freedom to decide later which exact address to access, >> without having to copy whole blocks. >> Regards, Eric > > All you say is very correct, and if I were to start today I would write > the program differently for sure. But for a program that started in the > late 90s and grew to add more and more features it is doing quit well. > At that time our systems where MUCH smaller. > However, the reason I answered in the first place was to show Tom that > DOS programs exist that use more then 100MB. I don't think I will ever > need more then 4GB - or even that much, but it is good to know that it > is possible. On the other hand, I never imagined I would end up using > more then 100 to 200MB in this program. > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New HiMemX version
On Sunday, January 10, 2021 10:48 AM, Eric Auer e.a...@jpberlin.de wrote: > Hi Mercury & everybody, > >> I noticed a while back that Japheth updated his HiMemX driver, and I've >> finally gotten around to packaging it up for use in FreeDOS. Also, he's made >> a new driver which can do what that HiMemX does, and more... way more. >> HiMemSX can access memory above the 4 GiB mark! I've packaged it up also, in >> case anyone (Jerome?) wants to include it in the next release or mirror it >> somewhere other than my site. Both packaged drivers can be found in [the DOS >> Downloads area at >> mercurycoding.com](http://mercurycoding.com/downloads.html#DOS). > > That implements a proposed XMS 3.5 interface to support 4 TB instead of 4 GB > of RAM, as far as I remember, with a modified version of Jack's ramdisk as > proof of concept example for what to do with so much memory. You will > probably be ready to keep > updating that package from time to time while initial glitches get fixed, Yep, he's released three versions already - I foresee a very active project. :) > but it is a good idea to already offer this as an optional (!) package to > motivate others to update drivers and apps to use the new possibilities :-) My thoughts exactly! It's not like any of us feasibly need more than 4 GiB right now, but the more people who use it on a daily basis mean more bug reports which mean a more polished product. > Compared to multithreading and 64-bit long mode projects, XMS 3.5 is very > close to normal DOS style, so making apps use it should work smoothly. I just > fail to find examples for stuff which would need so much RAM. > ... Agreed, but I wonder if it's a bit of a chicken-and-egg problem; do we have no big-time apps on DOS because DOS can't handle them or does DOS not handle them because the big-time apps don't exist? lol My point is that, perhaps if some of the underlying limitations of DOS are removed, we may see more modern apps breaths life into the aging platform.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] New HiMemX version
I noticed a while back that Japheth updated his HiMemX driver, and I've finally gotten around to packaging it up for use in FreeDOS. Also, he's made a new driver which can do what that HiMemX does, and more... way more. HiMemSX can access memory above the 4 GiB mark! I've packaged it up also, in case anyone (Jerome?) wants to include it in the next release or mirror it somewhere other than my site. Both packaged drivers can be found in the [DOS Downloads area at mercurycoding.com](http://mercurycoding.com/downloads.html#DOS). Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS runtime library format
On Tuesday, December 29, 2020 11:44 AM, Steve Nickolas usots...@buric.co wrote: > ... > I've had ideas for what I'd do if I were writing my own OS or my own DOS > clone... but they'd probably be too weird for this list. > ... But I, for one, would love to hear those ideas.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS runtime library format
First, thanks to all who replied! Good stuff. :) Also: On Monday, December 28, 2020 5:02 PM, Danilo Pecher danilo.pec...@data-experts.biz wrote: > Well, one could also question the point of shared libraries in a system that > doesn't support multitasking. > ... It's not so much a matter of multitasking, but of code re-use - ideally, there shouldn't be duplicates of certain code in each program which requires it. For example, a paint program and a video game may both need to load images/assets in various formats. It would be better, therefore, to have a standard library containing code to load and store images in a variety of formats than for the paint program and the video game both to contain code which performs the same exact function.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] DOS runtime library format
Hey, all! Just a question I've never seen addressed here - or anywhere else, for that matter. Was there ever any "official" format for a shared runtime library under MS-DOS? Windows has .DLL files, Linux has .KO files, and MS-DOS had... what, exactly? In all my years DOSsing I've never heard of anything official like this, so I'm pretty sure there was no such thing (unless you count a TSR, but that's not really what I'm after) but I figured it doesn't hurt to ask you folks, as you have more years under various flavors of DOS than I. Any constructive feedback would be appreciated! :D Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] protected mode DOS / running Windows apps
Hi there! Stas brought this project to our attention on the Night forum, but it seems the goals are too different to directly share code. On the other hand, some bits may prove useful once we get far enough into development. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, December 26, 2020 1:59 AM, TK Chia u1049321...@caramail.com wrote: > Hello 0x0d, hello Eric, > >> It's probably not, much. Night and FreeDOS-32 are both spare-time projects >> done for fun with the ultimate goal of running DOS software in 32-bit >> Protected Mode. However, I would say that Night most likely has a much more >> long-term support cycle. This isn't a research project we're working on to >> be discarded after it gets to some semblance of functionality... it will be >> developed and matured way beyond that. > > Any possibility that the Night Kernel or FreeDOS-32 can gel with the > FreeDOS-plus-plus project (https://github.com/dosemu2/fdpp)? > Basically FD++ is the 64-bit "DOS kernel" now used by the dosemu2 > project. It sits as a layer between an underlying Linux/x64 system and > dosemu2 runtime, and the DOS application programs to run. > Thank you! > --- > > https://github.com/tkchia > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] protected mode DOS / running Windows apps
On Friday, December 25, 2020 8:46 AM, Eric Auer e.a...@jpberlin.de wrote: > Hi :-) > >> Just a bit of FYI despite the project being nowhere near ready to go >> as of yet: there is a small group of us working on moving DOS into >> the 32-bit realm in the form of the NightKernel. As part ofthat journey, we >> eventually want a compatibility layer to make >> running Windows 3.x executables possible. > > How does that differ fromhttp://freedos-32.sourceforge.net/ > which is based on the assumption that running the whole kernel > in protected mode makes protected mode apps using DOS extenders > a bit faster? It's probably not, much. Night and FreeDOS-32 are both spare-time projects done for fun with the ultimate goal of running DOS software in 32-bit Protected Mode. However, I would say that Night most likely has a much more long-term support cycle. This isn't a research project we're working on to be discarded after it gets to some semblance of functionality... it will be developed and matured way beyond that. > Which barely seems to be the case, even with the > DOS extender layer inside the kernel? > Of course it can be fun to write a protected mode OS from scratch > if you like a challenge. That's a big driving force behind Night. :) > Plus dosemu / dosemu2 show that extending > DOS yourself can make it easier to run Windows 3.x. Note that this > is about running Windows itself, not about running apps FOR Windows > directly inside DOS. > For the latter, you can use the HX RT system by Japheth: > old website: https://www.japheth.de/HX.html > old version: https://sourceforge.net/projects/hx-dos/ > new version: https://github.com/Baron-von-Riedesel/HX > Happy testing :-) Eric Thanks! :)___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New packages for future releases
Just a bit of FYI despite the project being nowhere near ready to go as of yet: there is a small group of us working on moving DOS into the 32-bit realm in the form of the [Night Kernel](https://groups.google.com/g/night-dos-kernel). As part of that journey, we eventually want a compatibility layer to make running Windows 3.x executables possible. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, December 24, 2020 6:52 PM, Danilo Pecher danilo.pec...@data-experts.biz wrote: > Hi Eric, > The ReactOS/Wine combo was what got me thinking in the first place. > ReactOS was from the start meant to replicate WIndows NT though, which > isn't quite what I had in mind, as that isn't quite the 16 bit world > in which FreeDOS exists. Wine would be a starting point, as that > definitely has 16 bit remnants, like WING. Back many moons ago I used > some of that source to port Microprose's Grand Prix manager to SDL > under Linux. > My idea was more along the line of rebuilding Windows 3.11, Best > windows ever, even if Jim will probably disagree ;) > Cheers, Danilo > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS (and BIOS) references
Nice! Computer Shopper magazine (although one wonders how such a thick periodical tome could be called a "magazine" lol) used to have software called TECHHelp! back in the day containing similar information; it appears the site you mention is an online recreation of that software. Thanks for sharing! Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, December 9, 2020 5:00 PM, Aitor Santamaría wrote: > Hello, > > Incidentally I came across this DOS/BIOS reference (that I found cool > looking) and wanted to share it with you, > > [Tech Help! (dos4gw.org)](https://dos4gw.org/) > > I don't know how up-to-date it is. I know that this topic pops-up from time > to time, but I haven't heard any RBIL update for quite a while (last known > version is 61 from year 2000?). These are the sites I know to hold such kind > of information, and I was wondering if you knew of more that are worth, or > know of any that is being updated to some extent: > > RBIL - [Ralf Brown's Files (cmu.edu)](http://www.cs.cmu.edu/~ralf/files.html) > Ctyme - [Ralf Brown's Interrupt List - HTML Version > (ctyme.com)](http://ctyme.com/rbrown.htm) > (sadly, apparently Marc Perkel passed away) > [RBIL61 - HTML Edition (lod.bz)](https://fd.lod.bz/rbil/) - Bing gave this to > me, apparently there's a program called RBILtoHTML > Delorie - [Ralf Brown's Interrupt List > (delorie.com)](http://www.delorie.com/djgpp/doc/rbinter/) > > Best, > Aitor___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New Old Timer reporting :-)
Thanks! We would appreciate the help. :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, November 20, 2020 9:01 AM, tom ehlert wrote: > > But what has become a > > slow but seemingly steady stream is that there are new people > > showing up once in a while, with a whole plethora of grand ideas, > > that very quickly end up nowhere. As it seems, mostly because the > > vast majority of those doesn't understand what DOS is. And that > > seems to be part of the overall trend, where people are coming up > > with solutions for issues that people pretend to have in order to > > solve problems that nobody has... > > +1 > > maybe we should redirect these DOSIX fans to the NightDOS project > where they develop a multitasking, 32 Bit DOS clone > > /s > > Tom > > > Virus-free. www.avast.com > > > > Virus-free. I personally checked this ;) > > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] RES: HD graphics in FreeDOS ? Possible?
On Saturday, August 15, 2020 12:55 PM, Eric Auer e.a...@jpberlin.de wrote: > Hi! Hey there! > ... > >> Instead of an official FreeDOS graphics card, perhaps a standard FreeDOS >> graphics API and/or Window Manager. This would build upon the VBE by giving >> developers a handful of routines callable... > > What you describe is best implemented as a library. Usually, yes. But... > For example you do not want to search the list of VESA VBE graphics modes for > a nice true-color LFB mode, or you do not want to have to check which bit per > pixel depth is available. Then you could write a library which does that for > you, something like "specify which resolution and depth you support at least > / at most, then call the library to get the highest resolution mode in that > range" :-) Actually VESA VBE works quite well, it just is sometimes a bit > tedious to use in protected mode context such as DJGPP GNU C. Even then, you > only have to figure it out once, then enjoy ;-) Visual effects, scrolling > etc. are classic tasks for graphics libraries. The question is which classic > libraries are popular in DOS and which of them support full HD and higher > VESA modes? It is not common to put such libraries into TSR or drivers in > DOS. The usual way is to just link the library in your binary. ... if it were a TSR as opposed to this, then we eliminate the overhead incurred by including the same code in each and every application. Also, if window management features are included, a TSR opens up more possibilities for customization. For example, different flavors of this TSR could exist, each implementing a different style for drawing windows and other UI elements, allowing the user to choose which to use and enabling all the applications in use on their system which support such to maintain a consistent theme. > VESA VBE does tend to support high resolution modes, but this has a tendency > to offer mostly 4:3 and classic modes. In modern times, only OS installers > are the target audience. At present, yes. But if this capability were available, a whole new generation of apps could become available. > Modifications of graphics modes on modern hardware (think svgatextmode) can > be VERY vendor dependent and convoluted. You do not want to do that. > ... I completely agree there lol___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] RES: HD graphics in FreeDOS ? Possible?
Instead of an official FreeDOS graphics card, perhaps a standard FreeDOS graphics API and/or Window Manager. This would build upon the VBE by giving developers a handful of routines callable via interrupt to better utilize the underlying VBE code. Perhaps some useful functions would be to return the number of the largest supported screen mode of a specified bit depth, support for performing visual effects like scrolling, screen wipes and fades, drawing and manipulating windows etc. Such a thing could be encapsulated in a TSR which could then be run on demand by the user when needed for applications which support it. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, August 15, 2020 2:40 AM, Roberto Freaza wrote: > That is exactly the point. VESA is limited and not always the same. What if > we create a official FreeDOS VGA card? This will allow developers, like us, > to create much more advanced graphics software running in DOS. > > It is much more easier to do these days. Any VGA card can do 1920x1080x32 or > even more. > > What do you think? Good idea? > > De: [Mercury Thirteen via > Freedos-devel](mailto:freedos-devel@lists.sourceforge.net) > Enviado:sábado, 15 de agosto de 2020 01:15 > Para: [Technical discussion and questions for FreeDOS > developers.](mailto:freedos-devel@lists.sourceforge.net) > Cc:[Mercury Thirteen](mailto:mercury0...@protonmail.com) > Assunto: Re: [Freedos-devel] HD graphics in FreeDOS ? Possible? > > It certainly could be done using VESA. > > I believe the "official" VESA screen modes top out at 1280 x 1024, but some > VBE implementations go to 1600 x 1200 and beyond. Your game should be coded > to search the VESA modes list at startup to see what resolutions are > available on the system on which it's running. > > Perhaps some others here can recommend a good graphics library to help > interface to the VESA code. > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, August 14, 2020 10:22 PM, Roberto Freaza > wrote: > >> Hello everyone? >> >> Is it possible to create a 2D game for FreeDOS using high definition? Like >> 1920x1080? >> >> If the answer is Yes, what is the best language to complete the task? >> >> Thanks to all, >> >> Roberto___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HD graphics in FreeDOS ? Possible?
I was thinking Allegro too at first. But no, the current version does not work in DOS. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, August 15, 2020 6:14 AM, Random Liegh via Freedos-devel wrote: > For libraries, my first thought would be Allegro. But that's a game library > (if that makes any difference) and I'm not sure if the current version works > with DOS or not. > > On 8/14/2020 8:14 PM, Mercury Thirteen via Freedos-devel wrote: > >> It certainly could be done using VESA. >> >> I believe the "official" VESA screen modes top out at 1280 x 1024, but some >> VBE implementations go to 1600 x 1200 and beyond. Your game should be coded >> to search the VESA modes list at startup to see what resolutions are >> available on the system on which it's running. >> >> Perhaps some others here can recommend a good graphics library to help >> interface to the VESA code. >> >> Sent with [ProtonMail](https://protonmail.com) Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> On Friday, August 14, 2020 10:22 PM, Roberto Freaza >> [](mailto:roberto.fre...@gmail.com) wrote: >> >>> Hello everyone? >>> >>> Is it possible to create a 2D game for FreeDOS using high definition? Like >>> 1920x1080? >>> >>> If the answer is Yes, what is the best language to complete the task? >>> >>> Thanks to all, >>> >>> Roberto >> >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] HD graphics in FreeDOS ? Possible?
It certainly could be done using VESA. I believe the "official" VESA screen modes top out at 1280 x 1024, but some VBE implementations go to 1600 x 1200 and beyond. Your game should be coded to search the VESA modes list at startup to see what resolutions are available on the system on which it's running. Perhaps some others here can recommend a good graphics library to help interface to the VESA code. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, August 14, 2020 10:22 PM, Roberto Freaza wrote: > Hello everyone? > > Is it possible to create a 2D game for FreeDOS using high definition? Like > 1920x1080? > > If the answer is Yes, what is the best language to complete the task? > > Thanks to all, > > Roberto___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] stuck / forked freedos core component development!
On Friday, May 15, 2020 1:28 PM, Jim Hall jh...@freedos.org wrote: > ... > My comments/questions on a few ways we communicate: > ... My comments on your comments: :D > Email lists > https://www.freedos.org/forums/ > We obviously use the freedos-devel and freedos-user email lists. > But the freedos-kernel list is not used very much. Looking at the > archive, this hasn't seen more than a few emails per year in the > last several years. What if we retired the freedos-kernel list and > encouraged any kernel development discussion to happen on > freedos-devel? Sounds like a great idea. They're both development-related, so why not? > Facebook > https://www.facebook.com/groups/freedos/ > This is seeing a lot of discussion. I'd generally describe it as a > place where people talk about how they are using FreeDOS. Even though I don't Facebook myself, it sounds like it's enjoying some success, and very well may be the channel with the largest potential audience. Keep it. > Twitter > https://twitter.com/freedos_project > I use this pretty frequently, but usually to "broadcast" stuff > happening in FreeDOS. I tweet out any news items here as an "ICYMI" > (In Case You Missed It) and I share other FreeDOS-related news that > isn't always something worth putting on the website. For example, I > recently restarted the FreeDOS Blog, where I'm posting articles about > the videos I'm recording for the FreeDOS YouTube channel. I share > links to each blog item as I post them - but posting those links to > the website as "news items" would be too much. > > - I also share stories from people on Twitter, about FreeDOS. For > example, someone will say they've used FreeDOS for this or that thing, > and I'll retweet that. > - I also will tweet small news items from the FreeDOS Twitter account > that I wouldn't usually post on the website. Generally, when someone > announces a new project for FreeDOS (usually a game) I'll tweet about > it. If they keep making releases and it's clear the project is > actually going somewhere, that's when I'll make news items about it on > the website. It's a quick and handy way to get FreeDOS info out there. Keep it. > YouTube > https://www.youtube.com/freedosproject > I started doing weekly videos about FreeDOS. These fall into 4 categories: > > - "Using FreeDOS" - showing off things from the FreeDOS distribution > (as Robert described it, "FreeDOS in action") > - "DOS applications" - demo'ing DOS programs running on FreeDOS > (As-Easy-As spreadsheet, Word for DOS, etc.) > - "Let's play" - demo'ing DOS games running on FreeDOS (mostly > shareware and other proprietary games) > - "FreeDOS programming" - this also includes a new video series I > started for my Patreon, where I teach how to write FreeDOS programs in > C > *More info on that at https://www.freedos.org/c/ > > - There's some chat in the YouTube comments, but most of these are > about the videos themselves. I've been enjoying it, myself. :) Keep it. > Blogger > https://freedos-project.blogspot.com/ > I had been doing a lot of writing here until about a year ago. In > March, I started posting articles based on the YouTube videos. I > include more detail and background info than made it into the videos. Sounds like it's dead/dying, and we already have other platforms which offer similar functionality. Perhaps it could afford to be dropped? > DOS Ain't Dead > http://www.bttr-software.de/forum/index.php > This isn't a "FreeDOS" forum, but I follow it and re-post any > interesting announcements on the FreeDOS Twitter, or the website, > depending on topic. A classic! Keep (following) it. > And some lesser used communication channels: > Slack > I don't hang out there very often, and when I do I'm not seeing > traffic or discussion there. > > IRC > Very rare that I go there. I just went there now and there are 42 > people logged in. So maybe this is getting used, and I don't see it > because I'm not really there? > > USENET > Not much traffic to alt.os.free-dos, but looks like there's still > FreeDOS-related discussion on comp.os.msdos.programmer and > comp.os.msdos.misc. I link to all of these on the website (on the > Forums page) but maybe I shouldn't make them so prominent with the > "Join" button? > > And we also have the Wiki for documentation and other information, and > the bug tracker on SourceForge to track bugs and feature requests. > ... All of these may bear mention on the FreeDOS site, but don't need prime attention called to them. Differentiating these from the primary lines of communication would go a long way towards reducing the clutter.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freecom beep / stuck freedos core components
On Wednesday, May 13, 2020 3:33 PM, Eric Auer e.a...@jpberlin.de wrote: > ... > >> because nobody uses any FreeCOM binary younger then 2006 >> for well known reasons. > > Please shed some light on the well known reasons. +1 I never heard of any reasons. Granted I don't use FreeDOS on the daily, but I use 0.84 pre 7 on my VirtualBox VM with no issues in my basic use of it. > ...___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] [Freedos-user] HP laptop touchpad
Yes, the BIOS performs the necessary translations. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, August 10, 2019 10:10 PM, Thomas Mueller mueller6...@twc.com wrote: > From Dale E. Sterner: > >> I've had problem getting cutemouse to work on some PCs. >> Try msmouse that is what I use when cutemouse doesn't >> work. As far as usb goes check your bios setting, there is >> often a bios setting for legacy OS so you can plug stuff >> into a usb port and it converts to ps2. > > You mean you can plug a USB mouse (or keyboard?) into a USB port, with no > hardware adapter, and FreeDOS will see it as PS/2? > Tom > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS is 25 years old
And we thank YOU! It's pretty cool to see what passion for a platform can do, despite the majority of the modern computing world considering it dead. Great work, and may it continue growing! Btw... Nice guest appearance on the [Lunduke Show](https://www.youtube.com/watch?v=-ib9HLHeNfI)! On Sunday, June 30, 2019 6:33 PM, Jim Hall wrote: > FreeDOS has now been around for 25 years. That's a major milestone for > anything, especially an open source software project. > > I just wanted to say THANK YOU to everyone in the FreeDOS community - past > and present. Open source software is about people coming together to work on > something, and that's you. If I ever meet any of you in person, I'll buy you > a beer/beverage. > > And it's great that our community remains so positive. So THANKS for helping > keep out the trolls. > > I'm looking forward to FreeDOS 1.3! :-) > > Jim___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Application to check DOS API compatibility
Thanks! I've never seen this program, but methinks it shall be very useful. On Saturday, June 8, 2019 10:31 AM, TK Chia u1049321...@caramail.com wrote: > Hello Rugxulo, hello Mercury 13, > >> Of course, you could just always rather test the "big dogs" of the DOS >> world: Turbo C, Lotus 1-2-3, Doom, QBASIC, etc I don't know of a >> good list of tools off-hand, but obviously things like DJGPP or >> OpenWatcom or FASM (or maybe small *nix utils like sed) might make for >> good tests. > > I think Spinellis's system call tracer > (https://www.spinellis.gr/sw/ports/trace/) might be a good adjunct to > such test programs. It can help give an idea of the DOS system calls > which are covered by a particular run of a program. > However, the tracer does not handle calls to the BIOS, even though the > BIOS is also quite an important part of the ABI for DOS programs. > Thank you! > --- > > https://github.com/tkchia > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Application to check DOS API compatibility
Darn. I was hoping that, in light of the early MS-DOS clone market, there was something maybe released by a third party to help users determine if their DOS was MS-DOSsy enough. A reach, I know, but... oh, well. If I end up making one, I'll certainly share! :) Night is coming along well so far, and I'm trying my best to minimize slipping the development schedule. Hopefully we'll be on track next year to start test-running the first small .COM executables before later moving on to EXE and even ELF binaries. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, June 1, 2019 3:18 PM, Jim Hall wrote: > Not that I'm aware of. Such a thing has never really been needed, since > MS-DOS was always the gold standard, and Microsoft set the goalposts for most > of DOS history. A "compatibility check" tool would have had to come out of > Microsoft, but I can't see they would have been motivated to create a product > to help others create competing DOS implementations. > > Would be neat, though. If you write a tool to do this, please share it. You > can use the RBIL as the basis for DOS interrupts. > > I assume the NightDOS kernel is doing well, then? > https://groups.google.com/forum/#!topic/night-dos-kernel/PaPrNIvVWyo > > On Sat, Jun 1, 2019 at 2:08 PM Mercury Thirteen via Freedos-devel > wrote: > >> Hello all, >> >> Ultimately, I'm looking for an application which can probe the DOS function >> calls on a given system and report how "compatible" the current system is, >> perhaps presenting a list of what DOS functions have successfully returned >> legitimate output. E.g. "Your DOS implementation supports interrupt >> functions X and Y but not Z." >> >> I understand that in reality there may be no application which does exactly >> this... but perhaps in all of the collective knowledge here someone knows of >> a program to do something close? Thanks in advance! >> >> Sent with [ProtonMail](https://protonmail.com) Secure Email. >> >> ___ >> Freedos-devel mailing list >> Freedos-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-devel___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Application to check DOS API compatibility
Hello all, Ultimately, I'm looking for an application which can probe the DOS function calls on a given system and report how "compatible" the current system is, perhaps presenting a list of what DOS functions have successfully returned legitimate output. E.g. "Your DOS implementation supports interrupt functions X and Y but not Z." I understand that in reality there may be no application which does exactly this... but perhaps in all of the collective knowledge here someone knows of a program to do something close? Thanks in advance! Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeCOM 0.84-pre5 prerelease
AFAIK, VT-X is basically hardware-level support for virtualization and it does help noticeably. Without it, the VM hypervisor must do all that work in software. It kinda works like hardware acceleration for graphics in a video card. There's my two cents lol Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On August 22, 2018 4:03 PM, Rugxulo wrote: > Hi, > > On Wed, Aug 22, 2018, 7:07 AM Tom Ehlert wrote: > >> as a side note: I have no experience with UNZIP.EXE in DOS, but I think it's >> performance pathetically slow. is this normal? > > Under VM? Yes, "unzip" is specifically known to be much slower than normal. > I'm not exactly sure why. Like I always say, VT-X helps a ton. > >>-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Decompressing the FreeDOS kernel
Aha! Alright, that explains it, then. Thank you! Sent from ProtonMail mobile Original Message On Jul 10, 2018, 10:33 AM, TK Chia wrote: > Hello Mercury 13, > > Yes, the FreeDOS kernel is compressed with UPX --- but there are some > preprocessing and postprocessing steps done to the uncompressed kernel > code, before and after it is passed through UPX. > > Bart Oldeman's utils/exeflat.c program in the kernel sources is > responsible for doing these processing steps and wrapping the call to UPX. > > I think it _might_ be feasible to write a program to reverse what > utils/exeflat.c does, to allow UPX to decompress the image, though of > course this will need some work. Part of the reversal process will > involve restoring the .exe header and relocation(s) which were created > by UPX and removed by exeflat. > > (Anyway, I think compressing programs is useful, if FreeDOS is likely to > be used in resource-constrained situations. Floppy disks were not only > slow --- they also had quite limited capacity. (-: ) > > Thank you! > > -- > https://github.com/tkchia/ > > On 07/10/2018 03:18 PM, Mercury Thirteen via Freedos-devel wrote: >> I agree... not sure why the FreeDOS kernel folks felt that was necessary. >> Maybe a size limitation of the bootloader? >> >> Sent from ProtonMail mobile >> >> ---- Original Message >> On Jul 10, 2018, 12:47 AM, Ralf Quint wrote: >> >>> On 7/9/2018 7:43 PM, Mercury Thirteen via Freedos-devel wrote: >>>> So, I've been looking into de-UPXing the kernel image and keep getting >>>> told by the UPX binary that the image "wasn't compressed by UPX". Is >>>> there anything special I have to do to convince it otherwise? Was the >>>> kernel in fact not compressed by UPX? I'm using the latest UPX on >>>> Linux Mint 19, if that helps. >>> What would be the purpose of using UPX today? It made kind of sense back >>> in the days of slow data media (floppy disks) but nowadays, there just >>> isn't IMHO any valid reason to do that anymore. >>> >>> Ralf >>> >>> --- >>> This email has been checked for viruses by Avast antivirus software. >>> https://www.avast.com/antivirus >>> >>> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! >>> http://sdm.link/slashdot;>http://sdm.link/slashdot;>[http://sdm.link/slashdot](>> href=)">http://sdm.link/slashdot >>> ___ >>> Freedos-devel mailing list >>> Freedos-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freedos-devel;>https://lists.sourceforge.net/lists/listinfo/freedos-devel;>[https://lists.sourceforge.net/lists/listinfo/freedos-devel](>> href=)">https://lists.sourceforge.net/lists/listinfo/freedos-devel >>> >>> >>> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! >>> http://sdm.link/slashdot;>http://sdm.link/slashdot;>[http://sdm.link/slashdot](>> href=)">http://sdm.link/slashdot >>> >>> >>> ___ >>> Freedos-devel mailing list >>> Freedos-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freedos-devel;>https://lists.sourceforge.net/lists/listinfo/freedos-devel;>[https://lists.sourceforge.net/lists/listinfo/freedos-devel](>> href=)">https://lists.sourceforge.net/lists/listinfo/freedos-devel > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! > http://sdm.link/slashdot;>http://sdm.link/slashdot;>[http://sdm.link/slashdot]( href=)">http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel;>https://lists.sourceforge.net/lists/listinfo/freedos-devel;>[https://lists.sourceforge.net/lists/listinfo/freedos-devel]( href=)">https://lists.sourceforge.net/lists/listinfo/freedos-devel-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Decompressing the FreeDOS kernel
I agree... not sure why the FreeDOS kernel folks felt that was necessary. Maybe a size limitation of the bootloader? Sent from ProtonMail mobile Original Message On Jul 10, 2018, 12:47 AM, Ralf Quint wrote: > On 7/9/2018 7:43 PM, Mercury Thirteen via Freedos-devel wrote: >> So, I've been looking into de-UPXing the kernel image and keep getting >> told by the UPX binary that the image "wasn't compressed by UPX". Is >> there anything special I have to do to convince it otherwise? Was the >> kernel in fact not compressed by UPX? I'm using the latest UPX on >> Linux Mint 19, if that helps. > What would be the purpose of using UPX today? It made kind of sense back > in the days of slow data media (floppy disks) but nowadays, there just > isn't IMHO any valid reason to do that anymore. > > Ralf > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Decompressing the FreeDOS kernel
So, I've been looking into de-UPXing the kernel image and keep getting told by the UPX binary that the image "wasn't compressed by UPX". Is there anything special I have to do to convince it otherwise? Was the kernel in fact not compressed by UPX? I'm using the latest UPX on Linux Mint 19, if that helps. Thanks in advance! Sent with [ProtonMail](https://protonmail.com) Secure Email.-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit DOS
On July 8, 2018 1:42 PM, Ercan Ersoy wrote: > Hello, > > Can PDOS run programs that are run with CWSDPMI (for exmaple DJGPP)? > > Can NightDOS run programs that are run with CWSDPMI (for exmaple DJGPP)? > > Best regards, > > Ercan Hi Ercan, The Night kernel will eventually have its own DPMI interface to allow running of programs which require a DOS extender, and will also be able to run 32-bit console Windows and Linux binaries as well. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Ideas
I, for one, would personally love to see FreeQB. Even if it only converted BASIC to assembly and relied on NASM for compiling, it would be a welcome addition to the FreeDOS family. The language could even be extended with several features found in other BASICs, such as PowerBASIC. I began a BASIC compiler for a different project years ago and still have the source code lying around if anyone would be interested. I would be willing to assist on such a project as my free time allows. Chelson and his team was working on the [DOSCore](http://www.doscore.net/doscore/home.html) project a while back which gave a GUI for DOS based systems. I thought it was listed on the FreeDOS site, but I don't see it there now... The calculator would be a nice accessory. I made a set of routines in the early 2000s which allow mathematical operations on very large numbers by treating them as strings and processing them one digit at a time (as one would do manually) which might be useful for such a project, again if someone is interested in taking up such a project. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On July 6, 2018 4:34 AM, Ercan Ersoy ercaner...@ercanersoy.net wrote: > Hello, I have a few ideas. > FreeQB: > FreeQB is replacement for Microsoft QBASIC. FreeQB is > QBASIC.EXE for FreeDOS and compatible QBASIC. It may > run 8086 and low memory. This software may be written > write C++ and FDOSTUI Library. > FreeDOS Calculator: > A calculator for FreeDOS. This software may be written > C++ and FDOSTUI Library. > FreeDOS Control Panel: > This control panel may provide FreeDOS management settings > (display, sound, network etc.). This software may be > writtten using C++ and FDOSTUI Library. > A Graphical Shell for FreeDOS: > This graphical shell may provides using FreeDOS easily. > This software may be written using FreeBASIC or C++ (DJGPP). > It may requires 80386, graphic card and CWSDPMI. > FreeDOS Markdown Help System: > FreeDOS help documents may be rewritten via Markdown and > translated many languages. FreeDOS Written Help System > may be written easily than FreeDOS HTML Help System. > What do you think about these ideas? > Thanks for replies, > Ercan > --- > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] 32-bit DOS
Interesting you should mention this; I and a few others have been working on a 32-bit Protected Mode DOS-style kernel (see the Night group forum [here](https://groups.google.com/forum/?hl=en#!forum/night-dos-kernel) for more info) for a while now. While I never got too deep into DPMI (and therefore don't know how much help I would be to you) I'm interested in taking a look at your project. Since it seems we have a similar goal, maybe there's a nugget or two of info that can be shared to help both projects along. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On July 6, 2018 7:54 PM, Paul Edwards wrote: > Hi. About 30 years ago, someone made a comment > on a group saying "until DOS is made 32-bit, DOS > extenders are just a kludge". > > I didn't know much about DOS-specifics back then > to even understand the comment. > > Microsoft abandoned the MSDOS API, but what > would a 32-bit version of the MSDOS API look > like if they hadn't abandoned it? > > Since 1994, off and on, I have been working on > PDOS/386, which is designed to be a 32-bit > version of MSDOS/Freedos. > > I have recently just completed relocation of OS > and app so that they can both run in a flat address > space, meaning that applications can directly > manipulate the hardware, e.g. by going > *(char *)0xb8000 = 'X'; > With that change now in place, it is working to > my satisfaction technically (I want to return to > the days when blindingly fast applications could > be written by manipulating the hardware), and > I would like to solidify the API. What would a > 32-bit MSDOS API ideally look like? My current > thinking is that both int86() and some wrapper > functions should be made available, which I > have already done here: > > https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/pos.h > > Note that this is all working, but I am interested > in tweaking the design/interface before lots of > 16-bit MSDOS programs get ported to 32-bit, so > I am open to suggestions. E.g. I was thinking > that the PosAllocMem() should instead be put > on a different AH code and take extra parameters, > mainly a "location" which can be set to 20 to > request memory in the first 1 MiB, or 32 for the > full 4 GiB space, and in the future support 64. > > PDOS/386 is explicit public domain (no license) > and written mostly in C, with a bit of assembler. > The way it works is that the OS and apps are > pure 32-bit protected mode, but when a service > like reading from disk is required, it converts the > protected mode BIOS interrupt into a real mode > interrupt. This conversion to real mode is > transparent to the OS and apps. > > As a test, I tried porting micro-emacs from 16-bit > DOS to 32-bit DOS, and very few changes were > required. He was previously writing to the screen > buffer at 0xb8000 using an "int *" and I needed > to change that to "short *". I was thinking that > all the Freedos utilities could be similarly ported > so that I don't need to rewrite everything. > > I don't need any code written. I just need peer > review of the design/API. Hopefully someone > can offer some opinions. > > Thanks. Paul.-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] VGA/VESA vblank interrupt?
Enabling VSync should take care of tearing; I think the VESA spec has a way to enable that feature internally without you writing code for it. Also, proper double buffering will go a long way towards eliminating tear and flicker. Sent from ProtonMail mobile Original Message On Jul 3, 2018, 10:56 AM, TK Chia wrote: > Hello Mr. Bertho, > > Thanks for the tips. However, I suspect that knowing when exactly > vertical retraces occur is still relevant to modern monitors (and OSes), > where one needs to prevent "screen tearing" and other nasty artefacts. > So I would think it is still useful to know how to do it right. > > Thank you! > -- > https://github.com/tkchia > > On 07/01/2018 09:45 PM, Bertho Grandpied via Freedos-devel wrote: >> On Sat, 30 Jun 2018 ,David McMackins wrote : >> >> > Anyway, I'm figuring out VGA and VESA graphics programming, but one >> > thing I can't find is how to wait for an interrupt to tell me when the >> > vblank period starts so that I can vsync. >> >> The vertical interrupt was indeed part of IBM's >> original video systems for the PC (MDA,CGA, >> EGA), up to and including the original VGA for >> the PS/2, but don't count on it on any modern >> VGA,SVGA, etc (in-)compatibles ! The main use >> for monitoring that interrupt (where available) was >> in order to avoid so-called "snow" effects, but that >> would be before fast, dual-ported "VRAM" were >> introduced. There is no need to coordinate >> video memory accesses to/from CPU and the >> video adapter any more; the only remaining use >> for hooking vertical retrace I can think of is >> in order to measure vertical retrace frequencies, >> and that doesn't require the interrupt - simply poll >> the V-retrace bit = bit 3 at input port 3DAh >> (or 3BA in B/W mono). >> >> Anyway... if your, presumably very old, VGA card >> did support the Vertical interrupt, it should be routed >> as IRQ 9, interrupt #71h, on an AT-compatible (IRQ 2 >> on an original PC or PC/XT). On the EGA/VGA, you'd >> have to ENABLE that V-retrace interrupt explicitly, >> by REsetting bit 5 of the CRTC register #11h, and >> then hook the HW interrupt in your programme, of >> course. >> >> In any case you are welcome to try your HW for >> generating that interrupt, using the preceding indications, >> there are no risks in testing IMHO : but there is >> also very little chance of success on any PC video >> system less than 25 yrs old :=) >> >> HTH anyway, and happy hackings >> > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] VGA/VESA vblank interrupt?
[This page at OSDev](https://wiki.osdev.org/VGA_Hardware) has lots of details on the VGA system. I believe you can poll the registers to determine the blanking period; I don't recall VGA supporting interrupts for this. But I could be wrong. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On June 30, 2018 10:00 PM, David McMackins cont...@mcmackins.org wrote: > I'm new to graphics programming on DOS. My experience programming > graphics on PC is on modern systems where I can use a library that > handles all low-level calls for me. I know about Allegro, but it's kind > of fat and I don't think it supports 16-bit. > Anyway, I'm figuring out VGA and VESA graphics programming, but one > thing I can't find is how to wait for an interrupt to tell me when the > vblank period starts so that I can vsync. On the Game Boy, for instance, > there is a flag you can set which enables certain interrupts from the > hardware, and you specify a function to be called on those interrupts. > One of these is the vblank interrupt, which gets thrown once every frame > so that the program knows when it is safe to draw. > All the tutorials I can find online just use a while loop to constantly > poll for the vblank state, but that seems very inefficient and could > make it cumbersome to consider other types of interrupts. > Surely there is a way, but I don't know where to look. Also, what about > interrupts for mouse movement, etc.? Where is a good place to learn > about this kind of thing, or perhaps a book to recommend? > Happy Hacking, > David E. McMackins II > Supporting Member, Electronic Frontier Foundation (#2296972) > Associate Member, Free Software Foundation (#12889) > www.mcmackins.org www.delwink.com > www.eff.org www.gnu.org www.fsf.org > --- > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: I'd like an absolute minimal version of FreeDOS.
My thoughts exactly! On 6/15/2016 8:56 PM, Jayden Charbonneau wrote: Time to program with the delete key then. (Pun) On Wed, Jun 15, 2016 at 8:13 PM, Mercury Thirteen <mercury0x0...@gmail.com <mailto:mercury0x0...@gmail.com>> wrote: Yep, the bootloader and a FreeDOS kernel with the boot message removed. Problem solved. :) On 6/15/2016 6:57 PM, Jayden Charbonneau wrote: I may be wrong on this,but couldn't we just strip down the code used for FreeDOS?Removing un-needed modules,drivers,and removing any COUT/PRINTF statements to the point where it's just the kernel itself should do it. On Wed, Jun 15, 2016 at 4:25 AM, Maarten Vermeulen <netraa...@gmail.com <mailto:netraa...@gmail.com>> wrote: I think that can be done right? If we are finished with 1.2, then we (or some of us) can make it. Unless, nobody wants to do such thing. So, yeah I am volunteering. but it still needs an under layer right (for running programs)? Maarten -- 2016-06-15 9:23 GMT+02:00 Eric Auer <e.a...@jpberlin.de <mailto:e.a...@jpberlin.de>>: >From Ben Hutchinson <benh...@gmail.com <mailto:benh...@gmail.com>> By minimal, I mean that the boot sector program, and the kernel (kernel.sys), don't do any displaying of text. All they need to do is set up the DOS interrupt vectors (so that they behave correctly just as with MS-DOS), and then load and execute the first file, command.com <http://command.com>. No displaying text at all. The screen should remain blank until something in command.com <http://command.com> causes text or graphics to display. Such an absolute minimal version of FreeDOS would be useful for me, because it would allow me to write my own program in assembly language, call it command.com <http://command.com>, and then copy that file to the disk, and use it to boot another computer directly into the software I've written. This minimal version of FreeDOS would be just a boot-loader for my own OS-level software, a launch-point for my application (my application existing in place of an OS, rather than being run from an OS), that would then run upon booting. Project founder and developer of BirdOS by FeatherCode -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net <mailto:Freedos-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freedos-devel -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net <mailto:Freedos-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freedos-devel -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Endorsements: AMD, ATI, BirdOS, eBid.net - A great eBay replacement which doesn't habitually screw over its sellers, FreeDOS, Motorola - Maker of the legendary 68K instruction sets architecture, MSI, Night DOS Kernel, Samsung, Subaru - The most capable AWD ever!, Trump 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveal
Re: [Freedos-devel] Fwd: I'd like an absolute minimal version of FreeDOS.
Yep, the bootloader and a FreeDOS kernel with the boot message removed. Problem solved. :) On 6/15/2016 6:57 PM, Jayden Charbonneau wrote: I may be wrong on this,but couldn't we just strip down the code used for FreeDOS?Removing un-needed modules,drivers,and removing any COUT/PRINTF statements to the point where it's just the kernel itself should do it. On Wed, Jun 15, 2016 at 4:25 AM, Maarten Vermeulen <netraa...@gmail.com <mailto:netraa...@gmail.com>> wrote: I think that can be done right? If we are finished with 1.2, then we (or some of us) can make it. Unless, nobody wants to do such thing. So, yeah I am volunteering. but it still needs an under layer right (for running programs)? Maarten -- 2016-06-15 9:23 GMT+02:00 Eric Auer <e.a...@jpberlin.de <mailto:e.a...@jpberlin.de>>: >From Ben Hutchinson <benh...@gmail.com <mailto:benh...@gmail.com>> By minimal, I mean that the boot sector program, and the kernel (kernel.sys), don't do any displaying of text. All they need to do is set up the DOS interrupt vectors (so that they behave correctly just as with MS-DOS), and then load and execute the first file, command.com <http://command.com>. No displaying text at all. The screen should remain blank until something in command.com <http://command.com> causes text or graphics to display. Such an absolute minimal version of FreeDOS would be useful for me, because it would allow me to write my own program in assembly language, call it command.com <http://command.com>, and then copy that file to the disk, and use it to boot another computer directly into the software I've written. This minimal version of FreeDOS would be just a boot-loader for my own OS-level software, a launch-point for my application (my application existing in place of an OS, rather than being run from an OS), that would then run upon booting. Project founder and developer of BirdOS by FeatherCode -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net <mailto:Freedos-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/freedos-devel -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Endorsements: AMD, ATI, BirdOS, eBid.net - A great eBay replacement which doesn't habitually screw over its sellers, FreeDOS, Motorola - Maker of the legendary 68K instruction sets architecture, MSI, Night DOS Kernel, Samsung, Subaru - The most capable AWD ever!, Trump 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: I'd like an absolute minimal version of FreeDOS.
It sure can :) The most straightforward way I can think of to do this would be to use eliminate everything from FreeCOM on up. This would leave you with the FreeDOS bootloader and kernel.sys. Kernel.sys seems to only need command.com, so whatever you make could load in its place right there, also named command.com. Kernel.sys would then need patched or recompiled to remove the simple boot message. On 6/15/2016 4:25 AM, Maarten Vermeulen wrote: I think that can be done right? If we are finished with 1.2, then we (or some of us) can make it. Unless, nobody wants to do such thing. So, yeah I am volunteering. but it still needs an under layer right (for running programs)? Maarten -- 2016-06-15 9:23 GMT+02:00 Eric Auer <e.a...@jpberlin.de <mailto:e.a...@jpberlin.de>>: >From Ben Hutchinson <benh...@gmail.com <mailto:benh...@gmail.com>> By minimal, I mean that the boot sector program, and the kernel (kernel.sys), don't do any displaying of text. All they need to do is set up the DOS interrupt vectors (so that they behave correctly just as with MS-DOS), and then load and execute the first file, command.com <http://command.com>. No displaying text at all. The screen should remain blank until something in command.com <http://command.com> causes text or graphics to display. Such an absolute minimal version of FreeDOS would be useful for me, because it would allow me to write my own program in assembly language, call it command.com <http://command.com>, and then copy that file to the disk, and use it to boot another computer directly into the software I've written. This minimal version of FreeDOS would be just a boot-loader for my own OS-level software, a launch-point for my application (my application existing in place of an OS, rather than being run from an OS), that would then run upon booting. Project founder and developer of BirdOS by FeatherCode -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Endorsements: AMD, ATI, BirdOS, eBid.net - A great eBay replacement which doesn't habitually screw over its sellers, FreeDOS, Motorola - Maker of the legendary 68K instruction sets architecture, MSI, Night DOS Kernel, Samsung, Subaru - The most capable AWD ever!, Trump 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421=/41014381___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] An idea???
I was gonna GitHub it, but this <https://www.dropbox.com/s/ga535hsby0zkleh/Exelyx%20kernel.7z?dl=0> will work just as well for something that's not under active development. Let me know if you have questions! On 2/19/2016 5:14 PM, Maarten Vermeulen wrote: “Anyway, my shell project (as of my last firing it up a couple years ago) basically launches, (..)I still have the Watcom source around if you want to check it out or use it as a starting base.” Give me!!! :p Seriously though… you know what to do ;) Working on: Bird OS 2017 1.0.0a (western screech-owl) - netraa...@gmail.com - birdos.2...@gmail.com "why? Because Freedos, that's why!" Some Nice projects: - Freedos - Night DOS Kernel *Van: *Mercury Thirteen <mailto:mercury0x0...@gmail.com> *Verzonden: *vrijdag 19 februari 2016 05:51 *Aan: *Technical discussion and questions for FreeDOS developers. <mailto:freedos-devel@lists.sourceforge.net> *Onderwerp: *Re: [Freedos-devel] An idea??? This was my intent for many years. Eventually I shelved the project because it a shell simply can't do all I wanted it to; I needed to go more low-level for that. At its heart, DOS (MS-, IBM-, Free- or otherwise) is a single tasking OS. What this means is that you /can/ make a shell program to replace the command interpreter but when you launch a program, everything else stops until that program exits. This kinda breaks the functionality which one may think putting a shell atop DOS would achieve. If you're basically making a file manager, then that's quite doable and you'd basically end up with a Windows 3.x clone. Well, I shouldn't say /clone/ per se, because I hope you'd give it a much better interface than that of that eyesore. In theory you could develop small apps (and even run them multitasked) for a shell. Basically you'd include in your shell a rudimentary virtual machine which would execute bytecode a'la Java. What this bytecode would be is completely up to you. Do you make a custom bytecode which is powerful and compact yet not understood by any existing development tools out there? Do you make the bytecode basically a direct ripoff of the x86 instruction set, enabling you to run small programs compiled by anything from NASM to QuickBASIC? Do you say screw it and just make a whole new kernel which will handle all this fanciness at a hardware level as it was meant to be? These are all issues you'd have to address if you took this route. Granted, the virtual machine approach would require /lots/ of patience and time to implement, but it can be done. Don't ask me how I know lol Anyway, my shell project (as of my last firing it up a couple years ago) basically launches, does some environment probing, sets up some structures and then sits in a loop where you can access a menu and test out the various features and such. There's code for handling VESA mode switching, drawing in and manipulating off-screen memory buffers known as pixmaps, text string manipulation, mouse polling, direct LBA disk access and even the tiny beginnings of PCI bus probing. I still have the Watcom source around if you want to check it out or use it as a starting base. So far as your question, a 16-bit shell can load whatever graphics formats it's been programmed to handle. The biggest hang-up to doing so is the screen mode situation under DOS. There's a good chance you're going to want graphics which don't look blocky and colors depth beyond 256. If that's true, then your code needs to use VESA. Doing so gives you access to smooth animation, millions of colors and high resolutions (up to 1600 x 1200, I believe), all of which you normally can't have under plain DOS. I have 16-bit code (some written from scratch, some retooled from public domain works) to load and save images in jpg, bmp, pcx, gif (and a few other) formats. Although it's not all been ported to Watcom as of yet, it may come in handy for you as well. Images can be quite large and working with them can therefore involve large amounts of data, so I would definitely recommend using speedy 32-bit Watcom code (and the access-to-gobs-of-memory associated with it) for this kind of work. Others have given many nice examples of DOS GUI software but I didn't see Qube <http://www.osnews.com/story/75/Enter_the_Qube_a_New_Graphics_Environment_for_CLI_OSes> mentioned. I'm not sure if it was ever released or whatever, but I think it certainly is a nice looking addition to the list. Make your shell sport an interface like that, and you just may have something. :) Also, our own Chelson works on DOSCore (formerly OZone, I believe), so he may be a valuable resource to you as well. Small world, eh? Personally, while I may not use a GUI much for my DOS needs, I still think it would be nice to see FreeDOS get this addition because... well, you know why. ;) On 2/17/2016 3:19 PM, Maarten Vermeulen wrote: Hi all, It’s not really a
Re: [Freedos-devel] An idea ???
On 2/19/2016 6:06 PM, Jose Antonio Senna wrote: ... Or you could do something like DesqView, as was discussed in this list sometime ago. In short, use the timer interrupt to swap between processes, swapping all their environment at the same time. To give an idea of the amount of work involved, DesqView size is about 200 kbytes. JAS This is a great idea. Basically, it would be like the old DOS utility Memory Shift, which incidentally inspired Andy Hertzfeld to create a little utility called "Switcher" for the Mac to do this same job on that platform before the MultiFinder came along. Perfect! The minimalist nature of DOS would easily lend itself to making something like that work and work fairly well. -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump / Cruz 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] An idea???
aarten -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump / Cruz 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI and FreeDOS 1.2
+1 On 1/26/2016 2:54 PM, Maarten Vermeulen wrote: Hi, I should leave BWBASIC right where it is. As it's for programming and DEVELOPING. As it's devloper stuff I would leave it in "devel". It makes no sense to put a devloping part from developing to the basic system part. Leave it with his brothers (ASM and C). :) Maarten -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump / Cruz 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI and FreeDOS 1.2
It's a way of saying I agree with what you said. On 1/26/2016 3:04 PM, Maarten Vermeulen wrote: What's the meaning of "+1"?! Van: Mercury Thirteen <mailto:mercury0x0...@gmail.com> Verzonden: 26-1-2016 21:03 Aan: Technical discussion and questions for FreeDOS developers. <mailto:freedos-devel@lists.sourceforge.net> Onderwerp: Re: [Freedos-devel] FDI and FreeDOS 1.2 +1 On 1/26/2016 2:54 PM, Maarten Vermeulen wrote: Hi, I should leave BWBASIC right where it is. As it's for programming and DEVELOPING. As it's devloper stuff I would leave it in "devel". It makes no sense to put a devloping part from developing to the basic system part. Leave it with his brothers (ASM and C). :) Maarten -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump / Cruz 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump / Cruz 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI and FreeDOS 1.2
On 1/26/2016 6:18 PM, Eric Auer wrote: ... Jerome, regarding the packages which are part of the ALL choice: The list seems suspiciously SHORT to me! We had a lot more to offer in older FreeDOS distros when people selected "ALL". Unless things got dropped from Mateusz' repository, I would keep including them all. ... Yeah, I'm certain there were many more packages when I went through/updated every single one for the ISO I put together months ago. Not sure which ones are missing off the top of my head though. -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump / Cruz 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI and FreeDOS 1.2
On 1/26/2016 7:07 PM, Jerome Shidel wrote: Yes, there are many more packages on his repo. But, I don't think Jim wants everything on his repo to be installed when the user selects ALL. His repo contains about 500mb of zip files. The current USB stick image that only contained packages for BASE and ALL was about 75MB. A lot of which was FPC and OW. Ahh, ok I see. :) -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump / Cruz 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDI and FreeDOS 1.2
On 1/22/2016 4:24 PM, Tom Ehlert wrote: I emailed with Jim the other day. He is extremely busy at present. fine. we should look for a new boss with more time to care. Now, if Jim were to willingly appoints someone else to take his place, that's a different story entirely, but I can't imagine a more appropriate person to be the "boss" since he is, after all, the *founder* of FreeDOS. It's not ours to pull his project out from under him. what package for drivers? maybe ask Jim Tom -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- *This has been a Mercury Thirteen transmission.* /"Why? Because *FreeDOS*, that's why."/ Things I endorse: AMD ATI eBid.net - A great eBay replacement which doesn't habitually screw over its sellers! :) FreeDOS Samsung Subaru - The most capable AWD ever! Trump 2016 - Make America great again! I promote these things because awesomeness and excellence deserve recognition, not for personal gain of any kind. -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] A little message
Why did he do it? because FREEDOS! :D On 12/31/2015 7:44 PM, JAYDEN CHARBONNEAU wrote: Yeah.I used FreeDOS to hack the Matrix to access the webcam.Hahah. :) On Dec 31, 2015 6:39 PM, "Maarten Vermeulen" <netraa...@gmail.com <mailto:netraa...@gmail.com>> wrote: It is 1 january here (00:36). So happy new year :) The time in the Netherlands is about 6 hours later then in New York. Maarten Van: JAYDEN CHARBONNEAU <mailto:jcharbonnea...@cpsge.org> Verzonden: 1-1-2016 00:14 Aan: Technical discussion and questions for FreeDOS developers. <mailto:freedos-devel@lists.sourceforge.net> Onderwerp: Re: [Freedos-devel] A little message See you guys next year! (Hah...hah..hah?) On Dec 31, 2015 10:29 AM, "Mercury Thirteen" <mercury0x0...@gmail.com <mailto:mercury0x0...@gmail.com>> wrote: Then a happy New Year to all those of us who are still stuck in last year! :P :) On 12/31/2015 9:39 AM, Mateusz Viste wrote: > I fear you are slightly too late - there are many places in the world > where it's 2016 already - Most of Australia, some parts of Russia, New > Zealand, and a few more. :) > > Mateusz > > > > On 31/12/2015 15:09, JAYDEN CHARBONNEAU wrote: >> Yes,tonight is New Years Eve!Stay up late!Party!Watch the balldrop!I you >> all have a wonderful (and crazy) evening! >> >> -Jayden >> >> *Crazy meaning have a fun party >> >> On Thu, Dec 31, 2015 at 2:52 AM, Maarten Vermeulen <netraa...@gmail.com <mailto:netraa...@gmail.com> >> <mailto:netraa...@gmail.com <mailto:netraa...@gmail.com>>> wrote: >> >> And a happy new year! :) >> >> >> >> Van: JAYDEN CHARBONNEAU <mailto:jcharbonnea...@cpsge.org <mailto:jcharbonnea...@cpsge.org>> >> Verzonden: 26-12-2015 16:07 >> >> Aan: Technical discussion and questions for FreeDOS developers. >> <mailto:freedos-devel@lists.sourceforge.net <mailto:freedos-devel@lists.sourceforge.net>> >> Onderwerp: Re: [Freedos-devel] A little message >> >> I recently got my band director to let us play Sleigh Ride.The >> trumpets enjoyed making the horse noises. >> On Dec 26, 2015 3:19 AM, "Maarten Vermeulen" <netraa...@gmail.com <mailto:netraa...@gmail.com> >> <mailto:netraa...@gmail.com <mailto:netraa...@gmail.com>>> wrote: >> > >> > For those who like it, a Dutch christmas song. >> > 'midden in de winternacht' it's name. This is one of the first >> christmas songs you learn in dutch, because this one is always used >> on school. >> > >> > So here is it, 'midden in de winternacht'. >> > >> > https://m.youtube.com/watch?v=lOyEmKJozc0 >> > >> > Of course you are allowed to use google translate :) >> > >> > Van: Rugxulo >> > Verzonden: 26-12-2015 06:09 >> > Aan: Technical discussion and questions for FreeDOS developers. >> > Onderwerp: Re: [Freedos-devel] A little message >> > >> > Hi, >> > >> > On Fri, Dec 25, 2015 at 12:37 PM, Maarten Vermeulen >> <netraa...@gmail.com <mailto:netraa...@gmail.com> <mailto:netraa...@gmail.com <mailto:netraa...@gmail.com>>> wrote: >> > > >> > > Yes thanks! Everyone have a merry christmas! >> > > Good luck with your familly! :P >> > >> > What, no Dutch translation? :-O >> > >> > "Gelukkig Kerstfeest!" (according to https://translate.google.com) >> > >> > (And the German ...) &g
