Hi, On Wed, Sep 19, 2018 at 5:21 AM stecdose <stecd...@gmail.com> wrote: > > I don't know which is the best place for this message. As it is about > development I stick to freedos-devel. Is it ok to also send to > freedos-user, because in the end it will affect users when used. And > maybe users have suggestions for easy usage ;) > Or would it be better to wait until I have something to release and then > put another message on freedos-user without the dev related stuff?
General discussion, even without working prototype, is probably still okay for freedos-user. But of course having something concrete to point to (and test) can be better, but don't procrastinate "forever" (common pitfall!) just because everything isn't 100% perfect yet. Personally, I think general discussion is okay here on freedos-devel too, but some (very few) here get a bit grumpy with too many "useless" posts. So try to minimize theoretical discussions that don't have working code. (But practical software questions are probably okay.) In other words, do whatever you want, and don't worry. Someone (not me) might complain, but you are free to ignore them. Constructive criticism is rare, but we don't have a lot of users or developers either. You're not killing anyone with your text, so who really cares? As long as it's DOS-related, it's probably cool. (I'm no authority, so defer to them, but in general it's very lax around here.) > I am in progress of making a floppy disk distribution of FreeDOS. I am > not totally ready to publish it and more and more questions arise, this > is why I write here, before doing all the work to the end and then > realize it was the wrong way ;) I mirrored my own floppy .img (MetaDOS) to iBiblio. I've made others in the past. Mine was intentionally minimal to expand upon, not meant to be full "BASE" or anything else but a starting point. Almost all others (including previous ones of mine) are outdated, abandoned, buggy, and don't have full sources. Hence they're hard to find, unreliable, and not recommended by any of us directly. To be mirrored to SourceForge or iBiblio (or most places, presumably also Github), you need to be "open source" (OSI) or "Free/libre" Software (GPL, BSD, etc), aka FOSS. > Mainly I want encouragement or a "hey, this is not going to work like > this!". The section "Desc. of Installer / Please comment" describes the > installation process. I want you guys to comment on that. Do you have > any suggestions on this procedure? The whole mail is spotted with > questions and assumptions. I want answers and corrections ;) Okay, I'll try. > # why? > > I don't need FreeDOS on computers that have a CD-drive, for these I use > more unix-like OSes (minix, linux, *bsd). Well, a lot of modern computers don't have optical drives anymore anyways. But CDs can be useful (esp. old DOS games), but I personally rarely do that. (Most gamers prefer DOSBox, e.g. Pixelmusement/ADG.) Oh, almost forgot, CD holds more (obviously), hence unofficial distros like Mateusz's Svarog386: * http://svarog386.sourceforge.net/ AFAIK, not all of it is "open source", but he didn't want to be restricted to that (for practical reasons). But you still need to be extremely careful about licensing (if not for your own sake, then for your audience's sake). > I use it on 2 single board > computers, an old laptop that has no CD, no LAN. I have searched for > floppy images and found a post on mailing list or a bug, which I can't > find right now to link it here, that asks for floppy images. Someone > (maybe Jim Hall?) answered that it is possible but due to lack of demand > and man-power no one has made it. A "full" floppy distro is not urgent, no, because most people can roll their own. Besides, who wants to lug around dozens of floppies? Even modern computers don't have floppy drives anymore and prefer bootable USB. I personally do have a USB floppy drive but haven't used it much lately. Honestly, few ever used my MetaDOS (or even older ones like BARE_DOS), but I had hoped that those would provide some kind of help for such floppy users. So it's not totally dire, there's at least "some" images out there (that aren't totally illegal like bootleg MS-DOS/Win9x floppies, ugh.) > # What is it? > > It is *not* a full blown FreeDOS installation. It is a base-system+self > written installer that fits on one single floppy disk. Which is more reasonable to maintain, obviously. > Installer has the > ability to "install additional disks". This menu-entry will, if > selected, wait for floppy change and then execute a .bat file on this > disk. This makes it very easy for users to build their own custom > additional disks. > For example a file commander (like VC) in a zip file on a disk, can be > copied and unpacked by this bat to disk. Okay, but let me stop you right here: VC (presumably Volkov Commander) is ancient. Maybe the last beta was "freeware", but there are many better alternatives (that have sources), e.g. Doszip Commander or old/classic DOS Navigator 1.51. Granted, you probably like it for being small, but that alone isn't (necessarily) a perfect reason to include it. 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. A little extra care is good. ("An ounce of prevention is worth a pound of cure.") I know you're aware of this, but it's truly something that can hamper any project, and I don't want you to get accidentally caught up in any dumb worries that aren't directly related to your personal goals. Software is indeed meant to be used, but license woes can ruin any other good work that you do. All it takes is one bad apple to spoil the whole bunch. Please be careful. > # 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). > These screenshots were taken using dosbox on linux. BTW, they had a very minor refresh recently (0.74-2), preparing for 0.75 eventually. > # Description of Installer / Please comment > > It is a menu based design, rather than the step-by-step design like > MS-DOS installer uses. I wanted to have this for most flexibility and > easy usage. > As you can see on screenshots I have implemented it with these steps: > * Setup Keyboard > * Setup HDD (executes fdisk, asks for executing format C:, asks for sys C:) > * Configure (Date, Time, DOS-Folder, xcdrom, ctmouse, himem, emm386) 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/ 2). XCDROM is ancient and replaced by UIDE. 3). HIMEM and EMM386 are ancient and replaced by HIMEMX and JEMM386. 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). > 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. > # Packages > I have taken the base-packages (zips) and removed everything > unneccessary in these, only leaving the bins in zip. 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?). > They makes 1.240k in total. cdrom driver is still missing on floppy (not > worked on this yet). UIDE.SYS is probably the only available driver for such optical drives that includes sources. You may wish to try that (with SHSUCDX or similar). But it's unmaintained, so don't email the author (please)! > # size > > The installer's size right now is at ~30k (bin size), I use upx to > compress it for floppy distribution, which makes a ~60%-sized binary. If > upx causes any problems, I won't stick to it. > Do you know about common problems with upx? For example something like > "It does not work at all on a 286". As 286-486 are the main desired > targets of this floppy it would be a pity, having a not-working installer... 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. 386/DPMI (e.g. DJGPP) really is extremely popular and too good to ignore (mostly). 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. > # the smallest unzip? > > The smallest unzip tool I could find is pkunzip. As this is not free, is > there another, very small!, unzipper? Is there another compression > method, that would give me better results that does not neet DPMI or is > 300k in size - this wouldn't be a step forward. pkunzip comes in less > than 30k. > As DPMI is limited to half of the machines, this distribution is > intended for, it is not an option. 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. 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. > # 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). > # 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.) > # 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. > Also I want to keep the right to do a fork with a new license in a few > years. For example, if someone wants to buy this software to legally > remove copyright messages, I want to be able to offer under a new, > custom, license, assuming that I am still the only rights-holder. You should be able to dual license at a later date, yes, if you're the copyright owner. > # where is this leading to? > > I want to make such a distribtion for FD1.2, also for upcoming releases. > I want to make additional disks (like explained above) (dev-tools, > disk-utils, networking, games, ... splitted it categories like these) Good luck! You'll need it! > # Hosting > > As I assume, this is not going to be something official and supported I > think I will release it on my github account along with some > documentation to it. > Any other suggestions? Make sure to learn exactly what Github allows to be legally uploaded there. If they forbid "shareware", then you have to be careful about that. There's a lot of old shareware lying around, and some people are very sloppy about licensing. Just play it safe. I know I'm repeating myself, but it's just not worth wasting all your time and having everything thrown out due to one mistake. Maybe you don't want or care about mirrors, but software that isn't mirrored is often lost to the ages. I hate software that isn't well preserved. > # toolchain > As I've read on the mailing list, somewhere in past people were > complaining about non-free tools. I am using Borland C++ 3.1 for a few > reasons: > > * I do the development on an 486 Laptop with 8MB RAM and 80x25 > Text/640*480 GFX, it has to work on this old machine. 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). > * There is no text mode IDE that has syntax highlighting, online help > (go to a keyword, press CTRL-F1, you're directly at it's documentation) > and debugger, that works as good as BCPP3. FreePascal (FP.EXE) works fairly well. I know that's not C/C++, but still .... Yes, you mention RHIDE (below). That was based upon SETEDIT. DJGPP's TexInfo ("info libc a printf") is good for a quick fix. Same with GNU Emacs (or JED or FED or ...). Debugger? If not RHIDE, you'll have to use standalone GDB. (Although FP.EXE "usually", but not always, has GDB built-in as well.) > * For me it's free as I own a legal copy and didn't have to pay for it. > If you need, mail me off list. There are several places on the net > sharing this software, I can point to. 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+.) > I really don't care about using non-free tools to build free software, > as long as people can get hands on it without much effort. It is not a > religious question for me and please, I don't want to discuss that. The problem is moreso proprietary code that can't be patched, enhanced, optimized, etc. without a proprietary toolset. If you can't even rebuild it, then it's not worth trying to fix or improve it (almost). Again, preferring BC++ isn't wrong, but supporting other compilers in tandem makes things much less dire. Try not to rely exclusively on one specific compiler. For example, if code requires a DOS-specific compiler (for ancient, pre-standard C++) that isn't freely available, most people won't even try to debug it. Honestly, there's just too many dialects, non-standard languages, OS- (or cpu-)specific code, etc. It's one big mess. Standards and portability are good things, even if slightly more work in the long run. (TC 2.01 is freeware but can't be redistributed. It's also slightly buggy. TC++ 1.01 used to be freeware but is only available as demo download, also can't be redistributed.) Seriously, having old MASM- (or TASM-) specific code makes things *very* hard to rebuild, modify, fix, etc. HLLs should be easier, in theory, but never are, and it's very annoying. Please be careful. It's more important to think about source code compatibility than what specific toolset you prefer. You can still use whatever you want, but being able to "also" build with "Free/libre" tools can be incredibly useful. > If some comminuty rules or license terms would make my software totally > incompatible to FreeDOS I am willing to rethink and change to Watcom or > bcc/dev86. Everything is written by myself, no windowing-libs like > TurboVISION, it should be pretty straight forward to port to another > compiler. OpenWatcom is "OSI approved" but FSF (and pals) hate it. That negatively impacts DOSEMU and its inclusion in various Linux distros (even though 99% of Linux distros, e.g. Debian or Fedora themselves, are considered "non-free" by FSF). Still, for the most part, OpenWatcom is the best we've got. (Most of us haven't looked into Digital Mars much lately, but it's Boost-licensed now, so who knows.) Oh, there's also the unfinished GCC-IA16 toolset. I would consider BCC/Dev86 to be (mostly) "too weak", but it's barely okay if you're extremely diligent (to avoid its flaws). Even SmallerC (can rebuild itself) is more functional and ANSI standards compliant than BCC/Dev86 nowadays. > And yes, I know rhide, I dont like it. It's usage and look is similar to > Borland's, but it is not Borland. Also djgpp is so fucking slow Use a software cache (LBACACHE or UIDE) and/or RAM disk (SHSURDRV or RDISK). That helps a ton, esp. for DJGPP. > and binaries are too big for usage on a floppy disk distribution. Use Strip and/or UPX. Check the map file and avoid bloated functions you don't need. (printf has gotten much worse in recent years.) Maybe?? you can use old classic 2.03p2 if you don't need the bloated symlink support. > Also djgpp's binaries are limited to 32bit machines, not very dos-like and > same problem as with DPMI. 386 compatibility is universal, it's rare to not have one available. I think it's a red herring to imply that DJGPP wasn't insanely successful. However, I'm still also heavily sympathetic to 8086 (which turned 40 this year!), even in code (try FPC's ppcross8086!), but it's often hard to make things work in such limitations (unless starting from scratch). DJGPP and DPMI have been around for (almost) 30 years! Even though DPMI sometimes was implemented for 286s, it was the 386 where it had most popularity. Remember that Doom (Watcom/386) and Quake (DJGPP!) were both "extended", and that's 1993 and 1996, respectively! > PS: I thought about writing a quick mail about the installer, but this > message has taken 2 hours and I still have unwritten things on my mind, > but these later. > > I hope for response. Sorry if my answers were somewhat vague. I hope you continue to enjoy your hobby and discussion here. Keep hope alive, there's always more to do! _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
