Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
At 07:00 PM 7/6/2004 +0200, Aitor Santamaría Merino wrote: By the way, it's long since I last watched the EMM sources, but I've always thought that implementing RAM=/I=/X= couldn't be very difficult with current sources, by just modifying a bit ScanSystemMemory(), the current search range is fixed (at least it was in 2003): for (mem = 0xc000; mem 0xf000;) /* This is the range that should be IMHO modified with RAM= */ so you'd process the I's first, the X's next, and lastly the previous loop, so that if the entry is empty (hasn't been filled by the I/X processing) then you scan. Well, the fact that it might not have been done like that by current EMM386 developers gives a clue that it must be something more difficult behind... or am I wrong? Most standard options aren't all that horrible to implement, they just take modest chunks of time one by one, with debug and verification/field testing usually taking a lot more time than actually coding them. Now we have active RAM and HIGHSCAN requests, no big deal for either, really. But I'd like to see what the timeline for 1.0 FreeDOS release is first. The ever-receding goal line is getting me down. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
Alain schreef: 2) on NEW HW it works fine. In modern machines (mostly from PCI and P133 up) upper memory area is not encombered with anything. Before that QEMM's optimiser was the only way to make good use of UMB, but now any conservative auto setup will just set one chunk that goes from the video ROM to the BIOS ROM and that is just as good as you can get !!! == I am talking of many years of experience and surely there will be exceptions, but I have seen only one in all this time. Alain, you must be having a simple machine with no option roms then :) SCSI takes UMB space, and so do PXE ROM, SerialATA controller, etc. my last machine only had 4KB UMB space or so.. Bernd --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] Command.com 0.82pl3e-w: Mem.exe reports UMB corruption
Steffen Kaiser schreef: On Thu, 8 Jul 2004, Erwin Veermans wrote: Hello Erwin, would you please re-try all the steps you do with the non-swapping command pl3e. I wouldn't see in the changelog what might caused this behaviour. Bye, Erwin, please also try using MS's MEM.EXE, to see if the corruption problem is also present there. I'll see if I can verify your problem, did not try the 'w' release yet. (no time, was playing videogames :) ) Bernd --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
Michael Devore schreef: If you are using RAM without any parameters, EMM386 should not behave any differently than if it didn't exist. Standard UMB area scan occurs whether RAM is there or not. Only the optional range with RAM makes a difference, changing the default scan area size. And if you know your non-default range that well, why not just I= include and X= exclude within it? I still see scant evidence that RAM is anything but a weak option needed almost solely for minor MS-DOS compatibility sake. For compatibility reasons alone RAM should be in there, but not as a pressing issue. Same deal with HIGHSCAN and others. What makes the grade for adding to the option list right now, as a user-driven priority need? long term request, I guess. No need to implement it direct. Lower priority than VDS for example, but easier to implement. ..Except maybe that MS users may see a warning about the RAM parameter (hey, it's required in MSDOS, and now this replacement complains!!!) as Erwin demonstrated, FreeDOS apps should be, in best case, complete replacements instead of clones. (he uses FreeDOS kernel and MSDOS kernel on his Netware disk, but prefers FreeDOS programs as they are smaller + version independent) That means for example the line DEVICE=C:\DOS\EMM386.EXE RAM I=B000-B7FF in config.sys and then it should not matter if I replace the emm386.exe from msdos by the freedos version. a clone has the same functionality as the original, but only on the freedos platform. SYS for example, or unfortunately, FORMAT. What FreeDOS SYS could do if placed on a MS bootdisk would be: -take MS bootsector from source drive -insert it into bootsector area of target drive -patch the details so it works for harddisk. -copy io.sys/command.com/msdos.sys (as the freedos bootsector does not allow to boot msdos, we need to copy/patch the MSDOS bootsector for MSDOS operating system) Bernd --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] A000 to A001 possible change
At 12:53 PM 7/8/2004 +0200, Erwin Veermans wrote: I cannot oversee compatibility issues here and my interest would be that whatever is choosen it should be most compatible for most hardware around. So would it be an option to add an Arkady-A000 switch that will skip the A000-A001 ? Everybody happy? I don't agree with the option everything approach. This is one case whether the behavior definitively either should or shouldn't be present. Full MS-DOS compatibility camp says the A000-A001 changing code should not be there. Non-crashing standard FreeDOS kernel camp says maybe it's needed. In a perfect world, I'd say it should go. Fundamentally, it's an artificial limitation, regardless of how few people use linked DOS memory above 9FFF. But breaking things (if they do break) isn't worth the price. I base that opinion on the current standard FreeDOS kernel for Joe User, not forks, branches, enhanced, or experimental compiles. Change (or fix) the _standard_ FreeDOS distro, you change my opinion. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: Re: EMM386 VCPI/DPMI Help / Question
Eric Auer schreef: PS Bernd: Tell people to abort on the WHICHFAT critical error message. Then unformatted is reported as 0, and FAT12/16/32 are all reported properly. However, the kernel has to be fixed - there should be no interactive critical error message when detecting an unformatted drive at all! Just store the fact and return error 7, no DOS drive. Do not try to init the BPB further. are my FORMAT logs useful? I can't help you with the change kernel sources and other technical info. Currently, FAT12 users are out of luck: drive gets formatted because unformatted and FAT12 have the same errorlevel under freedos. MSDOS uses errlvl 1 for unformatted, and errlvl 12 is OK then. However, I don't know code to implement it: @echo off whichfat c: If errorlevel 16 goto skipwipe // don't format If %errorlevel%'==1 format c: // unformatted, msdos If %errorlevel%==12 format c: // unfortunately also wipes out FAT12 partitions with data on them there no critical error stuff. COMMAND /F (auto-fail) was needed for some operations. Perhaps a IF EXIST C:\*.* GOTO SKIPWIPE would help for FAT12. the problem is that a drive may have no files in root, only directories. In that case, no files are detected, drive is formatted, and bye bye data! Bernd --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] A000 to A001 possible change
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 available to programs 9 - a possibly used as UMB link, but not available a - a000f hidden by emm386 'change a000 to a001' a0010 - a available UMB ... old kernel, NEW a000 EMM386: 1 - 9 available to programs 9 - a possibly used as UMB link, but not available a - a available UMB ... AFAICS, the 9 - a range is used as UMB link, but in itself never available. the problems I saw are enable_UMB() dos_alloc() returns 8000-afff disable_UMB() however dos_alloc() returning 8000-afff should never be happen, as the UMB link area is used. arkady turbo kernel, NEW a000 EMM386: 1 - a available to programs if the a000-afff area is indeed merged into lower memory and UMB area starts at C, this might even work. however I still would prefer arkady to recompile emm386 and tell us if that works, instead of using mental input bandwidth of all people subscribed to this list. Finally, an idea that might even be used: I found that using EMM386 /IA000-Afff is dangerous. But the Numega SofyIce people had the idea to write a program LOADBIG MyProgram MyArguments that would merge A000-Afff into low memory run MyProgram MyArguments unmerge A000-Afff from low memory so I could run a very normal system; but on request (for make/compile jobs mostly) I could enjoy 64/96 K more memory. tom --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] A000 to A001 possible change
tom ehlert schreef: however I still would prefer arkady to recompile emm386 and tell us if that works, instead of using mental input bandwidth of all people subscribed to this list. didn't you use some commercial compiler? Eric didn't have it, and probably Arkady neither. compiling is troublesome that way. Bernd --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
[Freedos-devel] GRC and FreeDOS
I got this in an e-mail that was also sent to Steffen Kaiser. I haven't included Roland's e-mail address per the note -- Gregory: Hello, do you know that Steve Gibson(www.grc.com) is Considering spending $20,000 for DR DOS? There is a thread about this in news.grc.com/grc.spinrite.dev. He is still using FreeDos, and maybe he would be willing to invest some money into FreeDos if you would fix the problems he is is currently having with it. If you are interested go to the newsgroup and participate in the conversation. Also forward this email to other freedos developers if it's useful, but please remove my email address if you are going to post it in the mailing list, I don't want more spam. Roland -- Sie haben neue Mails! - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
[Freedos-devel] Announce: SORT 1.4 released
Hi, Tom pointed out that SORT was limited to sorting at most 15k of data. I fixed the problem by - compiling as EXE (do not forget to delete sort.com when installing the exe!!) - thereby making malloc and qsort use far pointers (there is no explicit far veraion of qsort, so I had to use a memory model with far pointers...) - reducing language file read buffers and language file storage buffers to 1k and 6k respectively - adjusting stack size to 6k and max line count to 12k and max line length to 8k respectively. That allows me to sort the first 10k lines of RBIL in a DOSEMU box where I have 626k free (- I can sort almost 400k of data :-)). You can still create a com version if you want one, use make sort.com for that purpose. This will allow you to sort up to 29k of data, up to 7000 lines of each up to 1023 chars size. SORT will also display the last line number when it runs out of memory while reading data now. Summary: SORT 1.4 can sort files and pipes of up to 400k size now, and it is an EXE file now. You can still compile a COM version, but it will be limited to file sizes of max 29k (SORT.COM 1.3: 15k). Maximum line length and line count when sorting with the normal (EXE) version of SORT 1.4 will is 8191 and 12000, respectively. http://www.coli.uni-sb.de/~eric/stuff/soft/ sort-09jul2004.zip Thanks to Tom for 1. reporting the bug and 2. being quite unhelpful and insulting when I asked for possible reasons and solutions. I finally found out myself in several steps: use farmalloc, use compact-model qsort, malloc list[] because it became too big (array of far pointers!) for being a stack var... Eric --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
[Freedos-devel] Re: Announce: SORT 1.4 released
Hi, I would like to add that: http://www.wordiq.com/definition/Quicksort Quicksort takes average O(n*log(n)) but worst O(n*n) comparisons, and average O(log n) but worst O(n) stack (and no head)... So I increased stack size of SORT to 16k, which means that it can sort up to 700 (roughly) identical lines (worst case). For sorting 1 lines from RBIL, even a tiny 6k stack was enough. I think there is no point in using 64k of stack just to be able to sort 3000 identical/unsortable lines of text, while this would on the other hand reduce the size of the biggest sortable file by those 48k of extra stack space. If you want some really huge files sorted, use CWSORT (- DJGPP), which uses protected mode (not sure for which stack size it is compiled and whether DJGPP supports auto-growing stacks. I think default stack size for Turbo C is 4k and for DJGPP it is 512k in recent DJGPP versions :-)). A really strange workaround would be using near pointers to an array of far pointers to save DOS stack. Current SORT seems to use up to 24 bytes of stack per qsort recursion level (far pointers). That would also allow using COM file format again, and some fancy custom malloc scheme (SORT never uses free(), so malloc() can be simplified). This is left as an exercise to the reader. I am happy with sorting 700 identical lines or 1 RBIL text lines with SORT 1.4 for now. Eric http://www.clipx.net/ng/turboc/ng4686d.php Turbo C qsort()... http://www.geocities.com/roryesperanza2/manuals/turboc20.txt Turbo C 2 handbook (600k)... RemarksAn implementation of median of three variant of quicksort of algorithm. http://www.sci.csuhayward.edu/~billard/cs3240/node32.html Quicksort and median-of-3... http://www.azillionmonkeys.com/qed/sort.html Sort optimizations and caveats http://www.devx.com/vb2themax/Tip/19472 Why median-of-3 might help http://www.cse.unsw.edu.au/~cs3121/03s2/exam/00midexam-solutions.html ... http://encyclopedia.thefreedictionary.com/Quicksort ... --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] Re: EMM386 VCPI/DPMI Help / Question
Hi Michael, I am 99.9% sure thar without RAM there is no UMB. I will check it tomorow. Alain Michael Devore escreveu: At 01:08 PM 7/8/2004 -0300, you wrote: Hi Michael, I would like to give you my opinion about the RAM option: I USE IT !!! And I have two reasons to use it: 1) it is easy and works on any machine and then I can just leave it working and go home :) If you are using RAM without any parameters, EMM386 should not behave any differently than if it didn't exist. Standard UMB area scan occurs whether RAM is there or not. Only the optional range with RAM makes a difference, changing the default scan area size. And if you know your non-default range that well, why not just I= include and X= exclude within it? I still see scant evidence that RAM is anything but a weak option needed almost solely for minor MS-DOS compatibility sake. For compatibility reasons alone RAM should be in there, but not as a pressing issue. Same deal with HIGHSCAN and others. What makes the grade for adding to the option list right now, as a user-driven priority need? --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
Re: [Freedos-devel] GRC and FreeDOS
I believe this is a very typical representation of FreeDOS development. Some people are optimizing it while critical problems (for some people) remain unsolved. Gregory Pietsch escreveu: I got this in an e-mail that was also sent to Steffen Kaiser. I haven't included Roland's e-mail address per the note -- Gregory: Hello, do you know that Steve Gibson(www.grc.com) is Considering spending $20,000 for DR DOS? There is a thread about this in news.grc.com/grc.spinrite.dev. He is still using FreeDos, and maybe he would be willing to invest some money into FreeDos if you would fix the problems he is is currently having with it. If you are interested go to the newsgroup and participate in the conversation. Also forward this email to other freedos developers if it's useful, but please remove my email address if you are going to post it in the mailing list, I don't want more spam. Roland -- Sie haben neue Mails! - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas 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/lists/listinfo/freedos-devel
