It takes a few days for me, but I haven't lost interest if it looked
like ;)
.... VC ....
I have now replaced vc with doszip commander. Also very small and powerful.
I have prepared a few disks:
* 1 disk base (boots, installs base)
* 1 disk dev (c, asm, basic)
* 2 disks util (partition tools, bootmanager, rawrite/read, doszip, ...,
...)
* 1 disk drivers
* net (also boots, network time sync, see a few lines below)
With 5 (6 for net) disks I have a lot of space. With repackaged programs
I already
have a lot of them and still having free space on some.
It's not wrong to use proprietary software, but it does add an extra
burden regarding licensing, which is always a pain. Sure, you can
probably "get away" with being very sloppy (and most people do/are),
but it doesn't help end users very much. [...] Please be careful.
I stick now to packages that are on FD-CD and stuff that is compatible
to it (by means of licensing).
I thought about preparing an additional non-free disk, but I don't think
so.
People in need of a propritary tool should know where to get it...
Maybe also, besides of complicating everything, it prohibits use for
some people for some reasons.
This is totally not what I want.
# Screenshots
As my message was too big with screenshots, I have uploaded em here:
https://raw.githubusercontent.com/spacerace/snippets/master/screenshots/dosinst/di02.png
That particular one won't display, has errors (according to Firefox ESR 52.7.1).
One seems missing or I have messed up naming...
These screenshots were taken using dosbox on linux.
BTW, they had a very minor refresh recently (0.74-2), preparing for
0.75 eventually.
Gentoo brings a gentoo svn package, that always uses the latest svn
version for building. I've updated to this and think will do this
always. 0.74 is around for so long, I never thought about updating it...
1). Date/Time can probably be done with SNTP (or whatever, I haven't
used it lately). I know you said "no LAN", but with packet driver it
can be convenient. IIRC, mTCP and Mateusz's port of PicoTCP both
support it: http://picosntp.sf.net/
I will prepare a network disk, but this does not fit on the
fdbase-floppy at all :(
I really like this idea :)
Maybe Procedure for network disk would be: boot up with that disk, some
dialog driven network-configuration, automatic time update with a list
of time servers,
change disks to installer disk, start installer.
2). XCDROM is ancient and replaced by UIDE.
This one makes me a bit confused. I searched for UIDE and here a three
quotes:
""Thanks" to the people in FreeDOS forum, all kind of insult, hack,
steal and modify Jack's drivers, Jack decided to stop offering this
drivers to the public."
"UIDE- Replaced by XHDD / XDVD2 caching driver"
"Initial release of the XHDD/XDVD2 driver set for all users, derived
from the XHDD/XDVD2 drivers that are now PRIVATE!"
There is no source download anymore and somewhere I read he stopped to
make source public.
I don't think it is wise to use this driver/these drivers. So still
searching for some. I found a few that I still have to investigate,
bookmarked.
http://optimizr.dyndns.org/dos/drivers.html
http://optimizr.dyndns.org/dos/old-drv.html
3). HIMEM and EMM386 are ancient and replaced by HIMEMX and JEMM386.
Changed this.
4). CTMouse ... be sure to use latest 2.1b4 (unless you have a good
reason). I'm not the maintainer, but I still need to fix that package
one day. (It uses non-free tools, e.g. COM2EXE.COM, which is not
needed, a simple debug script can replace it).
Okay.
Due to "it was too complex and is not needed by me up to now" I have
fixed every possible drive-selection for destination to C, for source to
A. I have never needed something else, if you think else, please write back.
I haven't tried lately, but I did make a bootable USB (via RUFUS) and
used PLoP Boot Manager (floppy) on my old P4 machine. That made the
USB "read-only", but at least it let me boot USB (which holds more
files, obviously) on such an unsupported machine (no BIOS support for
USB). That made the boot drive "C:" instead of "A:" for normal
bootable floppy. So, in essence, I automatically determine at bootup
and "set BOOT=..." the appropriate drive letter ('a' or 'c' or
whatever). Then I just use "%BOOT%" instead of hardcoded drive letter.
This is a very good hint for easy usability/program logic, but still
need to think about this.
These packages are
on disk right now:
A lot of those will never be used except in rare cases by 0.01% of
people. So I personally wouldn't even include them. Sure, Jim (and
others) demand compatibility, which is fine, but if no one actually
needs or wants or uses it, why bother? Unless you're trying to be
"official" or something, it's not worth the effort.
EXE2BIN
RECOVER
For instance, just for example, these two, I think anybody who needs
them can find them already. Seriously, they are not very useful by
themselves. And there are others that are rarely used too (APPEND?).
... UPX ...
I doubt many are still using 286s (whereas I know several still use
486s). I'm not against it, but it's somewhat impractical to demand 286
compatibility. In theory, we should be careful, but in practice it's
almost a lost cause. Again, I'm sympathetic, but it's only worth
worrying about "for fun" rather than an absolute mandate.
But this is just what I want to have it for. For all those PCs can't
boot from/doesn't have a CD-drive but having a 3.5" floppy. And this
goes down to 286 as well.
My first PC was a 286 with a 5,25" and I had to borrow a 3,5" drive to
install dos 6.22 and win 3.1.
I think any older PC than 286 wont support a 3.5" floppy.
I have added an option now to choose between 8086 and 386 kernel, which
one should be installed. floppy boots with 8086. Not totally implemented
right now, still some work...
If I had a 5.25" drive I would make a base disk (set) for these too, I
have a shoe box full of untested 5,25" floppies...
(e.g. DJGPP) really is extremely popular and too good to ignore
(mostly).
DJGPP is too complex and too big to fit on a floppy or some more... If
anyone needs this on a system only having a few MB HDD and a 3,5"
floppy, there are better ways to get this onto. Almost every PC supports
a CD drive at least without booting, change HDD to another computer, ...
And splitting DOCs... from bins and sources is too complex and wont help
at all. too big for floppies.
UPX? Don't forget "--8086" since it will be 286 (actually, 186) "only"
otherwise. Being incompatible saves a very few bytes (eight?) in the
stub, which isn't worth saving (cluster size wastes that much
anyways). The other caveat is that LZMA isn't default for 16-bit, so
you'll have to explicitly use "--lzma". That is due to speed, not
size, concerns. But it won't be noticeable except on truly ancient
machines or if the .EXE is really huge (like various DJGPP-compiled
things). IIRC, "upx -V" itself (when LZMA-compressed) was very slow on
a 486. (Also, UPX'd DJGPP COFF stuff runs slower under NTVDM, but I
don't guess that matters for you.) Otherwise, don't worry.
thanks for these notes, very helpful.
DPMI can work on 286s, e.g. old Borland (Pascal?) tools. But yeah, 386
is more popular. No, PKUNZIP is not freeware, only shareware (last I
heard), thus probably not good enough for Github (but who knows, I
don't actively use that). Info-Zip has a 16-bit UNZIP.EXE, but it's
not smaller. I would still recommend Info-Zip, though, just to not
worry about licensing.
shareware will not make it into release, for now I still use it for
space reasons.
As I have removed a little stuff from base disk, I have now space for
infozip.
There's also others, of course, but I can't think of any obviously
superior tool, except maybe UNTAR (which also supports .gz):
* http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/tar/
So UNTARDOS.EXE is 22 kb, but you can presumably UPX that to half
that. Granted, that's less DOS friendly, but it's still a good
alternative if you're creating your own compressed archives and only
need unpacking.
TAR is usually only uncompressed tape archive, that brings a wrapper
for combining with gzip. This is why I thought it needs an additional gzip.
This is not the case, it has decompression in 22k. Thank you very much,
this also helps me a lot.
# Tested
I do not own any older (8086/88, 286, 386) machines, I am going to set
up a few PCEM-machines...
Joris' old Retro emulator (Java) tried to mimic 8086, I think. Better
than nothing. But honestly it's rarely worth worrying about (except
"for fun", in theory). I'm no expert (ask Jim Leonard or Mike Brutman
or Mike Chambers), but there were only a few quirks worth worrying
about regarding a true 8086 versus a clone or successor. So if it
works on later machines, it's 99% guaranteed to work on 8086 (assuming
you don't do anything "bad", of course).
Yesterday I got a Commodore 386-SX25 with 2MB RAM. Will also test
on this machine.
# Disks
I've never seen any 2.88MB floppy out in the wild, so I decided to use
1.44MB. 1.7MB formatted floppies are tricky to get an image on it with
USB-floppies, if not impossible. Any suggestions or should i stick to
1.44MB disks for maximum compatiblity?
Stick to 1.44 MB unless forced otherwise. It's fairly common and
standard. I haven't seen anybody ask for 720 kb floppies, but in
theory that might be nice. (Someone said emulators support that too,
but I never wasted time finding out.)
I have two 720k floppies that still do work. Maybe I'll try when other
stuff done.
# what license for installer?
What license do you guys suggest? I want to keep away people trying to
make money, but I don't want any further restrictions.
Is that really a worry? They might just do it anyways, regardless of
license, esp. if their host country allows such. Or maybe they can get
away with it, who knows. So it's not worth worrying, IMO. Maybe just
keep it simple (GPLv2+)? But don't let me imply that you can't do
otherwise. I don't really understand your goals (or worries) here.
Maybe I'm too naive.
I have no actual reason for this, but I am somehow afraid of being
restricted
in some cases in some situation. This was more a general question to GPLx
and not related to this particular project.
You can always develop on one toolset but remain compatible with
others. So try to keep most of your code "standard" or quasi-portable
(or at least isolate non-portable stuff to separate
modules/units/files).
DJGPP is better. There are many other good free development tools
(e.g. FBC or FPC or even SmallerC). If you direly need 16-bit,
collaborate with the GCC-IA16 developers. Or OpenWatcom, obviously.
(Even SmallerC's 16-bit memory model support still needs 386+.)
When it's done I also add a Makefile for bcc/dev86 on DOS-host.
This seems the most easiest to do.
Nils
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
