OK, Mateusz, thanks for clarifying.
On 2/26/2016 11:49 AM, Mateusz Viste wrote:
> Hi,
>
> IIRC, FreeDOS 1.1 is broken by default when it comes to package
> management. Hopefully v1.2 will work better.
>
> As for now, you'd have to install packages via FDNPKG first, and only
> then these packages
Hi,
IIRC, FreeDOS 1.1 is broken by default when it comes to package
management. Hopefully v1.2 will work better.
As for now, you'd have to install packages via FDNPKG first, and only
then these packages will be detected and handled properly.
Example: FDNPKG INSTALL MEM
To answer your second
Hi Don,
> 1) BIOS Set in IDE emulation - NO issues with FDNPKG.
> 2) BIOS Set in Native SATA mode with AHCI.SYS, FDNPKG is prevented from
> extracting the executable files. Perhaps a security feature of this PC
No. AHCI / SATA is just the newer way of talking to various drives
compared to IDE.
Hi Mateusz,
Just wanted to give and update - Your FDNPKG is not the issue. After
checking every aspect of the installation process, changing my CDROM drive
and changing BIOS settings, I discovered the following about my HP Elite
8000 Desktop PC.
1) BIOS Set in IDE emulation - NO issues with
I am getting a (-15) error on almost every package in the NLS
extraction and the actual binaries. I eventually extracted the
"boot.img" and copied the new fdnpkg files to it and the extracted
the "all_cd" files to a directory on my hard drive and adjusted the
FDNPKG.CFG file. It works fine this
Thanks for the more detailed report. Can you confirm please that you get
all the "-15" errors using FNDPKG v0.99.3, and not any earlier version?
To know the exact version you are using, simply run FDNPKG without any
arguments. It will print its version somewhere at the top of the screen.
-15
I just boot the latest all_cd.iso and the fdnpkg version on it is 0.96
On Wed, Nov 25, 2015 at 3:48 PM, Don Flowers wrote:
> Hey Mateusz,
> I usually start my clean install from the all_cd.iso with FDNPKG install
> kernel, but since you announced the update to FDNPKG, I tried
Hey Mateusz,
I usually start my clean install from the all_cd.iso with FDNPKG install
kernel, but since you announced the update to FDNPKG, I tried to install
FDNPKG first. After loading the db to temp it begins the install but then
produces several (-15) errors in the DOC, NLS and BIN directory
On 25/11/2015 02:05, Don Flowers wrote:
> Been having trouble - did you update the boot.img my fdnpkg is all out
> of whack.
That's unlikely. I included more than enough of whack inside FDNPKG so
it never runs out of it. Surely the problem must be different.
Mateusz
> On Tue, Nov 24, 2015
Okay, I'm not sure I understand the wholeness of your situation, but is
it right to sum it up like this? "you had troubles because of using a
severly outdated FDNPKG v0.96 that was embedded inside the boot.img
portion of all_cd.iso" ?
If that's correct, then the problem should be gone by now,
Been having trouble - did you update the boot.img my fdnpkg is all out of
whack.
On Tue, Nov 24, 2015 at 11:44 AM, Mateusz Viste wrote:
> On 24/11/2015 16:32, Dale E Sterner wrote:
> > Is there an Ibiblio link?
>
> As usual, yes :)
>
>
>
On 24/11/2015 16:32, Dale E Sterner wrote:
> Is there an Ibiblio link?
As usual, yes :)
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/util/fdnpkg.zip
Also updatable from itself, ie: FDNPKG UPDATE FDNPKG
Mateusz
> On Mon, 23 Nov 2015 18:40:41 +0100 Mateusz
Is there an Ibiblio link?
DS
On Mon, 23 Nov 2015 18:40:41 +0100 Mateusz Viste
writes:
> Hi all,
>
> I released FDNPKG v0.99.3 today. This is a purely bugfix release,
> I'd
> highly recommend upgrading any older version.
>
> FDNPKG v0.99.3 [23 Nov 2015]
> - [fix] files
On 15/11/2015 14:30, Don Flowers wrote:
> I have been reinstalling FreeDOS and have my NIC card setup,
> I have a working connection (am writing this from my DILLODOS browser)
> but cannot get a download from FDNPKG. I can download to my HD and then
> install
> but FDNPKG is stalling.
Are you
I am back in Windows for the moment. I was trying to install assign ( I
overlooked it in my list) the syntax I used is FDNPKG INSTALL ASSIGN, then
it goes to the ibiblio BASE repo and stops, it previously gave the failed
to download repo error but then gave notice of an update (curious?) but
will
>> 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
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
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.
--
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
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 a
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,
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
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
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
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
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
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
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
--
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" ;)
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
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
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.
Hi, I'm temporarily hijacking this thread for FDNPKG's agenda :)
On 11/06/2015 22:55, Rugxulo wrote:
FDNPKG is a great idea, but we need more package(r)s. Well, I did try
to install something from there yesterday (under QEMU to RAM disk),
but it seemed to expect c:\games hardcoded. (Maybe I'm
Hi,
BTW, thanks for responding to this.
On Fri, Jun 12, 2015 at 12:59 AM, Mateusz Viste mate...@viste.fr wrote:
Hi, I'm temporarily hijacking this thread for FDNPKG's agenda :)
You're of course welcome to do so.
On 11/06/2015 22:55, Rugxulo wrote:
FDNPKG is a great idea, but we need more
On 12/06/2015 16:56, John Hupp wrote:
I agree that there is no perfect solution. But the same is true on
other platforms. Look at common Linux distributions: repositories of
vetted apps, hosted on servers that get special attention, with a single
update channel that keeps everything up to
On 6/12/2015 9:07 AM, Rugxulo wrote:
It's just that there is no perfect solution, sadly.
I agree that there is no perfect solution. But the same is true on
other platforms. Look at common Linux distributions: repositories of
vetted apps, hosted on servers that get special attention, with a
On 08/15/2014 03:01 PM, Tom Ehlert wrote:
it should have been
c:\USR\BIN\ZIP %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
Okay, I understand now, you were simply trying to be able to use 10
parameters instead of 9. I didn't ever think about this limitation,
since 9 parameters were always enough for
On 8/14/2014 3:52 AM, Mateusz Viste wrote:
Hi Ulrich,
Thanks for your feedback!
On 08/14/2014 12:05 AM, Ulrich wrote:
FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN.
This is not really about FDNPKG, but more about how packages are
structured. Indeed, I tend to
On 08/15/2014 01:24 AM, Ulrich wrote:
Yes I think this a good idea. About the PATH: What about creating an external
batchfile like C:\PKGS.BAT, that is automatically called by AUTOEXEC.BAT?
FDNPKG could update the PATH statement according to each package. The
content, for example:
This is not really about FDNPKG, but more about how packages are
structured. Indeed, I tend to avoid putting to much stuff into
%FREEDOS%\BIN, and only put there stuff that is supposed to be part of
the FreeDOS core (ie BASE, that is similar functionality than what
MSDOS was providing).
'Which means Accept what the package manager does by default. I
mostly concur, but an advanced user might have reasons for wanting
things elsewhere. It's nice it the package manager gives them an
option to do so and specify where, but if it needs AUTOEXEC.BAT
modified for things to work as
Hi Tom,
On 08/15/2014 12:29 PM, Tom Ehlert wrote:
a better way to achieve the same effect would be a directory on the
PATH with batches that redirect to the proper location.
ZIP.BAT
shift
c:\USR\BIN\ZIP %1 %2 %3 %4 %5 %6 %7 %8 %9
Exactly what I was saying, yes. For now, that's my
Hi Mateusz,
On 08/15/2014 12:29 PM, Tom Ehlert wrote:
a better way to achieve the same effect would be a directory on the
PATH with batches that redirect to the proper location.
ZIP.BAT
shift
c:\USR\BIN\ZIP %1 %2 %3 %4 %5 %6 %7 %8 %9
Exactly what I was saying, yes.
exactly. I
Yes, this would be cool indeed. Any volunteers? :)
In fact, we almost have such 1.11 distro: all_cd is pretty much working,
only requires a 'smart' installer (like the one we had in 1.0 or 1.1),
and maybe a downgrade of FDISK (if confirmed that the version is causing
the vbox
Hi Ulrich,
Thanks for your feedback!
On 08/14/2014 12:05 AM, Ulrich wrote:
FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN.
This is not really about FDNPKG, but more about how packages are
structured. Indeed, I tend to avoid putting to much stuff into
I know Masteusz has put in a lot of work into FDNPKG. One thing I
really appreciated when I transitioned to Linux almost 20 years ago
was how good the documentation was. Especially when I used Crux Linux
and their ports package system [0]. How to make a package, how to use
the various commands,
On Thu, Aug 14, 2014 at 3:52 AM, Mateusz Viste mate...@viste.fr wrote:
[SNIP]
This is not really about FDNPKG, but more about how packages are
structured. Indeed, I tend to avoid putting to much stuff into
%FREEDOS%\BIN, and only put there stuff that is supposed to be part of
the FreeDOS core
On 08/14/2014 04:36 PM, Louis Santillan wrote:
One school of thought is the NextSTEP style folders [0]. So you would
have functionally named folders /System, /User, /Programs, /Games,
etc.
This is actually how it already works. FDNPKG uses 'categories' of
software, and puts software there at
Hi,
I am unsure whether you are thinking about documentation for packaging
(ie. creating packages) or documentation for FDNPKG... These are two
different things.
If you are looking for pointers about how to create package, you might
find some good information to start here:
If, on the other
On Thu, Aug 14, 2014 at 10:54 AM, Mateusz Viste mate...@viste.fr wrote:
But the question now is different (I took the liberty to change the
subject of this message accordingly): where would you put applications
that need to be reachable from %PATH% ?
From a system viewpoint, it doesn't
oops, forgot to paste the link.. The packaging documentation link was
meant to be this:
http://www.freedos.org/wiki/index.php/Package
Mateusz
On 08/14/2014 05:44 PM, Mateusz Viste wrote:
Hi,
I am unsure whether you are thinking about documentation for packaging
(ie. creating packages)
Am 14.08.2014 um 17:51 schrieb dmccunney dennis.mccun...@gmail.com:
On Thu, Aug 14, 2014 at 10:54 AM, Mateusz Viste mate...@viste.fr wrote:
But the question now is different (I took the liberty to change the
subject of this message accordingly): where would you put applications
that need
That's good information. I don't think I had seen that before.
On Thu, Aug 14, 2014 at 8:52 AM, Mateusz Viste mate...@viste.fr wrote:
oops, forgot to paste the link.. The packaging documentation link was
meant to be this:
http://www.freedos.org/wiki/index.php/Package
Mateusz
On
Am 14.08.2014 um 12:52 schrieb Mateusz Viste mate...@viste.fr:
Thanks for your feedback!
Thanks for yours :-)
On 08/14/2014 12:05 AM, Ulrich wrote:
FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN.
This is not really about FDNPKG, but more about how packages
On Thu, Aug 14, 2014 at 5:33 PM, Ulrich my.gr...@mailbox.org wrote:
Am 14.08.2014 um 17:51 schrieb dmccunney dennis.mccun...@gmail.com:
On Thu, Aug 14, 2014 at 10:54 AM, Mateusz Viste mate...@viste.fr wrote:
But the question now is different (I took the liberty to change the
subject of this
On Thu, Aug 14, 2014 at 7:24 PM, Ulrich my.gr...@mailbox.org wrote:
Am 14.08.2014 um 12:52 schrieb Mateusz Viste mate...@viste.fr:
Now the question is where to put any 3rd party apps that are still
supposed to be callable from anywhere in the directories tree? One
option could be to create
On 08/13/2014 01:46 AM, Ulrich wrote:
Unfortunately it isn't so easy. I just tried to remove/reinstall UIDE in
FreeDOS 1.1. The C:\FDOS\PACKAGES\UIDEX.LST file in FD1.1 doesn't include
xmgr.sys and rdisk.com. So when uninstalling UIDEX these are not removed. And
when reinstalling UIDE,
Hi Mateusz,
obviously FDNPKG installs a few things differently than the FreeDOS 1.1 CD. So
it's hard to say what is a bug, what is a feature.
FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN. So
mTCP will not work with an AUTOEXEC.BAT from 1.1, the user needs to add
On 08/11/2014 09:07 PM, Ulrich wrote:
So doing a FDNPKG update from time to time could make FreeDOS a kind of a
rolling release (or at least create a testing branch).
I'm glad you think so, since that's exactly the motivation that led me
to creating FDNPKG in the first place :)
- Users of
Hi again,
On Aug 11, 2014 4:49 AM, Mateusz Viste mate...@viste.fr wrote:
About FDISK incompatibility: I am getting an error message Error
Reading Hard Disk: Function number of drive not permitted. Is it what
you end up with, too? If so, then it appears to be a problem only if you
run FDISK
Am 12.08.2014 um 20:23 schrieb Mateusz Viste mate...@viste.fr:
On 08/11/2014 09:07 PM, Ulrich wrote:
So doing a FDNPKG update from time to time could make FreeDOS a kind of a
rolling release (or at least create a testing branch).
I'm glad you think so, since that's exactly the motivation
Hi again,
I looked into the issue, by installing a fresh FreeDOS 1.1 inside a
vbox, and booting all_cd on top of it. Now:
FDNPKG freezing: debugging this really scares me. I wanted to check if
there's some memory leak maybe, and typed MEM in the vbox shell where
I launched FreeDOS... The
Hi Rugxulo,
Thanks for your offer, but I managed to reproduce the various problems
easily on a small vbox FreeDOS install, so I should have enough to
investigate :)
And yes, the vbox guest environment is quite confusing indeed... hard to
sort out real bugs out of buggy vbox behavior (but at
Hi,
On Mon, Aug 11, 2014 at 4:49 AM, Mateusz Viste mate...@viste.fr wrote:
About FDISK incompatibility: I am getting an error message Error
Reading Hard Disk: Function number of drive not permitted. Is it what
you end up with, too? If so, then it appears to be a problem only if you
run FDISK
But have you booted from a floppy (1.4M image), or from an emulated
floppy (as a CD) ?
The problem seems to appear when one boots from a CD with floppy
emulation, and fdisk being ran from the said emulated floppy...
cheers,
Mateusz
On 08/11/2014 04:34 PM, Rugxulo wrote:
Hi,
On Mon, Aug
Hi,
On Aug 11, 2014 9:44 AM, Mateusz Viste mate...@viste.fr wrote:
But have you booted from a floppy (1.4M image), or from an emulated
floppy (as a CD) ?
Just floppy, no CD anything.
The problem seems to appear when one boots from a CD with floppy
emulation, and fdisk being ran from the
Mateusz, thanks a lot for looking into the problem!
I think FDNPKG could be really useful. FreeDOS 1.1 is two and a half years old
and at least some programs are under active development. So doing a FDNPKG
update from time to time could make FreeDOS a kind of a rolling release (or at
least
Hi Ulrich,
Thank you for your report.
This sounds unfortunate :)
It seems you have three different problems.
About fdisk: could you tell more about the problem? What version of fdisk works
correctly for you?
About missing versions: could you please locate the *.lsm file of one of the
Hi,
On Sun, Aug 10, 2014 at 8:57 PM, Mateusz Viste mate...@viste.fr wrote:
About fdnpkg freezing: how could I reproduce this problem exactly? Should it
be enough to just install
freedos 1.1 on virtualbox, without any special configuration, and boot the
latest version of all_cd.iso
on top
Mateusz Viste schreef op 13-10-2013 23:56:
Of course, if you have plenty of disk space, you might want to copy
these repositories to your hard disk, and make the repositories pointing
there.
I think Mark ment pointing to the ISO file, but I guess no native ISO
support is implemented, so a CD
Hi Mateusz,
FDNPKG was not 'installed' before, but just wildly decompressed
!
The solution is to move all the files that you decompressd
manually somewhere else, and then run fdnpkg install fdnpkg
to install fdnpkg for real :)
It worked, as we can see by the messages:
Downloading...
Hi Marcos,
That's great, I'm glad you sorted it out :)
cheers,
Mateusz
On 10/12/2013 02:54 PM, Marcos Favero Florence de Barros wrote:
Hi Mateusz,
FDNPKG was not 'installed' before, but just wildly decompressed
!
The solution is to move all the files that you decompressd
manually
Mateusz Viste schreef op 12-10-2013 16:52:
Hi Marcos,
That's great, I'm glad you sorted it out :)
Does the program have to write all the mkdir lines all the time when
installing a package? I'd expect only the non-existing ones to be listed.
mkdir C:\FDOS\doc\fdnpkg\
instead of:
Hello Bernd,
On 10/12/2013 05:01 PM, Bernd Blaauw wrote:
Does the program have to write all the mkdir lines all the time when
installing a package? I'd expect only the non-existing ones to be listed.
Indeed, this is useless. It never bothered me, but you are right - it's
useless, and it takes
Mateusz Viste schreef op 12-10-2013 21:28:
This could be an interesting feature. It doesn't make as much sense as
in a linux distro, because there is no dependencies between FreeDOS
packages, but it could be nice anyway to be able to install a few
packages in one command (especially when they
Mateusz Viste schreef op 12-10-2013 21:52:
argument). So for such need, a full-blown script (like the one you did)
will probably be inevitable anyway...
I'm lazy, so prefer INSTALL KERNEL instead of remembering to type FDNPKG
INSTALL KERNEL. Even for a single package thus :)
Something like
Thank you, Mateusz!
-Toby
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
Hi Marcos,
That's interesting. It looks like your current FDNPKG installation is
not recognized as a package, so FDNPKG don't want to touch these old
files, because it thinks that they belong to something else than the
package in older version.
What do the command 'fdnpk checkupdates' say (if
Okay, that's it then.
FDNPKG was not 'installed' before, but just wildly decompressed, so
FDNPKG can't know where these files come from, and won't take the risk
to overwrite something potentially valuable.
This is also the reason why FDNPKG can't find any update for itself.
Because, simply,
Hi,
On Sun, Jul 21, 2013 at 1:59 PM, Mateusz Viste mate...@viste-family.net wrote:
I released a minute ago a new version of FDNPKG.
The exact changelog of the v0.96 follows:
FDNPKG v0.96 [21 Jul 2013]
Just FYI, I updated the online .LSM and mirrored this to iBiblio:
Mateusz++; :)
Geraldo Netto
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
On 11 July 2013 13:58, Mateusz Viste mate...@viste-family.net wrote:
Hi all,
I am glad to announce the release of a new version of the FreeDOS
network package manager: FDNPKG v0.95
Hi,
On Wed, Jun 19, 2013 at 3:07 PM, Mateusz Viste mate...@viste-family.net wrote:
I'm happy to announce the release of a new version of my FreeDOS package
manager - FDNPKG v0.94.
Jim just announced this in News for you.
Big changes: this new version brings support for offline (on disk)
On 19.06.13 23:07, Mateusz Viste wrote:
I'm happy to announce the release of a new version of my FreeDOS package
manager - FDNPKG v0.94.
Big changes: this new version brings support for offline (on disk)
repositories, and update features (FDNPKG is able to update itself now).
Great! This
Hi,
Yes, this is a feature that i was thinking for a long time now.
However it doesn't replace the tool that Matej did, since the latter have a
very specialized purpose of getting only packages that you miss. The offline
repo of Fdnpkg is a more generic approach. Choice is always good :)
Hi,
Since now, I will also periodically compute an ISO with all FDNPKG
repositories. This makes it easy to download all the up to date packages
in one file, burn it on a CD, and feed FDNPKG with on offline FreeDOS
systems.
The ISO is here:
Hi,
Sorry in advance for too many details, but in case anybody cares
On Sun, Nov 11, 2012 at 11:16 AM, Mateusz Viste
mate...@viste-family.net wrote:
You could give a try with the new version of FDNPKG (v0.91, released a
few minutes ago) - I don't think it will change much, but one
Hi again,
I don't really have a working packet driver except under VirtualBox,
which is slightly buggy. I had to grab FDNPKG itself (from iBiblio via
mTCP FTP) and manually install it, but running it didn't download the
.ZIP correctly (tmpfile error, which I've noticed before, pretty sure
it's
Great news, thanks! I will look into this asap.
About index.lst - yeah, it's better to not touch it manually, in fact,
I'm using an automatic generator to compute it, so I will recompute it
soon to include the new Freedoom.
thanks
Mateusz
On 10/31/2012 01:55 AM, Rugxulo wrote:
Hi,
On
Hi,
On Mon, Oct 15, 2012 at 11:49 AM, Mateusz Viste
mate...@viste-family.net wrote:
I will gladly accept your repackaged version of FreeDOOM and add it to
the FDNPKG repository (as well as any other packages that might be
contributed by willing volunteers) :)
I finally uploaded a new
Hi again,
Just to follow up on this
On Mon, Oct 22, 2012 at 10:18 PM, Rugxulo rugx...@gmail.com wrote:
On Wed, Oct 17, 2012 at 3:42 PM, Rugxulo rugx...@gmail.com wrote:
On Mon, Oct 15, 2012 at 11:49 AM, Mateusz Viste
mate...@viste-family.net wrote:
I will gladly accept your
Hi,
On Wed, Oct 17, 2012 at 3:42 PM, Rugxulo rugx...@gmail.com wrote:
On Mon, Oct 15, 2012 at 11:49 AM, Mateusz Viste
mate...@viste-family.net wrote:
I will gladly accept your repackaged version of FreeDOOM and add it to
the FDNPKG repository
I'd like to successfully rebuild first,
Hi,
On Mon, Oct 15, 2012 at 11:49 AM, Mateusz Viste
mate...@viste-family.net wrote:
I will gladly accept your repackaged version of FreeDOOM and add it to
the FDNPKG repository (as well as any other packages that might be
contributed by willing volunteers) :)
It shouldn't be too hard to
Hi Rugxulo!
I will gladly accept your repackaged version of FreeDOOM and add it to
the FDNPKG repository (as well as any other packages that might be
contributed by willing volunteers) :)
About packaging - I still have to think about modifying the packaging
style for FreeDOS packages, to make
Hi Mike!
On 10/14/2012 04:57 PM, Michael B. Brutman wrote:
I noted that FDNPKG is using WatTCP - I don't see that as a problem.
While I prefer mTCP and I think it has many advantages (speed, size, bug
fixes, etc.) WatTCP works well enough and people are comfortable with
it. I also have a
Op 14-10-2012 0:31, Rugxulo schreef:
There are some people who seriously wanted such a thing for FreeDOS,
e.g. some random dude on OS News when FD 1.1 was announced. So I guess
he'll finally be glad, heh.
From what I've noticed it's a big binary, likely due to including
wattcp and perhaps
Hello,
On 10/14/2012 12:31 AM, Rugxulo wrote:
I haven't looked closely yet, curious what it's written in (presumably C).
Yes, ANSI C89, compiled with DJGPP.
Do you have packet driver emulation enabled in DOSEMU? I never did
understand how to get that working (to say the least). Hence my only
I noted that FDNPKG is using WatTCP - I don't see that as a problem.
While I prefer mTCP and I think it has many advantages (speed, size, bug
fixes, etc.) WatTCP works well enough and people are comfortable with
it. I also have a slight bias, so I am trying to be objective. ; - 0
The
is the WatTCP program doing something anti-social like calling exit and
killing the program outright?
WATTCP programs generally start by calling sock_init() Sock_init() will exit
the program if a packet driver is not found. If your program might have some
useful purpose without TCP/IP
Hi,
On Sun, Oct 14, 2012 at 6:26 AM, Mateusz Viste mate...@viste-family.net wrote:
I saw this, but I can already tell some of it needs updating, e.g.
FreeDoom.
I'm not a big expert on Doom, and available ports or forks today.. I
think that I simply took the FD 1.0 package on this one. :)
Hi,
On Sun, Oct 14, 2012 at 9:57 AM, Michael B. Brutman
mbbrut...@brutman.com wrote:
Regarding the makefile errors - I do not compile in DOS. My preferred
DOS machine is an 80386DX-40 and compiling using OpenWatcom crushes that
machine. It is far more productive to work in Windows or Linux
1 - 100 of 101 matches
Mail list logo