Re: [Freedos-user] FDNPKG v0.99

[sparky4]

>> 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? 
IBM XT
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.

 my XT is overkill and it has EMS so yeah i when you stabilize it i will
defiantly port it to 16 bit


is it a good time to port it? i been working on memory management software

Mateusz





--
View this message in context: 
http://freedos.10956.n7.nabble.com/FDNPKG-v0-99-tp23151p23184.html
Sent from the FreeDOS - User mailing list archive at Nabble.com.

--
___
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 04/09/2015 12:32, sparky4 wrote:
>  my XT is overkill and it has EMS so yeah i when you stabilize it i will
> defiantly port it to 16 bit
> 
>
> is it a good time to port it? i been working on memory management software

Sure it is. It won't get any updates in nearest months, so, by all 
means, please go ahead :)

Mateusz


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

Re: [Freedos-user] FDNPKG v0.99

[sparky4]

oh shizam!! i will start when i can~



--
View this message in context: 
http://freedos.10956.n7.nabble.com/FDNPKG-v0-99-tp23151p23186.html
Sent from the FreeDOS - User mailing list archive at Nabble.com.

--
___
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/2/2015 9:12 AM, dmccunney wrote:
> On Wed, Sep 2, 2015 at 1:37 AM, Mateusz Viste  wrote:
>> 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.
You keep looking at it from the wrong end. There is no disadvantage of 
running 16bit code on >80{1}[6,8] type CPU. And for plain DOS software, 
like an installer, using a compiler/memory requirements of 386+ CPUs is 
rather limiting the number of potential users...
> And getting around the 640K limit was the reason for HIMEM,SYS, EMS,
> XMS, and playing games with the A20 address line.  I routinely used
> the capability when I *was* running on an 8086.  My old XT clone had
> an expansion card with a MB of additional RAM, split between a
> ramdisk, disk cache, and EMS memory for apps that could use it.  This
> all started back *before* the 286 and later 386 CPUs became common.
Well, yes. No. Maybe. All/none of the above...

On an 8086,8088, 80186 type CPU, you can use EMS, if you have 
specifically hardware (EMS board) installed. You can not use any XMS, 
HMA or similar extensions, as those CPUs have only 20 address bits 
(A00-A19), resulting in a hard 1MB memory limit. There aren't any 
"games" you can play with the A20 line because there is no A20 on those 
CPUs.
That all just became possible with the arrival of the 80286 CPU, which 
allowed due to a bug/quirk in the CPU to have a wrap-around of the first 
64KB segment, which allowed for an address space of 1MB+64KB-16 bytes.

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=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG v0.99

[Bob Schwier]

On Wed, 9/2/15, Mateusz Viste <mate...@viste.fr> wrote:

 Subject: Re: [Freedos-user] FDNPKG v0.99
 To: freedos-user@lists.sourceforge.net
 Date: Wednesday, September 2, 2015, 1:37 AM
 
 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
 
 
 
--___
 Before it died, I had my last 8086 with 2M of higher memory.
bs
 

--
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=/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]

Hi Bob, Dennis,

Good point on these hardware EMS cards, it is indeed a way of providing 
additional memory irrespectively of the CPU model. I never had one of 
these, but I did hear about them. I stand corrected on that one! :)

cheers,
Mateusz



On 02/09/2015 18:12, dmccunney wrote:
> On Wed, Sep 2, 2015 at 1:37 AM, Mateusz Viste  wrote:
>> 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.
>
> And getting around the 640K limit was the reason for HIMEM,SYS, EMS,
> XMS, and playing games with the A20 address line.  I routinely used
> the capability when I *was* running on an 8086.  My old XT clone had
> an expansion card with a MB of additional RAM, split between a
> ramdisk, disk cache, and EMS memory for apps that could use it.  This
> all started back *before* the 286 and later 386 CPUs became common.
>
> If you wish to restrict yourself to 640K, feel free, but it's a
> choice, not a requirement.
>
>> Mateusz
> __
> Dennis
> https://plus.google.com/u/0/105128793974319004519
>


--
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=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDNPKG v0.99

[dmccunney]

On Wed, Sep 2, 2015 at 1:37 AM, Mateusz Viste  wrote:
> 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.

And getting around the 640K limit was the reason for HIMEM,SYS, EMS,
XMS, and playing games with the A20 address line.  I routinely used
the capability when I *was* running on an 8086.  My old XT clone had
an expansion card with a MB of additional RAM, split between a
ramdisk, disk cache, and EMS memory for apps that could use it.  This
all started back *before* the 286 and later 386 CPUs became common.

If you wish to restrict yourself to 640K, feel free, but it's a
choice, not a requirement.

> Mateusz
__
Dennis
https://plus.google.com/u/0/105128793974319004519

--
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=/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
>
--

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

[Mateusz Viste]

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

[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=/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 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

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=/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 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=/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]

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

[Freedos-user] FDNPKG v0.99

[Mateusz Viste]

Hello all,

Today I released a new version of FDNPKG. Nothing major here, just a few 
details that were a little annoying on the long run. See the changelog 
below.

FDNPKG v0.99 [31 Aug 2015]
  - [new] support for "link" files to include third-party apps into %PATH%,
  - [fix] compiled FDNPKG with -lemu for 387 emu, so it runs on a 386 
w/o FPU,
  - [fix] during download, progress is shown on a single line (with 
refresh),
  - [fix] version string parser recognizes v1.0.2 as being newer than v1.01,
  - [fix] support for ZIP files that do not contain directory entries 
(zip -D),
  - [fix] FDNPKG is not UPXed with LZMA anymore - loads 10x faster on my 
386SX,
  - [cfg] added repositories 'SOUND' and 'EDIT' to the default cfg file,
  - [cfg] sources install switched OFF by default.


Project's homepage: http://fdnpkg.sourceforge.net/

Of course FDNPKG can update itself - so if you already use it, then 
simply type "FDNPKG UPDATE FDNPKG" and you will be all set.

have fun,
Mateusz


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

Re: [Freedos-user] FDNPKG v0.99

[Dale E Sterner]

Is there an Ibiblio link for this?

DS



On Mon, 31 Aug 2015 19:29:00 +0200 Mateusz Viste 
writes:
> Hello all,
> 
> Today I released a new version of FDNPKG. Nothing major here, just a 
> few 
> details that were a little annoying on the long run. See the 
> changelog 
> below.
> 
> FDNPKG v0.99 [31 Aug 2015]
>   - [new] support for "link" files to include third-party apps into 
> %PATH%,
>   - [fix] compiled FDNPKG with -lemu for 387 emu, so it runs on a 
> 386 
> w/o FPU,
>   - [fix] during download, progress is shown on a single line (with 
> refresh),
>   - [fix] version string parser recognizes v1.0.2 as being newer 
> than v1.01,
>   - [fix] support for ZIP files that do not contain directory 
> entries 
> (zip -D),
>   - [fix] FDNPKG is not UPXed with LZMA anymore - loads 10x faster 
> on my 
> 386SX,
>   - [cfg] added repositories 'SOUND' and 'EDIT' to the default cfg 
> file,
>   - [cfg] sources install switched OFF by default.
> 
> 
> Project's homepage: http://fdnpkg.sourceforge.net/
> 
> Of course FDNPKG can update itself - so if you already use it, then 
> simply type "FDNPKG UPDATE FDNPKG" and you will be all set.
> 
> have fun,
> Mateusz
> 
> 
>
-
-
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
> 


**
>From Dale Sterner - MS organic chemistry
http://pubs.acs.org/doi/abs/10.1021/jo00975a052
***


Buffett’s New Enemy
Buffett just confirmed his worst fear. Click here for his warning.
http://thirdpartyoffers.juno.com/TGL3141/55e4baba7b3713aba35a8st04duc

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