Re: [Freedos-devel] TDSK related issues.
Just for the record, I think the problem is that DEVLOAD only looks for block devices and will overwrite existing CDS entries if there is no associated block device. Which is the wrong thing to do. Regards, Christian -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] TDSK related issues.
Op 1-8-2011 15:29, c...@bttr-software.de schreef: Just for the record, I think the problem is that DEVLOAD only looks for block devices and will overwrite existing CDS entries if there is no associated block device. Which is the wrong thing to do. I hope there's a remedy to this, if this is the case. Your suggestion of the problem possibly/likely being DEVLOAD (instead of TDSK) is a good one though. I'd have to find other .SYS block device drivers to see how they behave under DEVLOAD, and other device driver loaders like Creative's CTLOAD and whichever program it was that QEMM had. Finding such drivers to test with isn't easy though, maybe SRDISK (GPL ramdisk) or MS RAMDRIVE.SYS will do the trick. Trying with USB drivers is a bit overkill though :) My workaround (abusing SHSUFDRV) will do fine, though a proper final fix would be better, be it DEVLOAD or TDSK requiring it. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK (was: EXE2BIN)
Op 30-7-2011 15:29, dos386 schreef: Got the answer ??? - LZMA decompressible on 8086: YES - LZMA vs NRV/UCL: LZMA (much?) slower decompression - Ultra-Brutal-Effect: much slower compression, no performance penalty on decompression (?) I did a quick test here by looking if UPX --ultra-brute --lzma --8086 generated smaller binaries than the one which are distributed in the MTCP/UPX file. And indeed smaller, so think Mike used default UPX settings ( --best --8086). It's indeed quite likely LZMA and UltraBrute options may at least cause slower loading (more decompression time required) or not work at all on 8086. If it does work however, awesome :) LZMA versus other alghorythms: likely slower indeed, but wasn't tested as Mike tested against uncompressed binaries (with longer DISK-reading time yet no time wasted on decompressing ofcourse). -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] TDSK related issues.
I hope there's a remedy to this, if this is the case. Yes; patch DEVLOAD (or get someone to do it). I'd have to find other .SYS block device drivers to see how they behave under DEVLOAD, and other device driver loaders like Creative's CTLOAD and whichever program it was that QEMM had. Finding such drivers to test with isn't easy though, maybe SRDISK (GPL ramdisk) or MS RAMDRIVE.SYS will do the trick. It should be sufficient to read DEVLOAD's source code for that. I looked into that stuff some time earlier (last year? or 2009?). Might have told Eric about it back then, too. In any case, I don't have my files or archived mails with me right now (not at home), but downloading DEVLOAD 3.21 and skimming the source code it would appear to me as if you would have to look into devload.asm around line 1360. Additionally, pay attention to where ever else it uses LastDrUsed or LastDrive. The check at around line 1300 probably has to be extended to search for a free CDS entry, and use that if found. While you're at it, you might review all phrasing that uses terms like LastDrive array in the comments - that appears to be a confusing way to refer to the CDS (array). The trickiest part about this patch is figuring out what to do with the List of Lists field referred to via the LastDrUsed variable here - this is supposed to be the count of installed block device units/(E)DPBs, but if there's non-consecutive (E)DPBs with redirector/CDEX CDS entries between them, should that counter reflect the number of actual (E)DPBs, or the (1-based) index of the highest (E)DPB? (Limited compatibility with programs that, like DEVLOAD currently, presume there are only (E)DPB-based CDS entries could be achieved by making it equal the index of the highest (E)DPB-based CDS entry. On the other hand, first, these programs are wrong anyhow, and second, I have a feeling that it should be the count instead. Oh well.) Unrelated: the software list says that the most recent version of DEVLOAD is 3.22, but I couldn't find that right away. Is that an error in the software list or did I just not find it? Regards, Christian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK
On 8/1/2011 7:31 PM, Bernd Blaauw wrote: Op 30-7-2011 15:29, dos386 schreef: Got the answer ??? - LZMA decompressible on 8086: YES - LZMA vs NRV/UCL: LZMA (much?) slower decompression - Ultra-Brutal-Effect: much slower compression, no performance penalty on decompression (?) I did a quick test here by looking if UPX --ultra-brute --lzma --8086 generated smaller binaries than the one which are distributed in the MTCP/UPX file. And indeed smaller, so think Mike used default UPX settings ( --best --8086). It's indeed quite likely LZMA and UltraBrute options may at least cause slower loading (more decompression time required) or not work at all on 8086. If it does work however, awesome :) LZMA versus other alghorythms: likely slower indeed, but wasn't tested as Mike tested against uncompressed binaries (with longer DISK-reading time yet no time wasted on decompressing ofcourse). I'm willing to get out the stopwatch and retest now that I know more. There was a question about the which of the algorithms (LZMA, NRV, UCL) is safe for GPL software. A quick review of the UPX web site did not give me a clear answer on which one was used when I specified -9 --8086 for options. Does anybody know off the top of their heads? Mike -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK (was: EXE2BIN)
Hi, Here it is (w/ srcs and one-byte diff): https://sites.google.com/site/rugxulo/XFDISK.ZIP?attredirects=0d=1 Nice size for a patch ;-) As for UPX terms, I could try LZMA and Ultra Brute settings indeed, but wonder what effect (decompression possible at all? loading times? memory uses? does resulting binary work?) they have on ancient machines. I think XFDISK, even at the best of times, only works on 286s on up. But I used --ultra-brute --lzma --8086 anyways I got the impression that lzma and ultra-brute are very slow to create and that lzma will use more CPU and RAM even when unpacking... So I would probably settle with something more humble, something like upx --8086 --best *.com which should still be quite decent in size reduction in particular when compressing typical relatively small DOS apps like we do. Eric PS: The above is based on intuition, not research. -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK
Hi, On Mon, Aug 1, 2011 at 8:20 PM, Michael B. Brutman mbbrut...@brutman.com wrote: On 8/1/2011 7:31 PM, Bernd Blaauw wrote: Op 30-7-2011 15:29, dos386 schreef: Got the answer ??? - LZMA decompressible on 8086: YES - LZMA vs NRV/UCL: LZMA (much?) slower decompression - Ultra-Brutal-Effect: much slower compression, no performance penalty on decompression (?) I did a quick test here by looking if UPX --ultra-brute --lzma --8086 generated smaller binaries than the one which are distributed in the MTCP/UPX file. And indeed smaller, so think Mike used default UPX settings ( --best --8086). It's indeed quite likely LZMA and UltraBrute options may at least cause slower loading (more decompression time required) or not work at all on 8086. If it does work however, awesome :) LZMA versus other alghorythms: likely slower indeed, but wasn't tested as Mike tested against uncompressed binaries (with longer DISK-reading time yet no time wasted on decompressing ofcourse). I'm willing to get out the stopwatch and retest now that I know more. There was a question about the which of the algorithms (LZMA, NRV, UCL) is safe for GPL software. A quick review of the UPX web site did not give me a clear answer on which one was used when I specified -9 --8086 for options. Does anybody know off the top of their heads? I'd have to let Jim answer since he was directly involved. But I *think* all UPX'd binaries [sic] are okay (GPL-friendly), it's just UPX proper (default .EXE download using closed source NRV library) is not free. So it's preferable to suggest people use UPX-UCL instead. If you use UPX-UCL (and compare to default .EXE), you will notice that UCL compresses slightly worse than NRV (though only slightly, we're not talking probably even 5%). But if you use LZMA, output should be identical. So I don't think you have to worry, but I'm not a lawyer (nor Jim's spokesperson), so you'd have to ask one of them instead. ;-) -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX and XFDISK
Hi! There was a question about the which of the algorithms (LZMA, NRV, UCL) is safe for GPL software. A quick review of the UPX web site did not give me a clear answer on which one was used when I specified -9 --8086 for options. Does anybody know off the top of their heads? I personally would say they are all safe, but because NRV is closed source, it would be bad for Debian evangelists to use that. To have the toolchain itself open source, you have to use UPX-UCL. Each UPX tool only supports either NRV or UCL as far as I remember and the default download on the UPX homepage is NRV, but Rugxulo et al do deliberately use UPX versions compiled with UCL style which is only a bit less effective than NRV. As said, UCL is open source, as is the LZMA compression which is rather new, included in all newer UPX binaries (both UCL and NRV style ones) sometimes (in particular for larger apps) more effective in compressing and always much slower in compressing. LZMA is also likely to be slower in uncompressing (i.e. when you run compressed apps) and likely to use more RAM for both compressing and uncompressing. So far my F.U.D. about LZMA ;-) Eric -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
