Hi, N.B. All tests I'm re-running below are using old stock 2006 TC build of FreeCOM. I'm just telling you the times and success for rough comparison of what I'm seeing and what is normally expected (by me).
BTW, "tests /t oberon16" succeeds and only takes 29 secs. On Fri, Oct 19, 2018 at 12:16 PM Tom Ehlert <t...@drivesnapshot.de> wrote: > > > Here's the DropBox link (again), in case it wasn't obvious: > > > * https://www.dropbox.com/s/6whjgmb9xhdgw29/metados-0.7.zip?dl=0 > > anyway, I downloaded this, and replaced the 32-bit system\unzip.exe > with 16-bit unzip.exe from > ftp://ftp.info-zip.org/pub/infozip/msdos/unz600x3.exe > which makes everything behave *much* faster under VirtualBox. This ancient Core i5 (Nehalem Westmere) from 2011 has VT-X. I read somewhere that most machines (since 2015?) have it now, too. It helps a lot in speed. Most tests are simple and fast enough either way, but some are admittedly too slow (e.g. p7zip). > then I created 3 instances of this machine, replacing command.com > by commandT/W/G.com in https://github.com/FDOS/freecom/releases/tag/com084pre6 > > everything else identical. > tested on Windows-32, VirtualBox, 256 MB machine size. > > the idea is that they should behave identical. They don't. > ********************************************************************* > restart machine. BTW, you can use Host (Right Ctrl, aka StrG) + R to reboot VBox. I also included a simple reboot.com (mostly useful for QEMU), but I don't recall it working correctly under VBox (at the time). > TESTS JWASMDJ > > after 1572 seconds, everything seems to have worked. > ok it worked, but slow as molasses. Newer DJGPP (GCC) is even bigger and slower, believe it or not. But some code can't run on ancient versions. (Even NASM 2.x requires C99 since 2005, hence you probably need GCC 3.2.3 or newer, IIRC.) This one succeeds for me in 2 min. 5 secs. (And it successfully rebuilds Xgrep.) > ********************************************************************* > restart machine. > TESTS CTAGS > all 3 fail quickly with a ctags58.zip problem. might be a unzip.exe bug. IIRC, this is trying to download from SF.net, so you need the "new" Wget runnable first. It succeeds in 21 secs. for me. > ********************************************************************* > restart machine. > TESTS PICOC This one succeeds in 52 secs. for me. > ********************************************************************* > restart machine. > TESTS P7ZIP > > aborted on all 3 machines after waiting forever. identical bug, or no freecom > bug at all. IIRC, it needs 512 MB of RAM (or, more specifically, 256 MB free on the RAM disk). Hmmm, I should've documented that in the .BAT. (BTW, "tests p7zip edit" is convenient.) Also it downloads source from SF.net, so you need "new" Wget again. Also slow as molasses. I think it once took me like five hours (!) without VT-X. (I think it was 11 hours until I avoided LFNs entirely!) But with latest VBox and VT-X enabled (Nehalem Westmere, which is more DOS-friendly), it just now "only" took me 13 minutes. > ********************************************************************* > restart machine. > TESTS NASMWAT > all 3 report 'bad command or file name "tar.exe", but proceed > in the end, all 3 fail in identical way. Yeah, it's failing to download Tar (via FTP), for some unknown "new" reason. (Don't you just love that? Ugh!) Trying "tests /t nasmwat djtar" succeeds for me in 47 secs (new Wget) or 1 min. 2 secs. (FTP). I was somewhat obsessed with having a modern NASM build (or two) that ran in all environments. I absolutely didn't want us having to rely on an old, 16-bit build, 0.98.39 only, that nobody could ever upgrade. And mixing DJGPP or OpenWatcom binaries together usually won't work, has compatibility issues (esp. with Wmake, but WmakeR is probably okay). I intend to add another .BAT for latest NASM 2.13.03 (using DJGPP) one of these days, but I've been too preoccupied. > ********************************************************************* > restart machine. > TEST KE2041 > > freecomW fails with 'bad command or filename - "patch.exe" You have to be careful here. The DJGPP people often delete old versions and put new ones in its place. So downloads will break, unfortunately. But it's a simple edit of a .BAT to fix that. Still unfortunate. (Maybe not the exact problem here but still worrisome.) BTW, this succeeds in 1 min. 21 secs. > ********************************************************************* > summary: > > both watcom and gnu builds have at least one bug left. We're getting there. Yes, it'd be great (huge understatement) to have GCC IA-16 able to build the kernel and shell (without regressions). Bart and you (et al.) have done great work. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
