Hi, On Wed, Apr 11, 2012 at 11:13 AM, Eric Auer <e.a...@jpberlin.de> wrote: > >>> it seems even on modern hardware unpacking FreeCOM >>> during install may take VERY long, so we need a fix: >> >> This seems to be specific to the old installer (v3.7.8 by Jeremy) I >> think, as that unpacks entire packages. Sourcecode modification would be >> required to add a "-x source/*". Alternatively, or additionally, if >> someone modified the new installer (v4.01 by Jim) to switch to >> destination directory after unpacking files, that would also work. > > That sounds as if a very small problem keeps you from > upgrading to a newer and probably better installer...
Yes, but Jim is too busy, and barring any motivation, others (ahem) haven't looked at it either. >>> - it is good to have source and binary in one zip > > If size is critical, you can automatically make zips > without sources by doing zip -d somefile.zip source/* Not recommended, it's easier to just keep it together. Though if you want to maximize size, just put sources inside their own .ZIP but within the main .ZIP, so at least unpacking only has to create one file. You can even use "Stored" (-0 compression) on it so the outer .ZIP can compress it better as a whole. >>> - but you can use info-zip's command line options >>> (-x source/*) to exclude sources from unzip :-) >> >> New installer already does this, reason why... > > That is sth. to discuss with the installer maintainer :-) Again, he's too busy with real life (work, MBA) and updating the web site, etc. >>> - a default install does not need sources, as the >>> user can always fetch those from the zip later >> >> I've never liked programs with many options/switches > > Exactly. So do not ASK users whether and which sources > they want to install, just TELL them that all sources > can be found in the zips when needed. Users will rarely > need sources and most of the time only of single apps. Users will always need sources, esp. if they share, but they don't necessarily need to unpack them. (Well, anyways, they probably don't have all compilers anyways.) >>> - users should be warned that install without XMS >>> drivers will be horribly slow due to lack of RAM > > Regarding the compatibility trouble discussion: Users > BELIEVE that not loading drivers is a safe option but > in fact it is a very problematic one because the install > performance totally chokes on lack of memory then. You > could better offer multiple XMS drivers to chose from. Keep in mind that outside of FDXMS286, there is no XMSv2 only driver, esp. for 286s that is the only one that (allegedly) works. And obviously XMS doesn't work at all on 8086 or 80186. But I thought the default installer (since on CD) was 386+ anyways? Or at least default requirements. So just use DJGPP UNZIP32.EXE (or whatever it's called), it can run in "raw" (no mem. managers) just fine. If you really want, you can include both 16-bit and 32-bit UNZIP*.EXE files and choose dynamically at runtime (cpulevel.com, if errorlevel 3 unzip32.exe). At least this way won't be painful "unnecessarily" for 90% of users. > For not loading anything, there is always the F5 key... Yes, but some DOS settings are quite limited by default, so sometimes F8 is better. >> I intend to offer loading of XMS driver at runtime as an option. > > Please avoid that - it complicates things and does not > give FreeCOM or kernel enough extra RAM to matter. So > I strongly prefer loading XMS drivers in config.sys... I agree with Eric, but it's your call, Bernd, obviously. ;-) > As said, XMS drivers should be loaded in config.sys, > there can be several XMS drivers to pick from to get > extra compatibility, and avoiding XMS drivers should > be hard, so only expert or masochist users do it... Depends on the app. Most "extended" apps can support raw just fine (more or less). Hmmm, spawning other extended apps might be tricky in some scenarios, but only because of fragmentation or default allocating everything for parent app. >>> Excluding sources from unzipping instead of unzipping >>> and then deleting them also saves CPU time and disk >>> activity time and temporarily disk storage space :-) >> >> Deleting files can take ages indeed. By the way, I'm considering >> 7-zipping sourcecode of programs that can't be compiled in DOS. > > We hopefully do not have many such programs anyway...? What can't be compiled in DOS? I know a lot of DJGPP-era stuff needs LFNs, but I can't think of any common FreeDOS util (off the top of my head) that can't easily work. Well, there's probably something somewhere. P.S. I guess you know 7zdecode.exe is much smaller than p7zip. Or are you just letting the end user figure out how to unpack it? ;-) Oh wait, p7zip itself can't build (easily?) on FreeDOS, heh, now that's one behemoth of a package (slow to build). ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
