Re: [Freedos-devel] Updated INSTALL program
Hi, On 7/10/11, Jim Hall wrote: > >>> I already looked at this. libzip requires 'configure' as the first >>> step to build it, which assumes a Unix-like environment. To build on >>> DOS using OpenWatcom requires reverse-engineering their Makefiles and >>> configuration options. Well, I (wrongly / blindly) assumed that "OW19/contrib/libzip/wlib/makefile" would build (oops, apparently not). Oddly enough, the makefile uses LFNs but for some reason the .c files themselves are SFN! (zip_add.c vs. zadd.c) And yes, OW 1.9 *does* ship their DOS-based installer (ZIP .sfx) using libzip (but only "old" 0.6.1 from 2005). Who knows, cross compile most likely, though wcc386 for DOS still can't handle LFNs anyways. >> Actually a big part of EDLIN is the autoconf script, so yes you >> can easily use that and configure on DOS, BTW, I've done so once or twice! ;-) > but of course it does >> feel a bit like a waste of space given that DOS systems do not >> differ that much from each other, Well, not all DJGPP installs are the same (2.03p2? 2.04? extra stuff installed? all latest versions? enough POSIX utils (fil + txt + shl = core)? buggy Bash? additional libs needed?). But of course I agree, it's not reasonable to expect a full POSIX suite on DOS. >> a makefile would be enough and >> would avoid the need to have various configure tools installed. I agree completely, more than most, but sadly *nix programmers don't care about anyone but POSIX. They just would rather drop DOS completely than bother with a tiny workaround. >> PS: Maybe Rugxulo can come up with a static DOS libzip makefile. > > I'd appreciate the help! Rugxulo, if you could craft an OpenWatcom & > WMAKE makefile that compiles a status libzip.lib (using -ml) then that > would be a big step forward. Well, as mentioned in private mail, I did build it for "large" model (16-bit), but the examples (zipcmp, zipmerge) didn't work correctly. It may be a (very tiny) stack (default size) issue, who knows. I suspect it's just that the authors never intended anything but 32-bit machines to ever use it. Anyways, it *does* work with 32-bit OW19 builds, thankfully, so you *could* use that if interested. Here's a rough .BAT that shows what I've done (again), just in case anybody wants to try it themselves for whatever reason. (Don't feel obligated, of course, I'm just offering it anyways "just in case!" I know it's far from crucial.) P.S. ow19-libzip.zip is just a verbatim (but very tiny, specific, partial) excerpt from OW19's stock sources. https://sites.google.com/site/rugxulo/ow19-libzip.zip?attredirects=0&d=1 http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/9.13/ http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/openwatcom/1.9/ http://www.zlib.net/ @echo off REM Apologies for LFNs, tested on WinXP. But you get the idea ... cd \tmp dir :: open-watcom-c-dos-1.9.7z :: ow19-libzip.zip :: zlib-1.2.5.tar.gz cd \ p7zip x tmp/open-watcom-c-dos-1.9.7z call watcom19\owsetenv.bat cd \tmp pause p7zip x ow19-libzip.zip cd ow19\contrib p7zip x ../../zlib-1.2.5.tar.gz p7zip x zlib-1.2.5.tar del zlib-1.2.5.tar ren zlib-1.2.5 zlib cd zlib set DOS4G=quiet wmake -f watcom\watcom_f.mak ren zlib_f.lib zlib.lib pause REM WinXP crashes the NTVDM CMD shell here, so I have to manually reopen (sigh) REM REM cmd.exe REM \watcom19\owsetenv.bat REM cd\tmp\ow19\contrib\zlib cd ..\libzip\lib set DOS4G=quiet for %%a in (*.c) do wcc386 -zq -wx -oaxt -I..\..\zlib %%a dir /b *.obj > libzip.txt wlib -q libzip.lib @libzip.txt cd ..\src ren *.c *.c~ :: yes, these should all be smaller than 126 bytes, I'm using DOS-hosted OW19 !! sed -e "/config\.h/s/^/\/\//" -e "s/\(#define\) PROG.*/&\n\1 PACKAGE \x22\x22\n\1 VERSION\x22\x22/" zipcmp.c~ >zipcmp.c sed -e "/config\.h/s/^/\/\//" -e "s/\(#define\) PROG.*/&\n\1 PACKAGE \x22\x22\n\1 VERSION\x22\x22/" zipmerge.c~ >zipmerge.c for %%a in (*.c) do wcl386 /bt=dos /l=causeway /oaxt /wx /zq %%a /I..\..\zlib -I..\lib ..\lib\libzip.lib ..\..\zlib\zlib.lib :: upx --best --lzma zipcmp.exe zipmerge.exe pause :: copy /b z:\befi-wip\old\befi_*.old *.zip :: for %%a in (2z 3a) do lgzsp befi_%%a.zip :: zipcmp befi_2z.zip befi_3a.zip -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
> >>> The TZ variable is used in Unzip or the UzpMain() library, not >>> (strictly speaking) in the Install program. Not having the timezone >>> set just results in a warning... > > ...which can be ignored / scroll away. Actually setting > a timezone can lead to more counterintuitive results > than the ignoring the warning afair ;-) > >>> To keep the warning from coming up, the >>> included Unzip program sets TZ with a PST value > > As suggested elsewhere in the thread, it is probably > better to set TZ - if at all - before calling the > default UNZIP. Instead of having a modified UNZIP. > It is always nice to have a standard full featured > version of INFO-ZIP UNZIP, also for manual use... > I prefer that the Install program be able to complete without throwing a warning. Otherwise, we will get lots of questions from new users asking "why am i getting this TZ message?" Of course, the install CD could set that before running the Install program. For a user installing FreeDOS 1.1 from the distro, I don't see a big problem if the TZ is off WHEN UNZIPPING PACKAGES TO THE HARD DRIVE. When you're running FreeDOS afterward, yes that's a problem. But during the install process, having the TZ be off by 12 hours isn't that big of a deal. That may be the simple view, but that's how I see it. -jh-- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
> >> CST, EST and UTC are confusing me. All I know is GMT, which would be >> UTC? SET TZ=UTC (and be done with it, unset right after install) > > CST = U.S. Central Standard Time (Chicago, etc.) -> me > EST = U.S. Eastern Standard Time (Florida, etc.) > > Can't remember if Pacific (PST) is same as Mountain, most likely yes. > (Jim is in Minnesota, can't remember what he is, probably Central > also.) Yes, I am in Minnesota, which is CST. I happened to pick PST for the TZ variable only because it was the example from the Unzip man page. ;-)-- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
Hi again, On 7/12/11, Bernd Blaauw wrote: > Op 12-7-2011 18:51, Rugxulo schreef: > > I was more thinking of running INSTALL for each disk. Pity we lack an > INKEY option like 4DOS has. It's a mixture between CHOICE (single key > except special keys) and SET /P (input requires pressing ENTER to confirm). I'm sure somebody has a small util for that, if direly needed. (J. Hoffman's DOSUTILS?) Or it could be whipped up pretty easily. > I've always disliked (UN)ZIP with so many switches/options, confusing me > a lot. PKZIP itself had quite a lot, too; though, admittedly, UNZIP 6.0 has way more than before! (See "-h2" for second help!) > CST, EST and UTC are confusing me. All I know is GMT, which would be > UTC? SET TZ=UTC (and be done with it, unset right after install) CST = U.S. Central Standard Time (Chicago, etc.) -> me EST = U.S. Eastern Standard Time (Florida, etc.) Can't remember if Pacific (PST) is same as Mountain, most likely yes. (Jim is in Minnesota, can't remember what he is, probably Central also.) >>> If you do, please use UPX-UCL instead of NRV. >> >> If you use --lzma, it doesn't matter as they should be identical >> anyways. But yes, otherwise use UPX-UCL 3.07 (latest): >> >> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/upx/v3.07/ > > Thanks for pointing me to that. Disadvantage of 586+ binaries though > instead of 386 (or even 8086 but doubt UPX runs on that at all). Not > sure what minimum platform is. GCC and DJGPP don't do anything specific to 486 or 586, AFAICT (neither of which added barely any instructions anyways, nothing hugely useful for general purpose stuff). IIRC, GCC never did anything for 486 (vs. 386) but extra alignment. GCC 2.8.1 (1998) was the first to even support 586s, and all it does there is instruction (re)scheduling for the U/V pipelines. It's only with -march=i686 (aka, pentiumpro, in GCC [incorrect??] terminology) that uses extra instructions, e.g. CMOVxx series. And I didn't use that, only safer "mtune" (and only "just in case" it sped up somehow, just for completeness and convenience). At least, I've run previous UPX-UCLs on my (now disconnected) 486 Sx without issue. There *may* be an implicit FPU requirement (esp. since GCC itself always assumed an FPU), but you can put a small 40 kb .dxe emulator file there if necessary (dunno without testing again but personally doubt it's needed). -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
Hi, On 7/12/11, Jim Hall wrote: >> >> BTW, feel free to nag some of us to (re)translate for Install. I see >> your /nls/ directory already has 12 languages (or perhaps 11 not >> counting .en). > > I will definitely need help in translating the strings, but I figured > I would wait to ask for that help until after I normalize the strings. Whenever you finish (to your own goals and timeline), then and only then will we translate. Just be sure to remind us!! (short attention span) > Yes, I'm not worrying about floppy-based installs. For right or wrong, > I consider floppy-disk-only installations to be a small "edge" use > case. Speaking as one of the few people who made his own "unofficial" craptastic mini-distro (three floppies) circa 2008, it's obvious that (almost) nobody cares. I'm probably one of the only ones left!! BUT, I have no intention of not helping someone who wants or honestly needs it. So I'm willing to provide tips etc. for those who need it (probably rare but ya never know). EDIT: If I had set up better and it wasn't so fragile to update and I didn't have so many hardware (and intermittent personal) issues, I would've updated it again by now. Alas. Good thing nobody cares, heh, ugh, I'm off the hook! I keep thinking about better ways to maintain it, e.g. virtual machine, but so far I've never bothered. P.S. Wasn't beta 8 (2001?) the last to have an official, full floppy install? I still have it in the other room. Might be interesting to look at again, for laughs. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
Hi, sorry for replying the same thread twice... Thanks to Bernd for the very verbose testing and pointing out so many corner cases, impressive :-) >> * Suppose I'd be a complete newbie to DOS: how do I know what to type >> there? (a.k.a what's valid input). >> * Absolute paths required? Relative paths seem to be supported, in which >> case there's attempts to create subdirectory structure in current >> directory. Which won't work ofcourse from cdrom >> * Path isn't checked/created before starting unzipping, depending on >> UNZIP itself instead to create directories? Or rather you're not >> returned to initial inputfield. >> * Try typing NUL into that field >> * Try typing C:\DUMMY\FDOS in there if C:\DUMMMY doesn't exist > > For the above: I'm thinking about simplifying the input even further, > asking for just the install *drive* and not a a full path. We can > assume installing to \FDOS (such as C:\FDOS). How about accepting both, and assuming a default directory name when only a drive letter is given? Then you still give the users freedom to call FreeDOS DOS, FDOS, FREEDOS etc. Of course that will need some checks - the target must not be a device or file, the target directory must exist or be createable, it must be writeable, the target drive must be writeable, existing and preferrably FAT (otherwise no SYS) and it should have enough space and fully use 8.3 syntax. > I'll add some level of confirmation of values before installing, and > an easy way to "gracefully" abort the install if the user chooses to. Thanks :-) >> SCREEN: DONE >> * No input on how to proceed/finish (pressing any random key?) > > I will add a "press any key" message. I'll borrow the NLS string from > the CHOICE program. Depending on what happens next, INSTALL could exit with a big (visible from across the room) and nice message without wait. > But I wonder if anyone really installs FreeDOS from floppies in 2011? As said, not many, and those can XCOPY a floppy distro or read a howto for mounting a DOS ISO which they downloaded directly to their FAT partition from within Windows anyway for the case where booting is the only part using floppy. >> * INSTALL expects/assumes user has validated that the input is >> 1) a directory (try C:\KERNEL.SYS as input if it exists as file) >> 2) on an existing driveletter >> 3) on a drive >> 4) FAT12/16/32 >> 5) with enough free diskspace >> 6) valid input Makes sense for INSTALL to check all those for the target. >> Question: can PACKAGES\subdirs\*.LSM now be deleted? Install doesn't >> give descriptions anymore of individual packages anyway. > > Correct, the LSM files are no longer required. Actually I liked knowing the version numbers of everything that way, but one file which concats all LSM info will be fine for me, saving lots of cluster overhead space compared to using many separate tiny LSM files. Probably INSTALL can have the LSMs in the package ZIP but copy the text to a big file and remove the individual ones after installing... ;-) >> scripting possibilities for: >> 1) source directory >> 2) destination directory >> 3) automation (accepting source input by default, and finish last screen Sounds useful. >> 3 seconds or so after being all done) Not useful imho. >> 4) /ALLSETS or /BASEONLY ; /NOSOURCE ; /QUIET Shrug. >> Yes, usable, will integrate it. Thanks for the work so far. >> (and I'll throw UPX over it to reduce size of binaries) > > If you do, please use UPX-UCL instead of NRV. Nice idea :-) Eric -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
Hi guys, >> That message comes from the Unzip program. I got that too, during >> testing, but I rebuilt the zip file it was complaining about, and the >> error didn't reappear. I think the problem was mixed case in the zip >> package file. > > Ah, now I think I know what you mean. I think that should be easily > fixable by using -C (or, as I typically do, "set UNZIP=-C"). Info-Zip > is pretty *nix-oriented in portability (as always), so they default to > case sensitive and (unlike PKZIP) compress with lowercase filenames. > But of course DOS (FAT) doesn't care. I vaguely remember ZIP files which mix forward and backwards slashes for directory separator depending on how you parsed the metadata... Also, Mac OS produces ZIP files with lots of garbage meta files in them. I hope INFO-ZIP for Mac does not. >> But I wonder if anyone really installs FreeDOS from floppies in 2011? Not many, and those can just use XCOPY from a floppy distro IMHO. >> The TZ variable is used in Unzip or the UzpMain() library, not >> (strictly speaking) in the Install program. Not having the timezone >> set just results in a warning... ...which can be ignored / scroll away. Actually setting a timezone can lead to more counterintuitive results than the ignoring the warning afair ;-) >> To keep the warning from coming up, the >> included Unzip program sets TZ with a PST value As suggested elsewhere in the thread, it is probably better to set TZ - if at all - before calling the default UNZIP. Instead of having a modified UNZIP. It is always nice to have a standard full featured version of INFO-ZIP UNZIP, also for manual use... >>> * Documented that InfoZip's UNZIP is required/expect Note: The Advancemame advzip (or similar name) is a nice way to recompress ZIP files better while still keeping them fully compatible with INFO-ZIP UNZIP and all other normal unzippers :-) > (overthinking) I guess in theory you could "unzip -l *.zip" Afair INFO-ZIP unzip -1 xyz is the same as zipinfo xyz. Indeed an idea to check needed disk space, but given that you would also have to round for cluster size it might not be worth the effort. UNLESS you just assume 32 kB (or any big default) cluster size and simply be happy if DOS leaves more space free than estimated :-) Eric -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] UPX compression for DOS apps
Hi, On 7/11/11, Michael B. Brutman wrote: > > I tested UPX on one of the slowest machines that I have that has a hard > drive. On a PCjr with a NEC V20 and XT-IDE adapter UPX compressed > executables worked, but they took noticeably longer to start up: > > FTPSRV: original was 2 seconds, with UPX is 5 seconds > PING: original was 1 second, with UPX is 2 seconds Not too bad, honestly. I think p7zip (several MB) took longer when using LZMA on my 486 (esp. compared to --best). But it really only matters for stuff you execute / invoke a lot. I'm not sure people use PING enough to be a problem. (But perhaps others would be more sensitive.) YMMV. Even WinXP has a penalty for UPX'd DJGPP stuff, strangely. So it's not just slow machines. (And this hurts when compiling, so you have to be careful of that, and it's been abandoned as default for a while now.) > The V20 makes the machine a little faster than a standard 8088 based > machine. The XT-IDE adapter is slow as far as hard drive controllers > go; on a real XT the delay would be more pronounced because the > controller is far better. But on an 80286 or better I'm sure that the > difference is not noticeable. Dunno without testing. > I think that most people are running on faster hardware with plenty of > storage space, so this is interesting but probably not worth making part > of the build process. (Is my instinct correct here? I think I'm one of > the few nut jobs on 8088 based hardware, because it's fun!) Yeah, it's interesting but probably not practical. (So what? ) But yeah, there aren't many 8088 gurus / geniuses out there: Trixter, you, RubberMallet, DeathShadow. That's all I can think of off the top of my head. (I don't and never had any 808x machines, but it's a classic, IMHO, so I've often written 8086-only stuff, esp. since it doesn't hurt much, if at all, on newer machines.) > On a slightly off topic note, I need to learn to build FreeDOS. I > suspect it doesn't like my PCjr and I'm going to have to fix that. :-) If you're trying to build _on_ your PCjr, try TC201. The kernel is actually pretty simple to build, but you'll need NASM (0.98.39 on SourceForge has a 16-bit binary) and maybe FreeCOM binary as shell (dunno why). FreeCOM also should build with TC (haven't tried Bart's OW port in SVN yet). IIRC, my tweaked P166 took 90 secs. to build the kernel, if that gives you any (very rough) idea of how long it'll take. It's been a while, and it's not like I ever needed to rebuild that stuff a lot, so I can't remember. CONFIG.B -> something something. Anyways, if you run into trouble, just nag us, and some of us can help. :-) -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
On Tue, 12 Jul 2011, Bernd Blaauw wrote: > I was more thinking of running INSTALL for each disk. Pity we lack an > INKEY option like 4DOS has. It's a mixture between CHOICE (single key > except special keys) and SET /P (input requires pressing ENTER to confirm). I thought PAUSE...? > CST, EST and UTC are confusing me. All I know is GMT, which would be > UTC? SET TZ=UTC (and be done with it, unset right after install) More or less. Stuff I've written in C tends to assume "EST5EDT" (Eastern Time, US/Canada) as the timezone, I think that's what the libcs tend to do. -uso. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
> If wanting things really fancy, organise sourcecode such that: > * NLS is used (KITTEN), optionally using external language files. > Lacking that, using internal strings. > * INSTALL can be compiled without an external strings file > * INSTALL can be compiled for a certain language with an external > strings file. > > I think David 'o Shea did so in 2006 for MEM binaries. > ( http://www.employees.org/~doshea/freedos/tmp/ ) > http://www.employees.org/~doshea/freedos/tmp/mem.htm > (last few lines of the page, not sure any of this code made it into > mainline MEM 1.11 (which replaced Arkady's MEM program)) Kitten-c is already in the source tree for Install, I never removed it. I just haven't used it in the new Install yet, but I intend to use Kitten for NLS support. > It's not 100% fullproof, but if free diskspace is at least a few MB, > then I'd assume the drive is writable and at least BASE would be > unpacked/installed. Non-existing drives have no free diskspace, and > neither do CD-ROMs for example. > Actually checking if the drive is writable could be done by creating the > target destination directory. Problem is when it already exists :) > Perhaps some tempfile. Tempfile seems the best method. > I've got 2 feature requests: > * don't show the "BASE or EVERYTHING" question if only PACKAGES\BASE\ > exists or PACKAGES\BASE\somefile.zip. > * at end of installation, switch to the target/installation directory, > so POSTINST can run and set DOSDIR to %_CWD% (current directory). Always > disliked the trick of using LOCATE.COM to find FreeDOS directory. I'll add these to the TODO list. -jh -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
Op 12-7-2011 18:51, Rugxulo schreef: > Hi, > > Homer: "Where's the any key???" :-)) yeah, people asking where the any key is, in 2011 :) > BTW, feel free to nag some of us to (re)translate for Install. I see > your /nls/ directory already has 12 languages (or perhaps 11 not > counting .en). I wonder if I made the dutch translation..it needs fixing. Not sure which strings are relevant and correct in the english file. If wanting things really fancy, organise sourcecode such that: * NLS is used (KITTEN), optionally using external language files. Lacking that, using internal strings. * INSTALL can be compiled without an external strings file * INSTALL can be compiled for a certain language with an external strings file. I think David 'o Shea did so in 2006 for MEM binaries. ( http://www.employees.org/~doshea/freedos/tmp/ ) http://www.employees.org/~doshea/freedos/tmp/mem.htm (last few lines of the page, not sure any of this code made it into mainline MEM 1.11 (which replaced Arkady's MEM program)) >>> * SUBST/JOIN usable for floppy install? 'mount' floppy files in some >>> dummy "PACKAGES\BASE" directory? >> >> The new Install assumes a CDROM install source, and reads all the >> packages at the beginning (so it understands the total number, used in >> progress bar) then installs the packages. To do this using floppies, >> the Install program would need to be refactored. I was more thinking of running INSTALL for each disk. Pity we lack an INKEY option like 4DOS has. It's a mixture between CHOICE (single key except special keys) and SET /P (input requires pressing ENTER to confirm). > I'm sure somebody weird (ahem) will probably still do it, but it's > probably rare now that floppies are almost discontinued. Anyways, if > anybody needs to install, they can come to the mailing lists and we'll > guide 'em manually. I've always disliked (UN)ZIP with so many switches/options, confusing me a lot. > IMHO, you (Jim) shouldn't worry about floppies at all right now. Leave > that until after you take care of CD-ROM users (the majority). Agreed. > sure I was ever correct anyways. Yes, typically I set "TZ=CST" > (central) though perhaps the full is something like "CST4DST" (or > something, I forget and this computer doesn't have it set, doh). CST, EST and UTC are confusing me. All I know is GMT, which would be UTC? SET TZ=UTC (and be done with it, unset right after install) >> The only way I can figure to test if the destination has enough space >> is to use hard-coded values for how big FreeDOS 1.1 will be after it >> is installed (with/without all packages, with/without source code.) It's not 100% fullproof, but if free diskspace is at least a few MB, then I'd assume the drive is writable and at least BASE would be unpacked/installed. Non-existing drives have no free diskspace, and neither do CD-ROMs for example. Actually checking if the drive is writable could be done by creating the target destination directory. Problem is when it already exists :) Perhaps some tempfile. > > (overthinking) I guess in theory you could "unzip -l *.zip" and > somehow sum up all the totals (awk?). I mean, if you wanted to do it > the fancy automated way. ;-) But I think your way is plenty good > enough for the foreseeable future. (Better than nothing!) I'd more think of a parameter to give to INSTALL: /MINFREESPACE=5MB >> If you do, please use UPX-UCL instead of NRV. > > If you use --lzma, it doesn't matter as they should be identical > anyways. But yes, otherwise use UPX-UCL 3.07 (latest): > > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/upx/v3.07/ Thanks for pointing me to that. Disadvantage of 586+ binaries though instead of 386 (or even 8086 but doubt UPX runs on that at all). Not sure what minimum platform is. I've got 2 feature requests: * don't show the "BASE or EVERYTHING" question if only PACKAGES\BASE\ exists or PACKAGES\BASE\somefile.zip. * at end of installation, switch to the target/installation directory, so POSTINST can run and set DOSDIR to %_CWD% (current directory). Always disliked the trick of using LOCATE.COM to find FreeDOS directory. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
>>> * Documented that InfoZip's UNZIP is required/expect, and no others >>> supported (7ZIP, PKZIP, UNRAR, TUNZ, 7ZDECOD etc) ? >> >> I'll add a note in the docs. But this is one reason that I'd prefer to >> use UzpMain() or some other internal library to unzip/install >> packages. Again, if anyone can figure out why this doesn't work >> (currently using InfoZip's Unzip 6.0) I'd appreciate the help. > > Info-Zip did used to have a forum online (at least a year or two ago). > You could probably post there or e-mail Ed Gordon (I think? that was > his name). > > Or post to news://comp.compression. > > Or use a different unpacker / installer: Gautier's zip-Ada, > OpenWatcom's (old) libzip used by their installer, FreePascal's unzip > / installer. > > In short, I need to find time today (shouldn't be too too hard) to > *try* to recompile OW's libzip statically for you. > > The stack "bug" in UzipMain() could be anything, so I have no idea, > and my C skills are limited. I'd have to look closer. > Haven't asked there yet. I'll do that. But I'd appreciate help in getting any "unzip" library to work. Odd that UzpMain() works with the unzip.c "wrapper" but barfs if used in the Install program. -jh -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
>>> SCREEN: DONE
>>> * No input on how to proceed/finish (pressing any random key?)
>>
>> I will add a "press any key" message. I'll borrow the NLS string from
>> the CHOICE program.
>
> Homer: "Where's the any key???" :-))
>
> BTW, feel free to nag some of us to (re)translate for Install. I see
> your /nls/ directory already has 12 languages (or perhaps 11 not
> counting .en).
I will definitely need help in translating the strings, but I figured
I would wait to ask for that help until after I normalize the strings.
I may be able to re-use text from Install 3.x, so I could re-use the
NLS strings from that. Or I might borrow some strings from other
programs (FreeDOS CHOICE "Press any key..") and re-use their NLS
strings too.
>>> * SUBST/JOIN usable for floppy install? 'mount' floppy files in some
>>> dummy "PACKAGES\BASE" directory?
>>
>> The new Install assumes a CDROM install source, and reads all the
>> packages at the beginning (so it understands the total number, used in
>> progress bar) then installs the packages. To do this using floppies,
>> the Install program would need to be refactored.
>>
>> But I wonder if anyone really installs FreeDOS from floppies in 2011?
>
> I'm sure somebody weird (ahem) will probably still do it, but it's
> probably rare now that floppies are almost discontinued. Anyways, if
> anybody needs to install, they can come to the mailing lists and we'll
> guide 'em manually.
>
> IMHO, you (Jim) shouldn't worry about floppies at all right now. Leave
> that until after you take care of CD-ROM users (the majority).
Yes, I'm not worrying about floppy-based installs. For right or wrong,
I consider floppy-disk-only installations to be a small "edge" use
case.
(OT) See also this note about archives on floppies:
http://ascii.textfiles.com/archives/3191
>>> * TIMEZONE stuff required? Didn't notice anything going wrong besides
>>> sometimes a warning. Any documentation for what is valid input for TZ?
>>
>> The TZ variable is used in Unzip or the UzpMain() library, not
>> (strictly speaking) in the Install program. Not having the timezone
>> set just results in a warning. To keep the warning from coming up, the
>> included Unzip program sets TZ with a PST value, if TZ is not already
>> set, just to suppress the warning message.
>
> Worse is that the timezone rules changed a few years back. Honestly, I
> don't know the lower-level details, and you're probably not using a
> DJGPP compile anyways. (Does any other compiler runtime support
> timezones?) And I'm fairly certain their rules are the old ones
> anyways. In short, it's far from perfect in DOS, but for someone like
> me, I don't care. (I've only been bitten by it once, IIRC, when
> unpacking something very fresh from "the future", i.e. U.K., which is
> a few hours ahead of me, heh.) I can't remember the full syntax, not
> sure I was ever correct anyways. Yes, typically I set "TZ=CST"
> (central) though perhaps the full is something like "CST4DST" (or
> something, I forget and this computer doesn't have it set, doh).
The included unzip.c - wrapper to UzpMain() - does this:
/* set TZ env variable, if not already set */
if (getenv("TZ") == NULL)
{
setenv ("TZ", "PST8PDT", 1); /* env.h */
}
I'm thinking about moving this into the Install program, in case the
external UNZIP program is the "stock" InfoZip UNZIP, so the TZ
variable is always set. Also needed if I can move to UzpMain().
-jh
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
>>> SCREEN: INSTALLING:
>>> * Sometimes getting the "caution: excluded filename not matched:
>>> SOURCE/*" when answered No to both questions. Seems odd. When selecting
>>> to not install sources, no messages related to them are expected.
>>
>> That message comes from the Unzip program. I got that too, during
>> testing, but I rebuilt the zip file it was complaining about, and the
>> error didn't reappear. I think the problem was mixed case in the zip
>> package file.
>
> Ah, now I think I know what you mean. I think that should be easily
> fixable by using -C (or, as I typically do, "set UNZIP=-C"). Info-Zip
> is pretty *nix-oriented in portability (as always), so they default to
> case sensitive and (unlike PKZIP) compress with lowercase filenames.
> But of course DOS (FAT) doesn't care.
>
Thanks for the suggestion, but "-C" was already being used in pkginst.c.
:-)
/* unzip */
if (do_source)
{
/* cputs ("DEBUG: include source code"); */
sprintf (command, "UNZIP -q -o %s -d %s", filename, dest);
}
else
{
/* cputs ("DEBUG: skip source code"); */
sprintf (command, "UNZIP -q -o -C %s -x SOURCE\\* -d %s", filename, dest);
}
ret = system (command);
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Updated INSTALL program
Hi, On 7/12/11, Jim Hall wrote: >> >> With the risk of having used an outdated binary (and lacking compiler >> environment for your official source-code-only release): > > Install 4.01 isn't "complete" but it is "stable" for use in the next > 1.1 Test distribution. By the time the Install program is ready for > 1.1 (official), I'll have made a few other releases. :-) Yes, having an installer is good for most people, so thanks! >> SCREEN: INSTALLING: >> * Sometimes getting the "caution: excluded filename not matched: >> SOURCE/*" when answered No to both questions. Seems odd. When selecting >> to not install sources, no messages related to them are expected. > > That message comes from the Unzip program. I got that too, during > testing, but I rebuilt the zip file it was complaining about, and the > error didn't reappear. I think the problem was mixed case in the zip > package file. Ah, now I think I know what you mean. I think that should be easily fixable by using -C (or, as I typically do, "set UNZIP=-C"). Info-Zip is pretty *nix-oriented in portability (as always), so they default to case sensitive and (unlike PKZIP) compress with lowercase filenames. But of course DOS (FAT) doesn't care. >> SCREEN: DONE >> * No input on how to proceed/finish (pressing any random key?) > > I will add a "press any key" message. I'll borrow the NLS string from > the CHOICE program. Homer: "Where's the any key???" :-)) BTW, feel free to nag some of us to (re)translate for Install. I see your /nls/ directory already has 12 languages (or perhaps 11 not counting .en). >> * SUBST/JOIN usable for floppy install? 'mount' floppy files in some >> dummy "PACKAGES\BASE" directory? > > The new Install assumes a CDROM install source, and reads all the > packages at the beginning (so it understands the total number, used in > progress bar) then installs the packages. To do this using floppies, > the Install program would need to be refactored. > > But I wonder if anyone really installs FreeDOS from floppies in 2011? I'm sure somebody weird (ahem) will probably still do it, but it's probably rare now that floppies are almost discontinued. Anyways, if anybody needs to install, they can come to the mailing lists and we'll guide 'em manually. IMHO, you (Jim) shouldn't worry about floppies at all right now. Leave that until after you take care of CD-ROM users (the majority). >> * TIMEZONE stuff required? Didn't notice anything going wrong besides >> sometimes a warning. Any documentation for what is valid input for TZ? > > The TZ variable is used in Unzip or the UzpMain() library, not > (strictly speaking) in the Install program. Not having the timezone > set just results in a warning. To keep the warning from coming up, the > included Unzip program sets TZ with a PST value, if TZ is not already > set, just to suppress the warning message. Worse is that the timezone rules changed a few years back. Honestly, I don't know the lower-level details, and you're probably not using a DJGPP compile anyways. (Does any other compiler runtime support timezones?) And I'm fairly certain their rules are the old ones anyways. In short, it's far from perfect in DOS, but for someone like me, I don't care. (I've only been bitten by it once, IIRC, when unpacking something very fresh from "the future", i.e. U.K., which is a few hours ahead of me, heh.) I can't remember the full syntax, not sure I was ever correct anyways. Yes, typically I set "TZ=CST" (central) though perhaps the full is something like "CST4DST" (or something, I forget and this computer doesn't have it set, doh). >> * Documented that InfoZip's UNZIP is required/expect, and no others >> supported (7ZIP, PKZIP, UNRAR, TUNZ, 7ZDECOD etc) ? > > I'll add a note in the docs. But this is one reason that I'd prefer to > use UzpMain() or some other internal library to unzip/install > packages. Again, if anyone can figure out why this doesn't work > (currently using InfoZip's Unzip 6.0) I'd appreciate the help. Info-Zip did used to have a forum online (at least a year or two ago). You could probably post there or e-mail Ed Gordon (I think? that was his name). Or post to news://comp.compression. Or use a different unpacker / installer: Gautier's zip-Ada, OpenWatcom's (old) libzip used by their installer, FreePascal's unzip / installer. In short, I need to find time today (shouldn't be too too hard) to *try* to recompile OW's libzip statically for you. The stack "bug" in UzipMain() could be anything, so I have no idea, and my C skills are limited. I'd have to look closer. > The only way I can figure to test if the destination has enough space > is to use hard-coded values for how big FreeDOS 1.1 will be after it > is installed (with/without all packages, with/without source code.) (overthinking) I guess in theory you could "unzip -l *.zip" and somehow sum up all the totals (awk?). I mean, if you wanted to do it the fancy automated way. ;-) But I think your way is plenty g
Re: [Freedos-devel] Updated INSTALL program
> With the risk of having used an outdated binary (and lacking compiler > environment for your official source-code-only release): Install 4.01 isn't "complete" but it is "stable" for use in the next 1.1 Test distribution. By the time the Install program is ready for 1.1 (official), I'll have made a few other releases. :-) > SCREEN: INSTALL TO: > * Suppose I'd be a complete newbie to DOS: how do I know what to type > there? (a.k.a what's valid input). > * Absolute paths required? Relative paths seem to be supported, in which > case there's attempts to create subdirectory structure in current > directory. Which won't work ofcourse from cdrom > * Path isn't checked/created before starting unzipping, depending on > UNZIP itself instead to create directories? Or rather you're not > returned to initial inputfield. > * Try typing NUL into that field > * Try typing C:\DUMMY\FDOS in there if C:\DUMMMY doesn't exist For the above: I'm thinking about simplifying the input even further, asking for just the install *drive* and not a a full path. We can assume installing to \FDOS (such as C:\FDOS). Actually, the Install program might even make an educated guess for where to install FreeDOS. For example, if the Install program is executed from A: or B: or D: (etc) then maybe the Install program should suggest installing to C: (if the Installer is executed from C: then maybe it doesn't make any suggestion, and simply asks the user.) > * How to confirm/terminate install location input? pressing ENTER I > guess, but no visual indication of this (at bottom of screen) > * How to exit the program without doing anything? F3 key seems popular > in other installers. I'll add some level of confirmation of values before installing, and an easy way to "gracefully" abort the install if the user chooses to. > SCREEN: INSTALLING: > * Sometimes getting the "caution: excluded filename not matched: > SOURCE/*" when answered No to both questions. Seems odd. When selecting > to not install sources, no messages related to them are expected. That message comes from the Unzip program. I got that too, during testing, but I rebuilt the zip file it was complaining about, and the error didn't reappear. I think the problem was mixed case in the zip package file. > SCREEN: DONE > * No input on how to proceed/finish (pressing any random key?) I will add a "press any key" message. I'll borrow the NLS string from the CHOICE program. > Bugs: whatever you've described already, with most noticeable the > install everything / sources questions using first given answer. That ended up being a display error. The functionality was ok, but Install was displaying the first answer for the second question. > Documentation omissions found so far: > * INSTALL.EXE can started from anywhere, but whatever your current > directory is, a subdirectory PACKAGES must exist, which must have at > least a subdirectory BASE. I need to add better error checking for this. Although most of the time, I'd expect that the Install program is executed by the install scripts on the install CDROM. This bug becomes an issue only when the user runs commands from the live session on the CDROM, and runs the INSTALL program at the command line. But still need to check this. > * UNZIP and RESET need to be in current directory or found in %path%. > * which subdirectories are valid for PACKAGES? Rest ignored or also > processed? The Reset program is intended for debugging, if you abort the install test and need to clear your screen. But CLS does the same thing, so there's not much point in having Reset. :-) I'll remove Reset in the next update. > * SUBST/JOIN usable for floppy install? 'mount' floppy files in some > dummy "PACKAGES\BASE" directory? The new Install assumes a CDROM install source, and reads all the packages at the beginning (so it understands the total number, used in progress bar) then installs the packages. To do this using floppies, the Install program would need to be refactored. But I wonder if anyone really installs FreeDOS from floppies in 2011? > * TIMEZONE stuff required? Didn't notice anything going wrong besides > sometimes a warning. Any documentation for what is valid input for TZ? The TZ variable is used in Unzip or the UzpMain() library, not (strictly speaking) in the Install program. Not having the timezone set just results in a warning. To keep the warning from coming up, the included Unzip program sets TZ with a PST value, if TZ is not already set, just to suppress the warning message. > * Package structure described? The FreeDOS 1.0 and 1.1 package structure is in the wiki: http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Package This was imported into the wiki in January 2009 from a "HOWTO" document. It was discussed on the mailing list some time before that. > * Documented that InfoZip's UNZIP is required/expect, and no others > supported (7ZIP, PKZIP, UNRAR, TUNZ, 7ZDECOD etc) ? I'll add a note in the docs. B
Re: [Freedos-devel] [Spam] R: Re: Updated INSTALL program
Hi, you can enter the following lines into your AUTOEXEC.BAT file as follows: DISPLAY CON=(EGA,858,1) MODE CON CP PREP=((858) EGA.CPX) MODE CON CP SEL=858 KEYB IT If "KEYB IT" doesn't match the characters that are labeled on your keyboard, please try "KEYB IT /ID:142". If that also does not match your keyboard, please let me know. Henrique Em 12/07/2011 02:14, marinellucc...@tiscali.it escreveu: > Hi, > > for me, end user : > > Installation (to harddisk!) is now a matter of: > 1) Partitioning (optional if already done) > 2) Formatting (optional if already done) > 3) Installing > 4) Copy kernel (and optional, shell) to C:\ (unless C: is USB, ah > well) > 5) Run SYS if user wants. > 6) Create configuration files (optional, usefull) > 7) Reboot (optional) > > Complicated by: > 1) Hardware > 2) USB sticks pretending to be C: > > BUT ALSO : > > setting files, buffers, DOS (high/umb) > Sett EMM /XMS > Language/keybpard > > > Thanks > > > Non temiamo alcun confronto: Tiscali ha l'Adsl più veloce d'Italia!Risparmia > con Tutto Incluso Light: Voce + Adsl 20 mega a soli 17,95 € al mese per 12 > mesi.http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > Esta mensagem foi verificada pelo E-mail Protegido Terra. > Atualizado em 11/07/2011 -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
