A 16 bit database engine is a little bit of a stretch, is it not? I don't think that keeping some data in memory and indexing to records on disk qualifies as a database engine. I agree that it is more work, or in this case rework. And I agree that when time is limited, projects like this become optional. But this is not a "monster project." I really do object to the "small machines can't use this or don't need this" misconception.
mTCP has all of the traction that it needs ... it runs on 16 bit machines, 32 bit machines, emulators, and pretty much every flavor of DOS created. The most recent version (2015-07-05) has been downloaded 600 times already; the previous version has over 4000 downloads. I'm sure it's much more widespread given how many places it was mirrored at. I can't see ever going 32 bits when the 16 bit code works well on both 16 and 32 bit machines. I think that the solution for requiring more memory is to start using EMS/XMS memory via interrupts. That allows the same basic code to run on both sets of platforms and use more memory when it is available without the pain of fully going to a 32 bit address space. Starting with a 32 bit address space is certainly easier and there is more library support available. But for the use case of just simply needing more memory it is overkill. I'm willing to leave that space to WATT-32 which handles it nicely. We need to include the 16 bit machines wherever possible. Note that I'll never ask for something like a 16 bit version of Dillo ... it's just not feasible. But a package manager really should be able to run on a 16 bit machine. I've managed to create functional (and fast) FTP and HTTP servers for 16 bit machines - they are very capable. On Tue, Sep 1, 2015 at 10:02 AM, Mateusz Viste <mate...@viste.fr> wrote: > Hi Michael, nice to hear from you! > > Of course disk-based structures are easy to implement - FDNPKG already > uses them extensively for storage. The key word here is speed - keeping > packages metadata in RAM is fast. Parsing and searching through on-disk > data structures is at least a magnitude slower. > > Now, of course I could implement some indexing mechanisms on top of > that, and end up designing a specialized 16 bit database engine that > would fit in the 640K limit of memory... Unfortunately I don't have > enough free time for this kind of "monster projects", although this > might positively change in a decade or two. Until then, I'll let others > do such work. > > BTW, any plans on publishing a DJGPP-compatible version of mTCP? I'd be > happy to switch from Watt32. I fear mTCP will get no traction if it > ignores the more interesting 32-bit projects. ;) > > cheers, > Mateusz > > > > > On 01/09/2015 17:45, Michael Brutman wrote: > > The current memory requirement is a function of your design, which I > > think could be improved. Disk based data structures are not that > > difficult to implement. > > > > I have a PCjr with a 20GB Maxtor drive on it, of which 600MB is in use. > > There are lots of 8086 and 80286 class machines with larger than > > original hard drives on them; drive overlay software made that possible > > 20 years ago. Recent IDE controller projects have expanded the number > > of old machines that are hard drive capable. You are incorrect in you > > belief that old machines can not benefit from a package manager. > > > > FreeDOS will get no traction among the sizeable retro-computing > > community of these kinds of design decisions continue to ignore the more > > interesting, older machines. > > > > On Aug 31, 2015 11:50 PM, "Mateusz Viste" <mate...@viste.fr > > <mailto:mate...@viste.fr>> wrote: > > > > Hi Sparky, > > > > On 31/08/2015 19:38, sparky4 wrote: > > > I want to make a 16 bit version of this program... wwww > > > > You are most certainly welcome to do so - that's what open-source is > all > > about. > > > > I can't help but wonder though - is there any practical need behind > such > > work? I don't really see what this would improve. Sure, it would make > > FDNPKG potentially run on 80286 CPUs - but I am not convinced anyone > > would want to run a package manager on a 286. Disk space is usually > > scarce on these machines (if there is a hard disk in the first > place), > > so I'd rather think people will turn to good old manual 'copying > what I > > need' on such hardware. It's worth noting that 8086 and 80186 are > out of > > scope anyway due to memory constraints, since FDNPKG definitely > requires > > more than 640K of RAM to work. > > > > Mateusz > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user >
------------------------------------------------------------------------------
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
