Re: [Freedos-user] FDNPKG v0.99

[Mateusz Viste]

On 02/09/2015 04:43, Ralf Quint wrote:
> You are making a totally wrong assumptionn that 16bit software means you
> are limited to 640KB of memory.

Absolutely not - my assumption is that running on 8086/80186 means I am 
limited to 640KB (or let's say < 1M). Hence for software with higher 
memory requirements there is little or no advantage of being 16bit.

Mateusz


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG v0.99

[Mateusz Viste]

On 01/09/2015 19:47, Rugxulo wrote:
> And I also announced it for News (but it hasn't shown up on front page yet).

That's cool, thanks!

> P.S. I knew that LZMA was slower for older-class machines, but I
> traditionally just unpacked/repacked

But keep in mind that you are a "special case" ;)
What's obvious to you (unpacking/repacking to gain on de-UPXing times) 
is not necessarily that obvious to a user that runs FDNPKG for the first 
time. The LZMA gain is not high, less than 20%, so I believe it's better 
to have something running reasonably fast on every 386+. For FDNPKG, the 
UPX loading times are as follows on my 25 MHz 386:

Not UPXed   : 1s
UPX -9  : 3.5s
UPX -9 --all-filters: 4.5s
UPX --lzma  : 35s (!)

> Also, the whole linking with libemu.a was probably unnecessary (due to
> emu387.dxe loadable at runtime) except for user convenience.

Without linking with -lemu, FDNPKG was immediately crashing with a 'no 
coprocessor' fault on computers without an FPU. There are ways around 
that, like using a 387 TSR emulator or runtime DXE loading, but FDNPKG 
is supposed to be working even in a minimal environment (ie. only 
kernel+command.com available), since it is used for installing all the 
rest of the system. That's also the reason it comes with a CWSDPMI stub 
embedded.

Mateusz


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] The beauty of 16-bit machines and code

[Bruno Félix Rezende Ribeiro]

Hello Michael!

Just want to demonstrate my empathy.


Em Tue, 1 Sep 2015 10:24:45 -0700
Michael Brutman  escreveu:

> We need to include the 16 bit machines wherever possible. [...] they
> are very capable.

To me 16-bit machine support is the true beauty and essence of DOS (For
32-bit machines we have GNU).  The BIOS and interrupt-based APIs are a
distinctive feature that should be regarded as the canonical way of
writing software for DOS.  DOS extenders and all software abstraction
that came with post IBM-PC architecture seem to me as not belonging to
the ideal DOS world. 


-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) http://oitofelix.freeshell.org/
 `-'(. .)`-'  irc://chat.freenode.org/oitofelix
 \_/  xmpp:oitofe...@riseup.net

GNU maintainer: ccd2cue
DMOZ free software editor (Portuguese)
UFU FAMAT PET member

[GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily
match those of the GNU project.  Hereby I express my own opinion,
style and perception, in good faith, aiming the betterment of GNU.


pgpl1vn5cepcd.pgp
Description: Assinatura digital OpenPGP
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG v0.99

[Ralf Quint]

On 9/1/2015 10:02 AM, Mateusz Viste wrote:
> 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...
You are making a totally wrong assumptionn that 16bit software means you 
are limited to 640KB of memory.

And properly written 16 bit software has the added advantage that it 
works just as fine on a 32bit or even 64bit capable host system... ;-)

Ralf

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG v0.99

[Bruno Félix Rezende Ribeiro]

Hello Mateusz!

Em Mon, 31 Aug 2015 19:29:00 +0200
Mateusz Viste  escreveu:

> Today I released a new version of FDNPKG.

Congratulations on this new release!


-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) http://oitofelix.freeshell.org/
 `-'(. .)`-'  irc://chat.freenode.org/oitofelix
 \_/  xmpp:oitofe...@riseup.net

GNU maintainer: ccd2cue
DMOZ free software editor (Portuguese)
UFU FAMAT PET member

[GNU DISCLAIMER] I'm a GNU hacker, but my views don't necessarily
match those of the GNU project.  Hereby I express my own opinion,
style and perception, in good faith, aiming the betterment of GNU.


pgpqdtJKKn_9I.pgp
Description: Assinatura digital OpenPGP
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG v0.99

[Michael Brutman]

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  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"  > > wrote:
> >
> > Hi Sparky,
> >
> > On 31/08/2015 19:38, sparky4 wrote:
> >  > I want to make a 16 bit version of this program... 
> >
> > 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 mai

Re: [Freedos-user] FDNPKG v0.99

[Rugxulo]

Hi,

On Tue, Sep 1, 2015 at 4:26 AM, Mateusz Viste  wrote:
> On 31/08/2015 22:46, Dale E Sterner wrote:
>> Is there an Ibiblio link for this?
>
> Sure, here it is:
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/util/fdnpkg.zip

It may be redundant, but I also mirrored it here (since I'd done so before):

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/fdnpkg/fdnpkg99.zip

And I also announced it for News (but it hasn't shown up on front page yet).

https://sourceforge.net/p/freedos/news/2015/09/fdnpkg-099-386/

But due to the way things are currently set up, I can't edit the
online Software List (.LSM), though I assume Jim is already well aware
of that (or maybe already mentioned it to me, I forget).

http://freedos.sourceforge.net/software/?prog=fdnpkg

P.S. I knew that LZMA was slower for older-class machines, but I
traditionally just unpacked/repacked (which UPX is direly in favor of)
when needed. It only affected 1+ MB .EXEs on 586 or less machines (but
huge .EXEs aren't nearly as common as you'd think), e.g. UPX itself.
Also, the whole linking with libemu.a was probably unnecessary (due to
emu387.dxe loadable at runtime) except for user convenience.

--
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG v0.99

[Mateusz Viste]

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"  > wrote:
>
> Hi Sparky,
>
> On 31/08/2015 19:38, sparky4 wrote:
>  > I want to make a 16 bit version of this program... 
>
> 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

Re: [Freedos-user] FDNPKG v0.99

[Michael Brutman]

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"  wrote:

> Hi Sparky,
>
> On 31/08/2015 19:38, sparky4 wrote:
> > I want to make a 16 bit version of this program... 
>
> 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

Re: [Freedos-user] FDNPKG v0.99

[Mateusz Viste]

On 31/08/2015 22:46, Dale E Sterner wrote:
> Is there an Ibiblio link for this?
>
> DS

Sure, here it is:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/util/fdnpkg.zip

Mateusz


--
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user