Thanks to Eric, I can now report that the rapidly repeating error message
with the stable kernel is:
Enter the full shell command line: Bad or missing Command Interpreter: EEE
The three capitol E characters actually have an accent over them,
but I don't know how to type that. This error appear
Johnson Lam escreveu:
You mean FD DELTREE? perhaps you should register this to bugzilla.
If you're writing from scratch, why don't you rename it and replace
the current deltree?
It is too different to replace deltree. It does the same thing, but with
many many options.
Alain
--
At 10:21 AM 7/30/2005 +0800, Johnson Lam wrote:
Will this affect some old DOS programs that work under MS-EMM but
failed under FD-EMM?
Don't have any reports of this happening regarding VDS function failure, so
that's a rather theoretical question.
Per-spec exclusion of internal remapping a
On Fri, 29 Jul 2005 16:50:27 -0300, you wrote:
Hi,
I lost the previous mail.
>> You mean FD DELTREE? perhaps you should register this to bugzilla.
Can someone help? I'm too stupid to use bugzilla.
>deltree is vary bad, has allways been. Ever since drdos I use xdel, that
>is why I wrote a clon
On Fri, 29 Jul 2005 14:07:53 -0500, you wrote:
Hi Michael,
>If he's saying that we need to implement a more substantial lock/unlock,
>there is no case for doing so. The lock function returns all information
>related to physical memory contiguity. We explicitly flag and otherwise
>indicate th
On Fri, 29 Jul 2005 21:03:07 +0200 (MEST), you wrote:
Eric,
>Hi, Jack should shout less and should not cross-post the same mail
>on two lists... Whatever...
The cross-post is MY fault, don't blame him.
A teacher shout if the student did things wrong AGAIN and AGAIN.
Spending time and teaching i
On Fri, 29 Jul 2005 20:57:15 +0200, you wrote:
Hi,
>However, it's enough to keep this only on the developer list.
>Thank you for Jack's advice on this matter. However a patch to EMM386
>[ ftp://ftp.devoresoftware.com/downloads/emm386/emms204.zip ]
>would be even more usefull :)
Oops! It's my fa
Hi,
I just removed FreeDOS from my first real user. I believe that this is a
Kernel BUG. Let me describe the problem
I have a 16 bit utility (BC31) that writes backup to floppy disks.
Before writing, the floppy disks are erased. The problem is that when I
erase the files in the _second_ flop
Eric Auer escreveu:
- if could use int 21.330f, "get DOS-C release string pointer", to
show a message like
"FreeDOS kernel version 1.1.35w (Build 2035w-UNSTABLE, Jul 23 2005)"
If you look at version numbering, you will see that this is the *ONLY*
existing manet of identifying a kernel. V
>> at case 0x30 (on line 722) in KERNEL\KERNEL\INTHNDLR.C, it looks like
>> lr.CX is set to zero when it should be set to 0x0101. It does say that
>> 32RTM does not like non-zero values. Why?
...
Can we use DX instead? That would solve our problem?
Listen, I see NO problem at all here. Version nu
But this *is* very annoying. I even implemented a FDVER program that
also prints the KERNEL identification string which is the *only* way of
identifying a kernel (it's the message that goes at boot time)
I would like very much to this implemented...
Alain
Alex Buell escreveu:
It bothers me th
I have the english version all nicely wrapt up in GPL package. But...
last version is not compiling in english. I will send you one soon.
Thank you very much!
Because the FREE DELTREE always refuse to work properly.
You mean FD DELTREE? perhaps you should register this to bugzilla.
deltree
At 08:32 PM 7/29/2005 +0100, Alex Buell wrote:
It bothers me that VER /R doesn't correctly return the FreeDOS kernel
version. FREECOM\SHELL\VER.C gets the version string from registers CH, CL
and BX after making a INT 0x21, AH=0x30 call. That's ok. But I look at
case 0x30 (on line 722) in KERN
Hi,
> at case 0x30 (on line 722) in KERNEL\KERNEL\INTHNDLR.C, it looks like
> lr.CX is set to zero when it should be set to 0x0101. It does say that
> 32RTM does not like non-zero values. Why?
Because 32RTM is very stupid. It forgets to set CX to zero at some
later point, assuming that it will
At 08:57 PM 7/29/2005 +0200, Bernd Blaauw wrote:
However, it's enough to keep this only on the developer list.
Thank you for Jack's advice on this matter. However a patch to EMM386
[ ftp://ftp.devoresoftware.com/downloads/emm386/emms204.zip ]
would be even more usefull :)
All kinds of help do h
Hi, Jack should shout less and should not cross-post the same mail
on two lists... Whatever...
He writes that it is VERY important to have VDS because you must
know where the memory used for UMBs is physically, for DMA purposes.
And that you must allow programs to get a LOCK on that UMB/physical
Johnson Lam schreef:
Hi,
Jack R. Ellis have message:
hi Jhonson, thanks for reporting Jack's email.
I guess he's silently reading the freedos mailinglists after all :)
(maybe only even through the sourceforge or freedos.org webmail system)
However, it's enough to keep this only on the develop
Hi Arkady,
> + if (FAT32_Free_Space.free_clusters >= 0x8000l / clustersize)
> Should be `ul', else there is signed division. Or, use "> LONG_MAX /
> clustersize" (where LONG_MAX defined in limits.h as 0x7FFFl).
Good point.
> +for (shift = 21; --shift;)
> +
Hi,
Jack R. Ellis have message:
-
I have read all the comments on FD-User re: Mark Bailey's problem
using the FD-EMM386 "VDS" parameter. I also noted Mike DeVore's
reply, that using "VDS" only enables 32-bit physical addresses to
b
Hi!
27-Июл-2005 16:27 [EMAIL PROTECTED] (Kenneth Davis) wrote to
[EMAIL PROTECTED]:
KD> +++ dir.c 27 Jul 2005 16:27:22 - 1.23
KD> clustersize = FAT32_Free_Space.sectors_per_cluster
KD> * FAT32_Free_Space.bytes_per_sector;
KD> + if (clustersize)
KD> + if (FAT32_F
20 matches
Mail list logo
