> the data from XMS... There might be some code which decides about
> whether restore-from-XMS is needed and which is too optimistic. But
> maybe I am totally wrong about that whole swap/overwrite topic...
>From what I can tell it always swaps back from XMS and there is no
other memory block that
>
> To be honest, since Jeremy disappeared I have little hope that
> there will be a 2039 unstable. I assume that 2039 will instead
> be a 2038 with some 2037 backport parts added, 2040 will have
> some more, and so on, until the rest of unstable can hibernate
> around in peace, waiting for anybody
Hi Blair, Christian,
> IIRC chkdsk does not support FAT32 filesystems. This might be your issue.
> On Thu, Apr 2, 2009 at 1:32 PM, Christian Groessler wrote:
>> When I run "dosfsck c:" it reports everything ok:
>>
>> dosfsck 2.11.DOS, 15 Apr 2006, FAT32, LFN
>> c:: 4191 files, 6623/62597 clus
Hi Alex,
> On Sun, 08 Mar 2009 16:20:40 +0100, I waved a wand and this message
> magically appears in front of Eric Auer:
>
>> Indeed a very annoying bug in FreeCOM 0.84 but nobody has yet found
>> a way to predict WHEN it happens. If you can find a way to make it
>> happen at a more specific tim
Hi Jim,
>> The current numbering is that "stable plus patches" will be
>> 2038 while unstable is 2037 (next unstable will be 2039)...
>> Both branches are based on kernel 2035 and for a while they
>> even both used 2035 as version number(s), unfortunately.
>> While it does not have a SF file rel
Jim Hall schreef:
> The problem is: how will you (Eric) know that the patches will work?
> How long do you intend to hold back the 2038 version before deciding
> it is "good enough"?
>
I'd agree with Jim here, release, then ask feedback. People might lack
the skill to comment on individual patc
On Sat, Apr 25, 2009 at 10:59 AM, Eric Auer wrote:
>
> Hi Christian,
>
>>> If you're waiting for further improvements to 2038 before you release
>>> 2038, then you're doing this wrong. [...] I'd strongly recommend
>>> making 2038 available, and putting the "few pending improvements" in
>>> 2039.
>
On Sat, Apr 25, 2009 at 11:31 AM, Eric Auer wrote:
[...]
> The current numbering is that "stable plus patches" will be
> 2038 while unstable is 2037 (next unstable will be 2039)...
> Both branches are based on kernel 2035 and for a while they
> even both used 2035 as version number(s), unfortunate
Hi Jim,
> I disagree with your "No, but you could say it is stable enough"
> statement. The kernel needs to work reliably. Today, we have two
> branches of the FreeDOS kernel: 2036 stable, and 2037 devel
> (unstable). That shouldn’t be ok, yet somehow we’ve convinced
> ourselves this is acceptabl
Hi Roberto, Mateusz,
>> About Freecom: I suppose that CVS version "1.34 2004/12/01 21:20:46" is
>> the same as SVN "Revision 1067**
SVN gives numbers for the whole state, CVS gives numbers per file.
I think you can tell both SVN and CVS to show you "the version of
everything which was current
Hi Robert,
> 1) ftp://ftp.simtel.net/pub/simtelnet/msdos/arcers/jam125sw.zip
> JAM is a transparent hard disk compressor, which enlarges your disk
> space. With the JAM you will forget about annoying messages like
> 'Insufficient disk space...' with no need to purchase a new hard disk.
It only m
Hi Christian,
>> If you're waiting for further improvements to 2038 before you release
>> 2038, then you're doing this wrong. [...] I'd strongly recommend
>> making 2038 available, and putting the "few pending improvements" in
>> 2039.
>
> The problem is that Eric holds back at least three neces
Hi Mateusz,
>> Is it still possible to use FDUPDATE on FreeDOS 1.0 or to upgrade 1.0
>> to 1.1? I think FDUPDATE detects when you're running 1.0 and won't
>> update, but I'm not sure how it does this.
> Yes, it is possible to use FDUPDATE to keep a 1.0 system up to date. However,
> you won't be
Hi Aitor,
> Eric, was the "windows" (partial) support" ever
> ported to the stable kernel? (maybe that's why).
That partial support is based on "heavy" patches it
seems... As said, the windows 386 mode support even
in the unstable kernel is not compiled in by default
because it is more experimen
Hi Michael,
> How about games made for the Tandy Color Computer 3 by Diecom Products?
> That company is now defunct and has been for a very long time. You
> can download disk images of Guantlet II. Is that really illegal?
As the company is defunct, it is unlikely that they will sue you.
But ma
Hi,
> Has anyone gotten fdupdate to work with a 486? I lost the link to
> fdupdate v0.55 and the instructions on how to use it in fdupdate
> v0.54. If using a 486 is the problem because of a bug in the math
> coprocessor or something similar, that would be nice to know.
>
> I've noticed that I
16 matches
Mail list logo
