Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

2022-08-25 Thread tom ehlert
Hallo Herr Paul Dufresne via Freedos-devel, am Donnerstag, 25. August 2022 um 15:41 schrieben Sie: > >>it's still beyond my understanding why you don't want to edit small >>files with edit32 >> >> Tom > Well, because the full idea is more like: > If file < 64k > then edit.exe the file els

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

2022-08-25 Thread tom ehlert
Hi Robert, >>> But there are many good (and free) >>> text editors available for DOS that can edit large text. >> >> True enough. and people have had time enough (it's 2022) to select one > Not everbody is with DOS since the 1980s. There are still DOS newbies > around from time to time. welcome.

Re: [Freedos-devel] MKEYB layout suggestion

2022-09-29 Thread tom ehlert
> I do not know if you have either the time or interest in this. definitively neither. just because some random guy on the internet proposes a new keyboard layout doesn't mean it should be implemented anywhere. remeber the Dvorak keyboard layout and it's phenomenal success? > I just wanted to p

Re: [Freedos-devel] FreeDOS Interim Build T2210

2022-10-02 Thread tom ehlert
> I’ve just uploaded this months Interim Build to ibiblio. To test > T2210, you can fetch it from > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ > I’ve warned about this several times. But with the recent updates > and few additions to the DJGPP packages, the Bonus

Re: [Freedos-devel] Bonus/Devel CD

2022-10-24 Thread tom ehlert
when downloading https://github.com/FDOS/kernel via [code] downnload ZIP the downloaded kernel-master\country directory is empty, and the project does not build. correcting for this, the the boooting kernel goes as far as FreeDOS boot FAT kernel GO! compiler watcom C Tom _

[Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

2022-10-25 Thread tom ehlert
Sorry, I posted this under the wrong topic. so: when downloading https://github.com/FDOS/kernel via [code] downnload ZIP the downloaded kernel-master\country directory is empty, and the project does not build. correcting for this, the the boooting kernel goes as far as FreeDOS boot FAT ke

Re: [Freedos-devel] Bonus/Devel CD

2022-10-26 Thread tom ehlert
> 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. ca. 30 years ago PCI enumerating has been invented. > I have a > single ETHERNET.BAT file I run to inst

Re: [Freedos-devel] Bonus/Devel CD

2022-10-26 Thread tom ehlert
> 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 netw

Re: [Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

2022-10-27 Thread tom ehlert
> correcting for this, the the boooting kernel goes as far as > I'm looking into this, seems to be some sort of memory corruption.  > On my test VirtualBox vm it works fine, on my laptop I get a halt > but much later than you, where FreeCom is loading.  The gcc compiled > kernel works in all my

Re: [Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

2022-10-27 Thread tom ehlert
> Does it make a difference on your computer if the kernel is > compiled for 386+ vs 86+  ?  Was this on real computer or virtual?  it was a VirtualBox machine. I only changed in build.bat from build.b the compiler setting, using OCWIN, so it probably was 8086 of course I have a very specific fl

Re: [Freedos-devel] The FreeDOS Kernel as downloadable from GITHUB no longer works

2022-10-29 Thread tom ehlert
Hi all, it seems this case is not as dramatic as it seemed first (to me). to repeat my earlier steps, I downloaded and installed kernel-master.zip and country.zip; edited config.bat to COMPILER=OWWIN, compiled and the resulting kernel.sys booted as it should. BUT: when I edited config.c, and aga

[Freedos-devel] GPT disk detection in FreeDOS kernel

2022-10-29 Thread tom ehlert
to make myself a better mailing list citizen, I created a new topic for this different issue ;) I have INITDISK.C that will detect and mount GPT partitions if available. FAT partitions on GPT disks are fully 'normal' drives. to be discussed, and I have no strong opinion here: shall FreeDOS ke

Re: [Freedos-devel] Toggling directories

2022-11-11 Thread tom ehlert
Hallo Herr Jerome Shidel, am Mittwoch, 9. November 2022 um 16:26 schrieben Sie: > Not all options perform toggling. For example: > dir /p - pauses per page > dir /p /p - pauses per page > I don’t think the toggling is very important. But, it does deviant from > MS-DOS. > I do

Re: [Freedos-devel] Toggling directories

2022-11-12 Thread tom ehlert
> In general, I find that toggling options are a bad idea. Things > just get too confusing, especially if you have multiple "sources" > for the options (like combinations of internal/compile-time default > settings, environment variables, options entered through a batch > file, options entered v

Re: [Freedos-devel] FreeDOS floppy edition boot disk lacks an editor?

2022-12-05 Thread tom ehlert
> You really don't want a 160 kb editor on a floppy (unless you copy it > to a RAM disk). copying it to a RAM disk will require 1 or 2 seconds every time you boot this floppy. starting this from floppy requires 1 or 2 seconds every time you use the editor - usually less often then you use to bo

Re: [Freedos-devel] Linking asm with C

2023-01-13 Thread tom ehlert
> I’m currently trying to make a function in a separate assembly > file, but I’m having problems linking it with a C program. it always helps to take the time to describe the problem you are facing, like what compiler, assembler, linker WHAT KIND OF PROBLEMS Tom

Re: [Freedos-devel] Linking asm with C

2023-01-13 Thread tom ehlert
_ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel Mit freundlichen Grüßen / with kind regards Tom Ehlert +49-15151898538 ___ 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?

2023-01-15 Thread tom ehlert
> 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 exte

Re: [Freedos-devel]  Re: Where to start and continue?

2023-01-16 Thread tom ehlert
Hallo Herr Knedlik, am Sonntag, 15. Januar 2023 um 15:17 schrieben Sie: > 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

Re: [Freedos-devel]  Re: Google Summer of Code?

2023-01-22 Thread tom ehlert
Hi, > the proposal was from me. Maybe some of you know that I work on the text for > a new help version. > To do so, I use different sources, depending on what I can get. > Sometimes documentation is very good, sometimes there is none, > sometimes even command/? gives no information and I have to

Re: [Freedos-devel]  Re:  Re: Google Summer of Code?

2023-01-22 Thread tom ehlert
; willi > -- > Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.comMail > gesendet. > Am 22.01.23, 17:56 schrieb tom ehlert :Hi, >> the proposal was from me. Maybe some of you know that I work on the text for >> a new help version. >> To do so,

Re: [Freedos-devel] Google Summer of Code?

2023-01-27 Thread tom ehlert
Hallo Herr Liam Proven, > I suppose my first suggestion would be: sod Windows. > A suggestion of a justification: > If people want a FOSS DOS then they must use a FOSS GUI, and if they > want a proprietary GUI then they must accept that also means a > proprietary DOS underneath. this argument i

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-27 Thread tom ehlert
Hi, most people around here already have a working machine, most likely Windows or Linux. any reason you don't download VirtualBox for your platform, select proper devices (there is even a Soundblaster16 emulated), install DOS on it and go. VirtualBox isn't perfect, but probably much better then

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Goo gle Summer of Code?

2023-01-27 Thread tom ehlert
Hallo Herr Ben Collver, am Freitag, 27. Januar 2023 um 18:23 schrieben Sie: > On Fri, 27 Jan 2023 at 16:42, tom ehlert wrote: >> any reason you don't download VirtualBox for your platform, select >> >> proper devices (there is even a Soundblaste

Re: [Freedos-devel] Google Summer of Code?

2023-01-29 Thread tom ehlert
>> 3. Develop embedded systems. > Not sure that's important in 2023. Any citations? http://wiki.freedos.org/wiki/index.php/Main_Page >> whatever EMM386 and friends was and is, it is definitively not what >> people think when they hear 'DOS VM'. you are abusing words to make a >> point. not go

Re: [Freedos-devel] Google Summer of Code?

2023-01-29 Thread tom ehlert
> I know. I am a professional in this field and have been since 1988. > Please do me the courtesy of imagining that I know what I am talking > about. according to https://cz.linkedin.com/in/liamproven FOSS and cloud reporter · Freelance writer and English teacher · Technical writer/editor · Soft

Re: [Freedos-devel] Google Summer of Code?

2023-01-29 Thread tom ehlert
>>> whatever EMM386 and friends was and is, it is definitively not what >>> people think when they hear 'DOS VM'. you are abusing words to make a >>> point. not good. >> I don't really care. I am talking about how existing DOS 386 memory >> managers have worked for 35+ years now. >> The 80386 has

Re: [Freedos-devel] DOS File Sharing- was: UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

2023-01-31 Thread tom ehlert
https://forums.virtualbox.org/viewtopic.php?f=4&t=105823 I haven't tested this, but there seems to exist "VBSF.EXE -- a client for Shared Folders. This allows shared folders to be mounted as drives inside MS-DOS (and Windows 3.x) directly, without any network stack." which is more or less w

Re: [Freedos-devel] DOS File Sharing- was: UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

2023-01-31 Thread tom ehlert
> The main difference between using VBADOS and EtherDFS would come > down to the DOS machine. If running DOS inside VirtualBox, VBADOS > would most likely be the easiest to setup and use. However, using > EtherDFS works under other Virtual Machines and with real hardware. EtherDFS should work f

Re: [Freedos-devel] Proposal: remove Graphical Desktops from next FreeDOS

2023-02-16 Thread tom ehlert
> And to be clear: I don't plan to delete these from the FreeDOS Files > Archive at Ibiblio. My proposal is just to not include them in the > next FreeDOS distribution. +1 > If people want to keep using, say, SEAL - > they can download it and install it themselves. as of many other packages. T

Re: [Freedos-devel] IFS API

2023-02-21 Thread tom ehlert
Hallo Herr Ralf Quint, am Montag, 20. Februar 2023 um 18:18 schrieben Sie: > 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? > There is no such thing for DOS. For DOS, things like this, for exampl

Re: [Freedos-devel] IFS API

2023-02-21 Thread tom ehlert
Hallo Herr Ralf Quint, am Dienstag, 21. Februar 2023 um 01:17 schrieben Sie: > > Don't recall when MSCDEX first showed up, but I think it was > after the networking redirector stuff (for both Novell and LanManager) > in MS-DOS 3.0. early version of Novell hooked a couple of interrup

Re: [Freedos-devel] Free FDISK interim builds

2023-02-27 Thread tom ehlert
Hallo Herr Bernd Boeckmann via Freedos-devel, am Montag, 27. Februar 2023 um 13:07 schrieben Sie: >> Am 27.02.2023 um 07:26 schrieb Deposite Pirate : >> >> I'm not sure if this fdisk can already do that, but additionally it >> would also be very useful if it could align partitions to 4k rather

Re: [Freedos-devel] IFS API

2023-02-28 Thread tom ehlert
Hey! > As a matter of curiosity, given that we were unable to find a > precise answer to why Microsoft dropped IFS after MS-DOS 5.0 to start with, your question is pretty much nonsense. IFS or the "networking redirector" was definitively there in MSDOS 6.2 and most likely in 7 (aka Win95). it

Re: [Freedos-devel] MS-DOG (was Re: [Freedos-user] FSF)

2023-03-01 Thread tom ehlert
Hallo Herr Rugxulo, am Mittwoch, 1. März 2023 um 10:22 schrieben Sie: Hi again, > It's entirely possible that Richard dislikes DOS that much. I also dislike Richard. we can leave it at that. Tom ___ Freedos-devel mailing list Freedos-devel@lists.

Re: [Freedos-devel] Free FDISK interim builds

2023-03-01 Thread tom ehlert
Hallo Herr Ralf Quint, am Mittwoch, 1. März 2023 um 18:08 schrieben Sie: > On 3/1/2023 8:22 AM, Bernd Boeckmann via Freedos-devel wrote: >> Hello, >> >> I am now reaching a state where I think that FDISK not any longer breaks the >> partition layouts created by itself. >> >> However, there is at

Re: [Freedos-devel] Free FDISK interim builds

2023-03-01 Thread tom ehlert
>>> The reason why partition boundaries are aligned on cylinder boundaries >>> is that a lot of other OSes also rely on that. >> any example of this? I don't any (not completely braindead) operating >> system would rely on that; it's just the way that FDISK and friends >> place partitions on the d

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-03 Thread tom ehlert
Hi, > I'm wondering if anybody has any experience, or has seen any source > code, related to manipulating the DOS Swappable Data Area (SDA) to > make DOS re-entrant. I working on at least one TSR program right > now where I think something like that might be useful but I've never seen it > done

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-03 Thread tom ehlert
Hallo Herr Bret Johnson, am Freitag, 3. März 2023 um 23:40 schrieben Sie: >>> But I was still wondering if anybody has seen it done before since >>> I don't think I've ever seen an actual implementation. >> >> neither did I. > Probably not worth pursuing. But even just the idea of a > re-entran

Re: [Freedos-devel] 386MAX

2023-03-06 Thread tom ehlert
Hallo Herr jer...@shidel.net, am Sonntag, 5. März 2023 um 22:43 schrieben Sie: > Hi all, > I spent a few minutes looking at 386MAX. > Unfortunately, it is going to take at least a some work by someone > (not me) before it could even be considered for inclusion. > First, it cannot even be run

Re: [Freedos-devel] 386MAX

2023-03-06 Thread tom ehlert
Hallo Herr tom ehlert, am Montag, 6. März 2023 um 10:14 schrieben Sie: > Hallo Herr jer...@shidel.net, >> Any volunteers? > to start first: what would be the point to have 386MAX in freedos > distribution (after 20 years without it)? > I know that it was somewhat important

Re: [Freedos-devel] 386MAX

2023-03-06 Thread tom ehlert
Hallo Herr Bret Johnson, am Montag, 6. März 2023 um 19:43 schrieben Sie: >>> 386MAX supports the Global EMM Import Specification (GEMMIS), which >>> allows Windows 3.x to start in 386 Enhanced mode, even when the EMM >>> manager is loaded. (The documentation in the 386MAX source code >>> seems to

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-07 Thread tom ehlert
> The SDA of MS seems fairly well documented in RBIL, but I'd be > pretty surprised if all DOS clones (particularly Virtual Machines > like DOSBox) are compliant so it may not be a good idea to pursue. > I suspect FreeDOS would be pretty close to compliant, but I'm not even sure > about that.

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

2023-03-08 Thread tom ehlert
> Over a month ago, I opened an issue on the FreeDOS project on > GitLab about the Open Watcom v2 installer being extremely slow in > FreeDOS. It takes an hour or more on FreeDOS, while the same > installation completes on MS-DOS 7.1 within just a few minutes. either you report your config.sys a

Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS

2023-03-08 Thread tom ehlert
> That depends. whatever 'depends'. > Besides poorly optimized system caches, is the > installer doing things that blow the cache and increase the miss rate? whatever the installer is doing: unless you find a valid 'this is doing something in a stupid way' point this installer is as much a val

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-09 Thread tom ehlert
>> A Virtual Machine for the rest of us is something like VMWare, Qemu, >> VirtualBox, etc. - something that simulates a real machine. You >> load a real operating system in it and the operating system >> generally doesn't know or care that it's actually in a simulation. > So "the rest of us" i

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-10 Thread tom ehlert
Dear Bret , am Donnerstag, 9. März 2023 um 23:27 schrieben Sie: >>> My terminology is compliant with that definition. >> >> *Sigh* >> >> I am aware of that. The general term "re-entrancy" is not synonymous >> with the specific term "reentrant kernel". > So re-entrancy is not synonymous with re-e

Re: [Freedos-devel] FDISK: how to handle sector size != 512?

2023-03-15 Thread tom ehlert
Hi, > while hacking on FDISK and having some thoughts about different > sector sizes I stumbled upon the problem that the extended INT13 > function 48 may return a sector size != 512 while the INT13,0X > functions always seem to operate on „virtual“ 512 sector sizes. all INT13 functions operate (

Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread tom ehlert
Hallo Herr Bernd Boeckmann via Freedos-devel, am Freitag, 17. März 2023 um 12:52 schrieben Sie: >> Any thoughts? > I have some additional data: > 1) Pentium MMX 166, T2303 default installation: > Installation time Open Watcom 1.9, FDAPM activated: 7:09 minutes. > After FDAPM OFF: 4:30 Minut

Re: [Freedos-devel] Booting and FDAPM

2023-03-17 Thread tom ehlert
> IDLEHALT=1 works for my machines and reduces the CPU load under > VirtualBox to nearly zero at the command prompt. :-))) FDAPM whatever should be REMified. OTOH this seems to be a problem between FDAPM, VirtualBOX and Watcom Installer. Whoever wants to develop ON FreeDOS ... >> Am 17.0

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-18 Thread tom ehlert
Hallo Herr Bret Johnson, am Donnerstag, 9. März 2023 um 23:27 schrieben Sie: > The computer I'm currently using is a few years old, old enough > that I can boot DOS on the actual hardware. The CPU is an Intel i5-4590 > running at 3.30 GHz. > I have a DOS program I wrote a long time ago, call

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-21 Thread tom ehlert
Hallo Herr Rugxulo, am Montag, 20. März 2023 um 23:20 schrieben Sie: > Hi again, > On Mon, Mar 20, 2023 at 5:06 PM Bret Johnson wrote: >> >> This is something much more serious than a "tradeoff" or a >> "regression". My new i5 CPU appears to be spending _at least_ 99% >> of its resources NOT

Re: [Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker benchmark

2023-03-21 Thread tom ehlert
Hi, am Dienstag, 21. März 2023 um 23:26 schrieben Sie: > Hello! The article is found at > https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison I mostly agree with you and your article, but: >Conclusion >CPU-bound benchmarks are much faster on a modern

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-23 Thread tom ehlert
Hallo Herr Bret Johnson, am Donnerstag, 23. März 2023 um 20:31 schrieben Sie: >>> Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5? And >>> again, I know it doesn't make any sense, but it's still true. >>> >>> As far as I can tell, the Emperor has no Clothes. >> >> I'm confused by thi

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

2023-03-23 Thread tom ehlert
" or "unfair" or "sub-optimal" or something > like that, but the results are very real and are simply what they > are.  Also, as already stated, the purpose of SLOWDOWN is not to be > a benchmark but you can indirectly use it as a benchmark. > _______

Re: [Freedos-devel] I wish I had a boot.log file

2023-03-26 Thread tom ehlert
> For > instance, vecho (which displays many user messages, like “Welcome to > FreeDOS”) don’t output text the same way as other programs and do not get > captured at present. I don't know how and why vecho displays text different. However it could "display" the text twice: once in the complicate

Re: [Freedos-devel] Slowdown-Units ratings and a CPU-bound depacker be nchmark

2023-04-04 Thread tom ehlert
Dear Bret, > The article is found at >> https://pushbx.org/ecm/dokuwiki/doku.php?id=blog:pushbx:2023:0321_cpu_performance_comparison > I mostly agree with you and your article, but: fine that you agree, but at most 50% of the article is even close to 'right'. >>> Conclusion >>> >>> CPU-bound

Re: [Freedos-devel] Bug 0x5801/41

2023-04-07 Thread tom ehlert
Hi, > Don’t know if the issue is in the Kernel (0.85a), HimemX (3.38), JEMM386 > (5.83) or My Head. it's in the Kernel - or in your head. to decide between these two alternatives it's always helpful to send your actual sources - not an english description of what you had intended to do. and of

Re: [Freedos-devel] Extension proposal

2023-04-21 Thread tom ehlert
Hi, > At present, the interface program for Logger just performs a slightly > optimized brute force search for the Logger device driver. Although reliable, > it is very slow compared to providing a simple interrupt call to test for > installation. given that this detection will be done once p

Re: [Freedos-devel] Extension proposal

2023-04-21 Thread tom ehlert
Hi ecm, > [1]: > https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267 this got me looking into this 'too slow' detection method. and it is indeed slow. as in molasse. let me explain. a) isn't %%Comparing: inc di

Re: [Freedos-devel] Logger v0.1 (beta)

2023-05-02 Thread tom ehlert
Hi Jerome, if you make it a logger.exe (rather tehn .com), UPX should be able to compress dual mode programs. Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] I want my 10K

2023-05-17 Thread tom ehlert
> This could look something like this. The system boots as normal. A CONFIG > option like ‘DOSMOVE=UMB’ could exist. there exists already the DOS=UMB option, meaning "move as much as possible to UMB". IIRC when Bart implemented this he only moved DATA (buffers, LASTDRIVE=, current directories,

Re: [Freedos-devel] EXIST NUL

2023-06-06 Thread tom ehlert
Hallo Herr Ralf Quint, am Montag, 5. Juni 2023 um 23:06 schrieben Sie: > On 6/5/2023 1:56 AM, jer...@shidel.net wrote: >> >> Hi All, >> >> /There are two separate issues when using: |IF EXIST ?:\NUL| / >> >> /I'm lazy and wrote up a info text file over at > >> https://fd.lod.bz/redist/testing/de

Re: [Freedos-devel] useful HTMLHELP bug findings and proposals

2023-06-20 Thread tom ehlert
Dear Vacek, > If it wasn’t on the to-do list earlier, I'd kindly request a mapping of > codepage 3845. Please map code point 0x9F, the Ft sign temporarily to > U+FFFD and add a comment to the definition file along the comments of > "addition of the forint sign into Unicode pending". > This would

Re: [Freedos-devel] format \s

2023-06-23 Thread tom ehlert
Hallo Herr Harald Arnesen, am Freitag, 23. Juni 2023 um 21:29 schrieben Sie: > Patrick McCavery [23/06/2023 18.13]: >> If I could run format \s right from Linux, I could use all of my >> existing toolchain and I would not have to run this command on a USB key >> from within qemu. >> > Could this

Re: [Freedos-devel] format /s

2023-06-23 Thread tom ehlert
> So in short, DOS is not great for real-time stuff, +1 > but it certainly is not as bad as Windows :-p Windows is actually quite good for realtime stuff (even hard realtime stuff) - if you write your time critical stuff as a device driver. there are a lot of provisions, directives, howto's e

Re: [Freedos-devel] Joke of the day: lb040501.zip !?

2004-05-09 Thread tom ehlert
Hello Eric, > Hi, I got an urgent request well - really urgent ;) > The claim is that (paraphrasing) "having to use a web browser > to download non-8.3-filename and save it as 8.3 filename on > disk would be contradictory to GPL". a) the claim is 100% bullshit. b) but is a good reason to switch

Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS (MSCLIENT failure)

2004-04-26 Thread tom ehlert
Hello Johnson, JL> I got the same problem when trying MSCLIENT, it does work under JL> FDXXMS+UMBPCI (try it), but fail with HIMEM+EMM386. I'm quite sure the JL> memory manager and hardware not so compatible especially Network JL> Interface Card. Freedos EMM386 doesn't support VDS yet, and NET.EXE

[Freedos-devel] EBDA

2004-04-26 Thread tom ehlert
Checking MSDOS 6.2, the kernel doesn't move the EBDA if no UMB is found. moving the EBDA makes most sense anyway, if it's moved to upper (UMB) memory) So I would recommend to disable move EBDA by default, or to move it only if UMB space can be allocated for it. in the default setting, moving the

Re: [Freedos-devel] EBDA

2004-04-26 Thread tom ehlert
ek BO> For a limited time only, get FREE Ground shipping on all orders of $35 BO> or more. Hurry up and shop folks, this offer expires April 30th! BO> http://www.thinkgeek.com/freeshipping/?cpg=12297 BO> _______ BO> Freedos-dev

Re: [Freedos-devel] EBDA

2004-04-27 Thread tom ehlert
BO> On Mon, 26 Apr 2004, Bart wrote: BO> "Some (especially embedded) applications don't use the DOS memory manager BO> but assume all the memory past that given to them by DOS is free for BO> use. " BO> .. BO> Obvious reply: BO> Most users don't use "Some (especially embedded) applications". And

Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS

2004-05-01 Thread tom ehlert
> Now, my users are reporting that the boot disk no longer works on > machines which have Intel gigabit (PRO/1000) networking hardware. Problem: Intel PRO1000 network driver E1000.DOS does Int21/IoControl XYZ --> driver --> Int21/GetVect, Setvect this will reuse the sam

Re: [Freedos-devel] Intel PRO/1000 driver fails under FreeDOS

2004-05-03 Thread tom ehlert
Bart, >> Int21/IoControl XYZ >> --> driver >> --> Int21/GetVect, Setvect > the problem with this is that int28 handlers will now end up on the error > stack instead of the disk api stack. So if an int28-TSR such as THELP > causes a critical error, the critical error will end up on i

Re: [Freedos-devel] Re: [Freedos-cvs] kernel/kernel fattab.c,1.30,1.31 fatfs.c,1.66,1.67

2004-05-04 Thread tom ehlert
Hello Arkady, >> + wasfree = 0; >> + if (cluster == FREE) >> +wasfree = 1; > wasfree = cluster == FREE; well - we know that gifted russian programmers can read this cryptic stuff fluently. mortal programmers like me prefer a more readable style. tom ---

Re: [Freedos-devel] LH DISPLAY problems / NLSFUNC in a nutshell

2004-05-04 Thread tom ehlert
> The latter suggestion is especially important if you want to make > DISPLAY a real DEVICE. Other than an EXE (with heap specification in > the header), the SYS would have to be an huge file, 60k or something, > unless you allocate the buffers dynamically. or you use .EXE style sys-files, of cours

[Freedos-devel] command.com should be compilable from source

2004-05-30 Thread tom ehlert
well it is. even the published suppl source is. unfortunately, it's incomplete; the available suppl.lib contains functions where the source doesn't exist on the net. see bug #1794 tom --- This SF.Net email is sponsored by: Oracle 10g Get cert

Re: [Freedos-devel] FreeDOS 10th "Birthday"

2004-05-30 Thread tom ehlert
Hello Jim, > PD-DOS was announced to the world on June 28, 1994. That project would > quickly turn into the FreeDOS Project. It's amazing to see the project > still alive and kicking after 10 years. So I thought it would be > appropriate to do something to celebrate our 10th "birthday" this ye

Re: [Freedos-devel] "copy . c:" fails. Kernel or Freecom?

2004-06-08 Thread tom ehlert
Hello Erwin, > A well known alternative for '*.*' is to use '.' with 'copy', like: 'copy . c:' > This works fine with MsDOS and DrDOS (OpenDOS) but fails > on FreeDOS with every kernel (2026b - 2035) and freecom > (0.82pl1 - 0.82pl3k) I tried (clean boot, no himem/emm386). > This dot-shortcut is u

Re: [Freedos-devel] FreeCOM CLS suggestions (vs. CTTY?)

2004-06-15 Thread tom ehlert
nstallShield X is the > one installation-authoring solution that does it all. Learn more and > evaluate today! http://www.installshield.com/Dev2Dev/0504 > ___________ > Freedos-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.n

Re: [Freedos-devel] bug in UMB support

2004-06-20 Thread tom ehlert
Hello Michael, > I hope to have some free time later this weekend and will try to get caught > up on a few FreeDOS items, including your requested test, a stand-alone UMB > stress test, whatever arkady suggests - IMO its nonsense. I coded the original implementation for 2 good reasons as it was

Re: [Freedos-devel] bug in UMB support

2004-06-21 Thread tom ehlert
> for example, as I understand, latest FD-EMM386 translates > starting I= area address A000 to A001 because there is bug in (current) FD. > Isn't it? right. ALL fd-emm386's translate a000 into a001; so it will never be merged into the lower memory block. if the a000 block is ever merged into the l

Re: [Freedos-devel] space in environment

2004-06-27 Thread tom ehlert
Hello Arkady, > 5. MS-command.com places its (resized) segment with environment right after >itself (original segment preserved not freed), FreeCOM places environment >into UMB, but, as I understand, with LAST_FIT. > I think, (5) should be changed (LAST_FIT to BEST_FIT). I think (5) shou

Re: [Freedos-devel] space in environment

2004-06-27 Thread tom ehlert
Hello Arkady, >>> 5. MS-command.com places its (resized) segment with environment right after >>>itself (original segment preserved not freed), FreeCOM places environment >>>into UMB, but, as I understand, with LAST_FIT. >>> I think, (5) should be changed (LAST_FIT to BEST_FIT). te>> I thi

Re: [Freedos-devel] Re: FreeCOM environment

2004-06-30 Thread tom ehlert
Hello Arkady, > I suggest, this may cause troubles for your swapping FreeCOM edition. > What I mean: FreeCOM loaded at FABh; when it runs program, it remains here > (shorter) stub and swaps itself somewhere. Let suggest, some program will > allocate memory at 1063h (right after stub). As I un

Re: [Freedos-devel] Re: FreeDOS distro delayed

2004-06-30 Thread tom ehlert
Hello Arkady, > I already know that tom will never accept my changes for kernel. which isn't true, I even look over your SMALL changes, if they are appended; took your RET_AH fix, and found nothing else useful enough to fire up my editor immediately. if you would send 200 mail's each stating

Re: [Freedos-devel] updates: SORT, translations of FIND / others

2004-07-05 Thread tom ehlert
Hello Eric, Monday, July 5, 2004, 4:23:00 AM, you wrote: > Hi, translation time! > http://www.coli.uni-sb.de/~eric/stuff/soft/ sort-04jul2004.zip I'd prefer programming time as SORT can't sort anything greater then ~15000 byte. In this case I'd prefer functionality over 'smallest executable at

Re: [Freedos-devel] EMM386 VCPI/DPMI Help / Question

2004-07-06 Thread tom ehlert
Hello Arkady, MD>> I'd recommend asking Tom Ehlert or any of the MD>> other original authors (whomever they might be) about making the change. I MD>> already have enough stress in my life rather than get in the middle of that MD>> debate -- or an

Re: [Freedos-devel] EMM386 VCPI/DPMI Help / Question

2004-07-06 Thread tom ehlert
and significant difference between 'idea to add VCPI' and 'idea that tom ehlert adds VCPI' tom --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vega

Re: [Freedos-devel] A000 to A001 possible change

2004-07-06 Thread tom ehlert
Hello Michael, > Should EMM386 remove its current code which changes returned upper memory > block start addresses from A000 to A001? Is it safe? Is it sane? Is it > The Right Thing To Do or not? when I wrote that 'return a001 instead of a000', I saw a lot of problems, that would arise, if low

Re: [Freedos-devel] A000 to A001 possible change

2004-07-07 Thread tom ehlert
Hello Arkady, te>> actually I don't see the point - it's open source; why doesn't he te>> compile it himself ? > Because I prefer to ask mantainer(s) instead make other fork for > another application. in an open source world, you SHOULD compile and test yourself. if works - fine, tell the m

Re: [Freedos-devel] A000 to A001 possible change

2004-07-08 Thread tom ehlert
Hello Michael,Arkady, and everybody else WITHOUT PROGRAMMING OR TESTING !! some thoughts: being pressed by arkady, I rethought the issue. I think, that even IF EMM385 returns A000, the old kernels will not merge a000 UMB into lower RAM. old kernel, old a001 EMM386: 1 - 9 availab

Re: [Freedos-devel] Announce: SORT 1.4 released

2004-07-09 Thread tom ehlert
gas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > ___ > Freedos-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/li

Re: [Freedos-devel] GRC and FreeDOS

2004-07-09 Thread tom ehlert
Hello Alain, > I believe this is a very typical representation of FreeDOS development. > Some people are optimizing it while critical problems (for some people) > remain unsolved. I don't think that this statement is valid for the last 3 years of kernel development. tom -

Re: [Freedos-devel] best free C++ compiler

2004-07-22 Thread tom ehlert
Hello Roberto, > I must add the Digital Mars C++ compiler (http://www.digitalmars.com), > closed source, free (as in beer), and currently actively maintained by > its original author Walter Bright. I think that the DOS compiler it's a > 16bit executable, but I'm not sure. > DMC is faster than OW,

Re: [Freedos-devel] Small EMM386 update & call for bugs

2004-07-22 Thread tom ehlert
Hello Michael, > Uploaded to ftp://ftp.devoresoftware.com/downloads are the files emm386.zip > (uncompressed executable) and emm386sr.zip (revised source code) for EMM386. > and restores the VDS experimental option for those who > can use it in its current skeletal condition. if you didn't make

Re: [Freedos-devel] Ensemble Lite Redux

2004-07-29 Thread tom ehlert
Hello Jim, > Michael Devore wrote: >> >> This is pretty cosmetic stuff and really, EMM386 has been acting like >> ALTBOOT from the beginning. > I would agree with Aitor - the /ALTBOOT option in FreeDOS EMM386 should > act the same as MS-DOS EMM386. exactly. a) it shouldn't be needed b) MS /AL

Re: [Freedos-devel] Format 0.91r and FreeCOM sound tests

2004-07-30 Thread tom ehlert
Hello Luchezar, > Sure. Borland's delay() uses timer 0. Why not rely on the referesh toggle > bit instead? maybe because that's a *really* undocumented input bit ? I searched right now, but couldn't find it anywhere. so let me ask: what kind of 'refresh' is that ? does this work on compaq/dell

Re: [Freedos-devel] Re: Format 0.91r and FreeCOM sound tests

2004-07-30 Thread tom ehlert
Hello Steffen, > The boot menu is used in a DOS session one time at maximum. and - hopefully - FreeCOM also isn't bping all the time ;) >> INT 15 - BIOS - WAIT (AT,PS) >>AH = 86h >>CX:DX = interval in microseconds >> Return: CF clear if successful (wait interval elapsed) >>

Re: [Freedos-devel] BEEP

2004-07-30 Thread tom ehlert
Hello Bart, > Don't forget that FreeCOM is also supposed to be able to run over a serial > line via CTTY. In that case the beep should happen on the terminal and not > on the PC where FreeCOM actually runs. > So I vote for >putchar('\007'); > no BIOS, no int29, no delay timing, no direct ha

Re: [Freedos-devel] Re: How to detect if fd #0/#1 are the local console

2004-08-06 Thread tom ehlert
Hello Bart, >> But back to the question: "HOW DOES FREECOM KNOW THAT THE CURRENT STANDARD >> OUTPUT IS THE DEVICE DRIVEN BY THE BIOS?" > The only reliable way is to trap int10, write a character using int21 and > see if it gets trapped. I've seen (N)ANSI.SYS implementations doing direct screen I

<    1   2   3   4   5   6   7   >