Re: [Freedos-user] state of play
Thankyou everyone for your answers. I've made a lot of progress and Freedos is looking fantastic. The first problem I would like to address is that I have installed the DOS version of mplayer and the video is working fine, but there is no audio. Some research said that I need to use jemm with /sb to get audio to work. I'd like to ask a more fundamental question - why does video not require a driver to be installed, but audio does? Is audio more complicated than video or something? Or was it never properly standardized by IBM or someone? Next question is - what does emm have to do with a sound card driver?! I'm only guessing that my laptop is compatible with soundblaster. What are the odds of that being true? Any suggestion on what to do to get sound working? Thanks. Paul. -- This email has been checked for viruses by AVG. https://www.avg.com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] state of play
Hi folks. Freedos 1.3 RC5 is now good enough for my main need which is to do development work using gccwin (similar to mingw) to build Win32 executables. (making use of HX too). I am now looking for Freedos to be a viable alternative to Windows for the rest of the things I would like to do. What I'm looking for is Win32 applications that run under both Freedos+HX and Windows 10. In particular I want: 1. Something to display JPEGs. Just one JPEG at a time is fine. I actually have some software to do this already (public domain C code), but although it works under Win10, it produces garbage on Freedos + HX. 2. Something to play MP3s. 3. Something to play movies like MP4s. 4. Something to read and write text email - for this I would like a Win32 console mode application using ANSI escape sequences. Currently I have "msged" working for Fidonet technology messages. 5. Something to send/receive email to gmail. I am expecting this to be DOS-specific rather than a Win32 application, and I am expecting to need to use ethernet instead of Wifi, as I believe the ethernet spec is open but the Wifi spec is not. Does such software exist? If Win32 applications are not available, I'm interested in DOS alternatives. Note that I have produced my own Freedos distribution if anyone is interested. It is available at http://pdos.org Thanks. Paul. -- This email has been checked for viruses by AVG. https://www.avg.com ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
Hi Jeremy. I just realized that the bug fix you have already committed is enough to unblock what I am doing. All I need to do is run “pdmake –n” to produce a batch file, and then I don’t need command.com to accept a long parameter. It would certainly be nice if it did, but it is not necessary. I was successfully able to rebuild my version of binutils 2.14a on Freedos+HX+doslfn with the freecom beta. This now provides me with a replacement Windows environment independent of Linux. Results so far are reasonable, I can produce a viable “as”, but the binaries are not identical and I need to do more thorough testing, and then perhaps hope that the difference is some unimportant uninitialized data or something. Also I need to see if I can build my GCC 3.2.3. Hopefully this is the end of Windows 10, because all I need to do is run Bochs under Linux instead of Win 10. BFN. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
Resending – I think it didn’t get through ... Hi Jeremy. I just realized that the bug fix you have already committed is enough to unblock what I am doing. All I need to do is run “pdmake –n” to produce a batch file, and then I don’t need command.com to accept a long parameter. It would certainly be nice if it did, but it is not necessary. I was successfully able to rebuild my version of binutils 2.14a on Freedos+HX+doslfn with the freecom beta. This now provides me with a replacement Windows environment independent of Linux. Results so far are reasonable, I can produce a viable “as”, but the binaries are not identical and I need to do more thorough testing, and then perhaps hope that the difference is some unimportant uninitialized data or something. Also I need to see if I can build my GCC 3.2.3. Hopefully this is the end of Windows 10, because all I need to do is run Bochs under Linux instead of Win 10. BFN. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
> Yes, I had hoped to get a release out already but ran > into build issues getting all compilers to build which > was just fixed*. I will look into the cmdline issue, > already filled a bug for it. Then post the release. Hi Jeremy. Thanks for filing the bug report. Could you please hold off doing a formal release until I’ve had a chance to test it? I have a good test environment, and Japheth is active, so hopefully we can put this to bed. Thanks. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] command.com and long commands
IMO it's a bug in FD command.com. If a command line exceeds 126 bytes, the value at [PSP:80h] "should" be 0x7Fh ( and a 0x0D "should" be placed at [PSP:FFh] ) - that's at least what COMMAND.COM of Win95/98 does. The environment variable CMDLINE will then contain the full command line. It's documented in RBIL. A bit more information from Japheth: freecom sets the length byte of the command tail at PSP:80h to the "true" value of the commandline length. If the command line is 130 chars, this value will be 82h. However, since the PSP has a size of 256 only, just the first 127 bytes are copied to PSP:81h-ffh. Note that Eric has replied now, and I have to digest that. BFN. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] command.com and long commands
Hello. When I run a long command, e.g. pdptest ... (to exceed 126 characters), and it is a Win32 executable so HX gets involved, I get a crash. Japheth has debugged it and reported his findings. Could someone please confirm that his analysis below is correct and it is a Freecom bug? Or is more information required? Thanks. Paul. IMO it's a bug in FD command.com. If a command line exceeds 126 bytes, the value at [PSP:80h] "should" be 0x7Fh ( and a 0x0D "should" be placed at [PSP:FFh] ) - that's at least what COMMAND.COM of Win95/98 does. The environment variable CMDLINE will then contain the full command line. It's documented in RBIL. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] DOS extenders with 32-bit INT 21H
Hi all. A short time ago I was made aware of this: http://dos32a.narechk.net/manual/index.html which is a 32-bit INT 21H AH=40H call that does a "write". Exactly the same as 16-bit INT 21H, except with 32-bit registers. Given that Microsoft don't have such a thing, it means that anyone who created such an API got to make up registers themselves. In this case, bx was changed to ebx etc, so everything seems sensible. But I'm wondering how many different variations of this there are. Or did DOS/4GW set the industry standard and almost everyone copied them? In particular I'm interested to know if EMX 0.9d copied them. I know that EMX internally uses a 32-bit a.out file, but what I'd like to know is if that a.out file does an INT 21H above (in 32-bit protected mode), does the EMX DOS extender handle that (and obviously end up doing one or more 16-bit INT 21H calls), or does EMX only support INT 31H (DPMI) or something else? Thanks. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] CMDLINE
Hi Eric. I went to github, but the readme didn't show the "/e" parameter. I looked around in the "docs" and "cmd" but nothing stood out. I don't want to report a bug unless I can see the documentation myself that says 32768. Currently I only see it when I go command /? on my version which is presumably old. Anyway, your theory is correct. ECX increases by 1 if I add another character to the command line. I have already raised a problem with HX, so we'll see what happens. BTW, I'm a bit surprised this hasn't been found a long time ago. HX + doslfn + Freedos gives you a free Windows-compatible environment. Surely there is some demand for this? The only thing I know of that is missing is msvcrt.dll. I provide one of those with PDPCLIB, but it only has C90 functionality. Not sure if someone else provides the msvcrt.dll that Wine must be using, for Freedos. Note that I provide another Win32 environment with PDOS/386. BFN. Paul. -Original Message- From: Eric Auer Sent: Sunday, May 30, 2021 9:06 PM To: Discussions and general questions about FreeDOS Subject: Re: [Freedos-user] CMDLINE Hi Paul, Thanks Eric - 32766 solved the problem! Good, could you file a ticket on that github to update the documentation to stop saying "32768" instead of the correct 32766? Thanks! :-) C:\DEVEL\binutils-2.14a>gcc386 -S temp.c j d dd jj doing CreateFile with Xtemp.cX cc1: temp.c: An error has occurred This isn't! C:\DEVEL\binutils-2.14a>gcc386 -S temp.c bb bbb jj k Commandline longer than 125 characters. Exception 0D EAX=0282 EBX=549D ECX=0003 EDX=0274 ESI=0100 EDI=0100 EBP=5898 ESP=5702 EFL=00013246 EIP=09FE CS=0097 (00111000,58CF,00FB) SS=008F (00111000,58CF,40F3) DS=009F (00029AF0,010F,00F3) ES=00D7 (000298C0,00FF,00F3) FS= (,,) GS= (,,) LDTR=0038 (FF80F000,0FFF,0082) TR=0030 (0002F770,0067,008B) ERRC= (,,) PTE 1. Page LDT=1FFEF467 GDTR=07FF:FF80E000 IDTR=07FF:FF80E800 PTE CR2=0067 CR0=E031 CR2= CR3=1000 CR4=0200 TSS:ESP0=2898 DR0-3= DR6=0FF0 DR7=0400 LPMS Sel=0087(01) RMS=31F6:0200 open RMCBs=/ ISR= [EIP]=F3 67 A4 F7 C7 00 FF 75 03 B0 0D AA That would be "rep a16 movsb" if the task is 32-bit? If the GPF is caused by ESI=EDI=100, maybe the "FF" in the description of ES refers to segment length? Which could mean a pointer overflow? Does the ECX in the error message get larger when you make the command line longer? If yes, it could mean that something tries to copy the over-long command line into the PSP? I think it is an HX problem, so I'll report it to Japheth. No idea, but you could use another DPMI provider, such as CWSDPMI, which would be the default for DJGPP? Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] CMDLINE
Thanks Eric - 32766 solved the problem! Now I'm on to my next problem. This is behaving normally (there is no temp.c): C:\DEVEL\binutils-2.14a>gcc386 -S temp.c j d dd jj doing CreateFile with Xtemp.cX cc1: temp.c: An error has occurred This isn't! C:\DEVEL\binutils-2.14a>gcc386 -S temp.c bb bbb jj k Commandline longer than 125 characters. Exception 0D EAX=0282 EBX=549D ECX=0003 EDX=0274 ESI=0100 EDI=0100 EBP=5898 ESP=5702 EFL=00013246 EIP=09FE CS=0097 (00111000,58CF,00FB) SS=008F (00111000,58CF,40F3) DS=009F (00029AF0,010F,00F3) ES=00D7 (000298C0,00FF,00F3) FS= (,,) GS= (,,) LDTR=0038 (FF80F000,0FFF,0082) TR=0030 (0002F770,0067,008B) ERRC= (,,) PTE 1. Page LDT=1FFEF467 GDTR=07FF:FF80E000 IDTR=07FF:FF80E800 PTE CR2=0067 CR0=E031 CR2= CR3=1000 CR4=0200 TSS:ESP0=2898 DR0-3= DR6=0FF0 DR7=0400 LPMS Sel=0087(01) RMS=31F6:0200 open RMCBs=/ ISR= [EIP]=F3 67 A4 F7 C7 00 FF 75 03 B0 0D AA [ESP]=4A5D 475A 0040 5898 5722 5712=549D 0274 005B 0204 5722=008F 008F 2875 00C7 5746 0040 0040 5732=5898 574A F000 572A 5742=0001 0507 0021 00C7 4550 014C 5752=0006 E78A 608B 00E0 I think it is an HX problem, so I'll report it to Japheth. BFN. Paul. -Original Message- From: Eric Auer Sent: Sunday, May 30, 2021 7:33 PM To: freedos-user@lists.sourceforge.net Subject: Re: [Freedos-user] CMDLINE Sorry, I have to correct myself: According to https://github.com/FDOS/freecom/blob/master/shell/init.c#L440 the REAL maximum possible environment size right now is "only" 32766. Not 32767 and not 32768, but FreeCOM texts (in all languages) claim it is 32768. If you specify values below 17 or above 32766, some default size of the environment will be used instead. Regards, Eric Hi Paul, I believe that command.com can get involved in the CMDLINE environment variable, just like any other program can. And if it can't, it should say so, rather than reporting a failed attempt to set it. C:\DEVEL\PDOS\SRC>ver FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00] This seems to be the oldest version with CMDLINE at all: https://github.com/FDOS/freecom/blob/master/CHANGED Actually there seems to be a documentation error: The REAL maximum value of 16-bit signed integers is 32767 and not 32768 bytes. Try /E:16384 of, if you are less humble, /E:32767 :-) https://github.com/FDOS/freecom/blob/master/shell/init.c#L102 Regards, Eric PS: I suggest to include a NEWER version in our distro! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] CMDLINE
Hi Eric. Thanks for your reply. "hexdump" is my own program and does not have a version. But it's the same with any program - command.com complains before executing the program. The environment used to be set to the default, I wasn't using the "shell" command. But I switched to the max when I got the error. As you can see from the below screenshot, that is the max. I believe that command.com can get involved in the CMDLINE environment variable, just like any other program can. And if it can't, it should say so, rather than reporting a failed attempt to set it. Version is below also. Also, I will be using HX as the DOS extender once I get command.com working. The way I use it, I am still dependent on command.com. Thanks. Paul. C:\DEVEL\PDOS\SRC>ver FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00] C:\DEVEL\PDOS\SRC>command /? Starts a new copy of the FreeDOS command shell. COMMAND [[drive:]path] [device] [/E:n] [/L:] [/U:nnn] [/P] [/MSG] [/LOW] [/Y [/[C|K] command]] [drive:]pathSpecifies the directory containing COMMAND.COM. device Specifies the device to use for command input and output. /E:nSets the initial environment size to n bytes. (n should be between 256 and 32,768). -Original Message- From: Eric Auer Sent: Sunday, May 30, 2021 6:31 PM To: freedos-user@lists.sourceforge.net Subject: Re: [Freedos-user] CMDLINE Hi Paul, commands with their arguments are indeed limited in length in DOS. As far as I remember, if you use DJGPP based apps (including for example BASH as shell) then they can exchange longer command line arguments with each other by storing them in environment variables, but I do not think that command.com participates in this method. Also, I am not sure whether /E:32768 is possible. There could be a lower limit for allowed env sizes. Which command.com version and which version of hexdump are you using? As far as I remember, neither MS DOS nor FreeDOS command.com use the CMDLINE mechanism, maybe you mean the shell (terminal) window of Microsoft Windows? Regards, Eric Can someone please explain the below: C:\>hexdump bb Commandline longer than 125 characters. Can not set environment variable 'CMDLINE'. Environment full? C:\>grep shell config.sys File CONFIG.SYS: shell=c:\command.com /p /l:1024 /e:32768 C:\> "hexdump" is just a simple MSDOS program and it doesn't make any difference which program I try to execute. It looks to me like command.com is doing the exact right thing, trying to set the CMDLINE variable for the long parameter, but I have no idea why it would fail to set it. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] CMDLINE
Can someone please explain the below: C:\>hexdump bb Commandline longer than 125 characters. Can not set environment variable 'CMDLINE'. Environment full? C:\>grep shell config.sys File CONFIG.SYS: shell=c:\command.com /p /l:1024 /e:32768 C:\> "hexdump" is just a simple MSDOS program and it doesn't make any difference which program I try to execute. It looks to me like command.com is doing the exact right thing, trying to set the CMDLINE variable for the long parameter, but I have no idea why it would fail to set it. Any ideas? Thanks. Paul. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
