Hi!
5-Авг-2006 21:48 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:
EA> Also freeware.
EA> Well, TASM is not, but Arkady even has TASM.
I may switch to NASM, if me will be explained, how to switch to it
(through NoMySo?) in case of EMM386. Then I may even add SE
Hi Arkady, Michael, I think we are getting closer :-).
> Yes, because it not updated together with HIMEM/EMM386 (and currently
> not working), and it tied to TCPP. (This why I use above word "added"
> instead "updated").
It is perfectly okay to support only TC++ at the moment. Also freeware.
Wel
Hi!
1-Авг-2006 16:52 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> Currently EMM386 isn't complete - there are no working build batch
>> files, so only you yourself may compile EMM386 (and check result).
MD> EMM386 is sufficiently complete for now: it works
At 01:02 AM 8/2/2006 +0400, Arkady V.Belousov wrote:
> Though, I don't understand, why to AVB> duplicate all pops on each exit
> branch, whereas you may just move push "move _pushf_" AVB> after
> other pushes?
Because it was not prone to any introduced error that way. Many pushes in
man
Hi!
2-Авг-2006 00:53 Arkady V.Belousov wrote to
freedos-devel@lists.sourceforge.net:
MD>> out of memory prematurely when free areas were available. Okay, that was
MD>> worth the entire thread.
AVB> :) And this is FIXED in 2.21. Though, I don't understand, why to
AVB> duplicate all pops on
Hi!
30-Июл-2006 22:32 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>0. In emm386.c you forget remove one space (in "/ *").
MD> And? It's a comment. Is there another one of those #ifdef 0 type
MD> things? Because I'm not ready to debate the style of embedded
On Sun, 30 Jul 2006, Michael Devore wrote:
> Fixed, although I'm not sure a 286 would get there. Does UPX decompressor
> run under non-386? If not, the decompression code will stop it first.
Yes. I've run UPX'd binaries on 8086 (Tandy 1000HX) before
-uso.
---
At 07:48 AM 7/29/2006 +0400, Arkady V.Belousov wrote:
>0. In emm386.c you forget remove one space (in "/ *").
And? It's a comment. Is there another one of those #ifdef 0 type
things? Because I'm not ready to debate the style of embedded comments again.
>1. Bug: wrong handling for clc/stc i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Japheth wrote:
>> Japhet, how did you traced the IF problem with QEMU ?
>
> What do you mean with "how did you trace the IF problem"?
> I run ctmouse under debugger control inside qemu of course. There was no
> magic.
Do you mean a debugger running
> Japhet, how did you traced the IF problem with QEMU ?
What do you mean with "how did you trace the IF problem"?
I run ctmouse under debugger control inside qemu of course. There was no magic.
-
Take Surveys. Earn Cash. Inf
Hi!
28-Июл-2006 23:13 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> >> ...but if you not object, I rewrote for you DefragXMS.
MD> You or anyone else can rewrite and submit whatever code you want with my
MD> blessing. The rules are simple:
[...]
We
At 07:48 AM 7/29/2006 +0400, Arkady V.Belousov wrote:
> ...but if you not object, I rewrote for you DefragXMS.
You or anyone else can rewrite and submit whatever code you want with my
blessing. The rules are simple:
1) As maintainer, I am the final decision maker if the change goes in. I
At 04:41 AM 7/29/2006 +0200, Japheth wrote:
> > Since low-level changes were made to this version of EMM386, please
> keep an
> > eye out for any problems and report them as soon as you can. While I
> don't
>
>The IF bug fix may have disclosed some previously hidden bugs which are
>due to
>a ca
> Since low-level changes were made to this version of EMM386, please keep an
> eye out for any problems and report them as soon as you can. While I don't
The IF bug fix may have disclosed some previously hidden bugs which are due to
a careless handling of flags. The following is an excerpt fr
At 05:03 PM 7/28/2006 +0400, Arkady V.Belousov wrote:
>_
>O/~\ /~\O 6. Superfluous code (not need to
>check, if block at [edi] precedes block at[esi], because they will be
>found at next iter
Hi!
28-Июл-2006 13:28 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>MD> There! Right there! Whatever you're doing there, keep it up. You
>>have MD> CR's in your e-mail message.
>> Yes, because I right mailer. :)
"Because I _use_ right mailer".
At 10:02 PM 7/28/2006 +0400, Arkady V.Belousov wrote:
>MD> There! Right there! Whatever you're doing there, keep it up. You
>have MD> CR's in your e-mail message.
> Yes, because I right mailer. :) But, I suggest, most mailers may be
> customized
Yargh! Back to the old format. Your's a
Hi!
28-Июл-2006 11:21 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD>
MD> I can't tell yet because there's either a missing e-mail on list from you,
But you answer to my email?
MD> or it's just because all your e-mails to the list are mashed together
M
Hi!
28-Июл-2006 12:39 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> X-Mailer: QUALCOMM Windows Eudora Version 5.1
>>7. Code below is buggy (counted not expected bits - should be used SHL
>>instead SHR) or redundant (result is always zero additions):
MD>
At 05:03 PM 7/28/2006 +0400, Arkady wrote:
I can't tell yet because there's either a missing e-mail on list from you,
or it's just because all your e-mails to the list are mashed together
without any CR's and it's hard for me to parse them out, but it looks like
you're sending me code optimiz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello
I have testet the version 2.20 of EMM386 under QEMU. The good news is,
that the PS/2 driver of GEOS now works. Unfortunatly, it seems that this
version breaks FDAPM. I use FDAPM to keep the CPU load off QEMU low and
to shut down the QEMU instanc
At 06:36 PM 7/28/2006 +0400, Arkady V.Belousov wrote:
>Hi!
>
>MD> emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files;
>
> One more place:
>
>7. Code below is buggy (counted not expected bits - should be used SHL
>instead SHR) or redundant (result is always zero additi
Hi!
MD> emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files;
One more place:
7. Code below is buggy (counted not expected bits - should be used SHL
instead SHR) or redundant (result is always zero additions):
__O\_/_\_/O__
Hi!
28-Июл-2006 15:36 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
> 1. Bug: wrong handling for clc/stc in some places (they ignored, because
>popf follows, thus caller receives "always success"):
> @@loc2:
> clc ; flag
> 1. Bug: wrong handling for clc/stc in some places (they ignored, because
>popf follows, thus caller receives "always success"):
>
> __O\_/_\_/O__
> @@loc2:
> [...]
> clc ; flag success
> @@l
Hi!
28-Июл-2006 00:05 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
MD> emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files;
MD> and emms220.zip, source code files.
> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
> emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files;
> and emms220.zip, source code files.
Thanks :-).
> This release of EMM386 and HIMEM has several changes and fixes, two of a
> low-level nature, b
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files;
and emms220.zip, source code files.
This release of EMM386 and HIMEM has several changes and fixes, two of a
low-level nature, but at a guess, relati
At 03:23 AM 7/27/2006 +0200, Eric Auer wrote:
>Eric indicated I need to allow local A20 control, but
>as it turns out, that won't help. EXEPACK code simply doesn't call
>A20
>routines, so EMM386 cannot fix this problem. It never "sees" the
>wrap
>occurring. The situation has to be corrected
Hi everybody,
we don't need to get so excited. A new guy that apparently was not used
to this kind of list posted a few messages. I believe now that he
understands better and can be forgiven. Don't we get so excited amongst
ourselves...
Michael Devore escreveu:
> At 02:39 PM 7/20/2006 +0800, "
Hi!
20-Июл-2006 12:36 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
>> Strange. I was think, that "bugzilla", "private email" or "post in
>> group" is only ways to transfer reports to author and have nothing with
>> "distance between me and program".
J> Bugzilla i
> btw: it looks to me as if japeth wrote a tiny program to produce the
> bug; it's always helpful for maintainers if they get this
> program/source/description how to reproduce,
> so the time to reproduce the bug (and thereby time
> spend on the problem) is significant reduced, and often motivation
>>Seems FD-HIMEM can't do a MERGE with others free blocks, even the
>>MS-HIMEM did the job well. My friend told me how but sorry I'm not
>>allow to tell details,
Wow. 'I'm not allowed to tell the details...' seems to suggest that's
it's some ingenious (patent pending) technology art.
In fact it's m
Arkady V.Belousov wrote:
> Hi!
>
> 20-Июл-2006 12:09 [EMAIL PROTECTED] (Japheth) wrote to
> freedos-devel@lists.sourceforge.net:
>
>
>>> Do you think, that "distance" allows/mean more rude behavior?! :) :(
>>>
> J> No, it means using Bugzilla for bug reports - if anything at all. :)
At 05:50 PM 7/20/2006 +0800, Johnson Lam wrote:
>On Thu, 20 Jul 2006 03:52:02 -0500, you wrote:
>
> >>XMS free blocks fragmentation ... they should not exist (now is 21
> >>century!). I hope he found the time to fix it.
> >
> >Fragmentation always exists, and if you were a programmer you would know
> Strange. I was think, that "bugzilla", "private email" or "post in
> group" is only ways to transfer reports to author and have nothing with
> "distance between me and program".
Bugzilla is more complicated and you have to login - several - times. That
makes you think twice before you inde
Hi!
20-Июл-2006 12:09 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
>> Do you think, that "distance" allows/mean more rude behavior?! :) :(
J> No, it means using Bugzilla for bug reports - if anything at all. :)
Strange. I was think, that "bugzilla", "privat
> Do you think, that "distance" allows/mean more rude behavior?! :) :(
No, it means using Bugzilla for bug reports - if anything at all. :)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Te
On Thu, 20 Jul 2006 03:52:02 -0500, you wrote:
>>XMS free blocks fragmentation ... they should not exist (now is 21
>>century!). I hope he found the time to fix it.
>
>Fragmentation always exists, and if you were a programmer you would know
Fragmentation always exist for XMS manager, not user.
Hi!
20-Июл-2006 14:39 [EMAIL PROTECTED] (Johnson Lam) wrote to
freedos-devel@lists.sourceforge.net:
JL> XMS free blocks fragmentation ... they should not exist (now is 21
JL> century!).
Dynamic memory fragmentation was and will exist in any century. This is
unavoidable behavior. Issue is on
Hi!
20-Июл-2006 08:15 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
>> Be polite never late!
J> You're right. But to be safe I will maintain a tiny security distance between
J> me and everything FD-related in the future.
Do you think, that "distance" allows/
At 02:39 PM 7/20/2006 +0800, "someone" wrote:
>On Wed, 19 Jul 2006 06:32:11 +0200, you wrote:
>
> >> I never seen similar reports before, so Michael,
> >> probably, unaware about this behavior and thus have no chance to fix
> it. :)
> >Yes, let's assume this. :)
>
>XMS free blocks fragmentation ..
On Wed, 19 Jul 2006 06:32:11 +0200, you wrote:
>> I never seen similar reports before, so Michael,
>> probably, unaware about this behavior and thus have no chance to fix it. :)
>Yes, let's assume this. :)
XMS free blocks fragmentation ... they should not exist (now is 21
century!). I hope he fou
> Be polite never late!
You're right. But to be safe I will maintain a tiny security distance between
me and everything FD-related in the future.
> PS: Last 5 days news.openwatcom.org misbehaves for me. Is it my troubles or
> it broken itself?
I've experienced the same troubles. It seems
Arkady: I think that news.openwatcom.org is broken at the moment
--
Fall is my favorite season in Los Angeles, watching the birds change
color and fall from the trees.
David Letterman (1947 - )
See ya
-
Take Surveys. Ear
Hi!
19-Июл-2006 06:32 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
>> Total "all" or total "free"? If first, then this is bug.
J> RBIL is a bit unclear, but given that the FD-Himem competitors are correct it
J> is meant "total free".
If you mean Table 02758
> Total "all" or total "free"? If first, then this is bug.
RBIL is a bit unclear, but given that the FD-Himem competitors are correct it
is meant "total free".
> Be more polite! :)
It's too late. Mr. Devore already expressed his "bewilderment" concerning my
remark.
> I never seen si
At 11:48 PM 7/18/2006 +0200, Japheth wrote:
> > Thank you for a most reasoned and pleasant remark. It is a particularly
> > enlightened remark to make in view of recent mail-list history. In any
> > case, you have certainly modified my overall view of your attitude and
> > willingness to act as
Hi!
18-Июл-2006 22:50 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
J> 1. the xms state after booting FD without EMM386:
J> XMS3+ total extended memory (kB): 785088
J> 2. the xms state after allocation of 1024 kB:
J> XMS3+ largest free block (kB): 784064
J> XMS3+ total
Hi!
18-Июл-2006 10:51 [EMAIL PROTECTED] (Jim Hall) wrote to
freedos-devel@lists.sourceforge.net:
JH> I don't have my copy of Kernighan & Ritchie's "C Programming Language
JH> (ed. 2)" with me to show you, but here is an excerpt from ISO/IEC
JH> 9899:TC2 WG14/N1124 Committee Draft - May 6, 2005 (6
> Thank you for a most reasoned and pleasant remark. It is a particularly
> enlightened remark to make in view of recent mail-list history. In any
> case, you have certainly modified my overall view of your attitude and
> willingness to act as a responsible party in reporting errors and
> com
At 10:50 PM 7/18/2006 +0200, Japheth wrote:
>Here is another "CORRECT, but not terribly GOOD" behaviour of FD-Himem
>(newest
>version!):
>After these tests I understand now the reasons which brought QHIMEM into
>existance.
Thank you for a most reasoned and pleasant remark. It is a particula
At 09:24 PM 7/18/2006 +0200, Japheth wrote:
>As already mentioned, the block merges are not done on allocation, at least
>not in all cases, since my simple try to alloc a block which exceeded the
>reported "largest size" failed. Else I would probably have hesitated to call
>it a bug.
Tonight's c
Here is another "CORRECT, but not terribly GOOD" behaviour of FD-Himem (newest
version!):
1. the xms state after booting FD without EMM386:
XMS3+ largest free block (kB): 785088
XMS3+ highest address: 2FFF
> the largest (allocatable) block. In its defense, I believe that
> contiguous XMS blocks will be merged on allocation if there is insufficient
> memory contained in a single block, although I might be remembering that
> wrong. In other words, if my memory is correct, block merges are done on
>
At 06:20 PM 7/18/2006 +0200, Japheth wrote:
>There is a bug left in the FD-Himem.exe memory manager.
Nope. But see further...
>When a program that had allocated several XMS blocks doesn't release these
>blocks in the order FD-Himem likes it, it will report a too small "largest
>free block
There is a bug left in the FD-Himem.exe memory manager.
When a program that had allocated several XMS blocks doesn't release these
blocks in the order FD-Himem likes it, it will report a too small "largest
free block". Luckily the memory is not "permanently" lost, FD-Himem is able to
regenerat
>>> And there remains issue with "nested" comments.
>>>
> MD> No issue; no nesting. Ergo, I'm not changing it. In reply, rather than
> MD> quoting boring old pre-ISO C compiler options, please instead trace
> support
> MD> back to the far more enriching Magna Carta. King John of England
Hi!
17-Июл-2006 12:05 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>And there remains issue with "nested" comments.
MD> No issue; no nesting. Ergo, I'm not changing it. In reply, rather than
MD> quoting boring old pre-ISO C compiler options, please instead t
Hi!
17-Июл-2006 19:35 [EMAIL PROTECTED] (Japheth) wrote to
freedos-devel@lists.sourceforge.net:
J> There is a small "issue" which I have to "cure" on every new release:
J> Turbo C Version 2.01 Copyright (c) 1987, 1988 Borland International
J> emm386c.c:
J> Warning emm386c.c 801: 'temphandle' de
At 08:07 PM 7/17/2006 +0200, Japheth wrote:
>After fixing the first error...
Nomenclature correction:
>fixing
^^^
modifying source to remove
>error
^^^
warning
So that:
>After fixing the first error...
properly becomes:
After modifying the source to remove the first warning...
In o
After fixing the first error, I'm getting:
---
C:\FREEDOS\EMM386\SOURCE\EMM386>d:\alt\tc201\make
MAKE Version 2.0 Copyright (c) 1987, 1988 Borland International
Available memory 563902 bytes
d:\alt\tc201\tcc -G- -w -r -
> No issue; no nesting. Ergo, I'm not changing it. In reply, rather than
> quoting boring old pre-ISO C compiler options, please instead trace support
> back to the far more enriching Magna Carta. King John of England's
> viewpoint on how an unpaired '/*' inside of a comment block makes the
At 04:43 PM 7/17/2006 +0400, Arkady V.Belousov wrote:
>And there remains issue with "nested" comments.
No issue; no nesting. Ergo, I'm not changing it. In reply, rather than
quoting boring old pre-ISO C compiler options, please instead trace support
back to the far more enriching Magna Carta.
Салям!
15-Июл-2006 01:19 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
> MD> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
> MD> emmx211.zip, EMM386 version 2.11 memory manager, mostly executable files;
> MD> and emms211.zip, source co
At 12:06 PM 7/15/2006 -0500, Jim Hall wrote:
>I also mirrored this release on ibiblio, and updated the LSM on the web
>site. :-)
Can you update the freedos.org website to point to 2.11? I dunno if it
needs an UPDATE message below original text. Maybe "minor VDS patch", or
whatever.
Unrelated
I also mirrored this release on ibiblio, and updated the LSM on the web
site. :-)
Blair Campbell wrote:
> Just in time :-) (15 min left here)
>
> On 7/14/06, Michael Devore <[EMAIL PROTECTED]> wrote:
>
>> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
>> emmx211.zip
Just in time :-) (15 min left here)
On 7/14/06, Michael Devore <[EMAIL PROTECTED]> wrote:
> Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
> emmx211.zip, EMM386 version 2.11 memory manager, mostly executable files;
> and emms211.zip, source code files. 2.11 is a minor up
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx211.zip, EMM386 version 2.11 memory manager, mostly executable files;
and emms211.zip, source code files. 2.11 is a minor update from 2.10 --
minor, of course, unless you need it.
EMM386 2.11 fixes a problem with a few
At 11:02 AM 12/5/2005 -0600, I wrote:
Looks like NSM source might have been the better translation input choice,
but I'm not sure why the extensions are named that way, as they appear to
be reversed for their intended assembler.
My mistake, the NSM is definitely for NASM. I was looking at th
Hello Kenneth,
> But seriously, any suggestions to improve it (both in function or style)
> are welcome. In may latest versions (0.5.x) I've gone back to just
> MASM/TASM form (I can't stand NASM's positional based macro parameter
> names, FASM had no list support, and I couldn't get my segment
At 09:10 AM 12/5/2005 -0500, Kenneth J. Davis wrote:
EQUates globally that can be IFDEF'ed out of sight, and has a few other
quirks.
:-) how do you improperly use an EQU? (-:
It looks to be improper if the code, for example, declares an EQUate called
FLG_MASTER inside an IFDEF OPT_ATAPI
Kenneth J. Davis schreef:
But seriously, any suggestions to improve it (both in function or
style) are welcome. In may latest versions (0.5.x) I've gone back to
just MASM/TASM form (I
0.5.x? Must be quite some advancement then in a private development tree.
out of curiosity which version of at
Michael Devore wrote:
...
Okay, that was painful. The ATAPICD assembly code is already a we1ird
amalgam of NASM and MASM/TASM code. Plus it appears to improperly use
I agree it is painful
EQUates globally that can be IFDEF'ed out of sight, and has a few other
quirks.
:-) how do you impr
Michael Devore schreef:
I'll make Nomyso automate a couple more of the current manual ops,
although slight hand massage will likely remain necessary, and then
release a Nomyso 2.5, or 3.0, or 3.14159 or something.
Nomyso pie? (ehm..PI).
Bernd
--
Efficiency is intelligent lazyness
At 09:25 PM 11/29/2005 +0100, Bernd Blaauw wrote:
Michael Devore schreef:
Does ATAPICD work? I thought it was basically abandoned unfinished in
favor of other DOS CD-drivers generally available and working (which
admittedly aren't open-sourced).
AtapiCD basicly works, but without error check
I can't avoid saying Many many thanks, Michael, for your excellent work
in both Nomyso and EMM386!
Aitor
Michael Devore escribió:
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx208.zip, EMM386/HIMEM mostly executable package (EXEs compressed via
mutant UPX), and e
Michael Devore schreef:
Nah, think of it as a commitment filter. If a person can't be
bothered to make a small download to get Perl for the conversion, how
much effort do you think they'd put into coding and debugging the
source files? Besides, Perl is multi-platform and pretty darn useful
o
At 09:47 PM 11/29/2005 +0300, Arkady V.Belousov wrote:
Hi!
__O\_/_\_/O__
---> RETR /downloads/emm386/emmx208.zip
550 No such file.
Failure on 'RETR /downloads/emm386/emmx208.zip' command
failed to get /downloads/emm386/emmx208.zip
--->
At 06:01 AM 11/29/2005 +0100, Bernd Blaauw wrote:
our NOMYSO page already points to Perl website, so I guess it's pointless
to ask for converted sourcecode.
Nah, think of it as a commitment filter. If a person can't be bothered to
make a small download to get Perl for the conversion, how muc
Hi!
__O\_/_\_/O__
---> RETR /downloads/emm386/emmx208.zip
550 No such file.
Failure on 'RETR /downloads/emm386/emmx208.zip' command
failed to get /downloads/emm386/emmx208.zip
---> RETR /downloads/emm386/emms208.zip
550 No such file.
F
Hello Bernd,
> if HIMEM compiles now with NASM, does FDXMS/FDXXMS/FDXDM286 also (as
> HIMEM was based on it, looong time ago)?
HIMEM and FDXMS are descent from the same parent which also happens to
be called FDXMS, but HIMEM is definitively NOT based on the current
FDXMS. If anything, it's
Michael Devore schreef:
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the
files emmx208.zip, EMM386/HIMEM mostly executable package (EXEs
compressed via mutant UPX), and emms208.zip, EMM386/HIMEM mostly
source package. Nomyso version 2.0 was uploaded to
ftp://ftp.devoresoftwar
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx208.zip, EMM386/HIMEM mostly executable package (EXEs compressed via
mutant UPX), and emms208.zip, EMM386/HIMEM mostly source package. Nomyso
version 2.0 was uploaded to ftp://ftp.devoresoftware.com/downloads/nomyso
na
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx206.zip, EMM386/HIMEM mostly executable package, and emms206.zip,
EMM386/HIMEM mostly source package.
This release of EMM386 has modifications attempting to reduce conflicts
with SCSI and VDS, along with minor internal
If you have any problems with EMM386 2.05, try the unofficial release
emmflesh.zip at
ftp://ftp.devoresoftware.com/downloads/emm386 as it has a couple of
relatively minor fixes in the EMM386.EXE file that will affect some
users. Be aware that this unofficial version is not EXE compressed in siz
At 05:01 PM 9/19/2005 -0500, I wrote:
This version of EMM386 has a number of compatibility changes to enhance
operability with a variety of DOS applications and environments without
the need for advanced option tweaking. As a result of the seven changes
to EMM386 and two changes to HIMEM, thi
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx205.zip, EMM386/HIMEM mostly executable package, and emms205.zip,
EMM386/HIMEM mostly source package.
This version of EMM386 has a number of compatibility changes to enhance
operability with a variety of DOS applicatio
Hi!
Maybe another dpmi extender helps?
Why don't you contact the author?
Bye, Flo
> After I upgraded to EMM386 2.04, I got an "Ignoring (and losing) VCPI
> page!" message
> with GVFM.EXE from the DOSCDRB3 -- a graphic file manager.
GraphicVision apps have difficulty with FreeDOS's HIMEM due t
At 08:01 PM 8/14/2005 -0700, Blair Campbell wrote:
> After I upgraded to EMM386 2.04, I got an "Ignoring (and losing) VCPI
> page!" message
> with GVFM.EXE from the DOSCDRB3 -- a graphic file manager.
GraphicVision apps have difficulty with FreeDOS's HIMEM due to
something like resizing small a
At 02:56 AM 8/15/2005 +, bahcl wrote:
After I upgraded to EMM386 2.04, I got an "Ignoring (and losing) VCPI
page!" message with GVFM.EXE from the DOSCDRB3 -- a graphic file manager.
It only happen in my PCCHIPS 810 motherboard.
Sounds like a status message from their program. It isn't c
> After I upgraded to EMM386 2.04, I got an "Ignoring (and losing) VCPI
> page!" message
> with GVFM.EXE from the DOSCDRB3 -- a graphic file manager.
GraphicVision apps have difficulty with FreeDOS's HIMEM due to
something like resizing small amounts of XMS. I have been having the
same type of pr
Hi,
After I upgraded to EMM386 2.04, I got an "Ignoring (and losing) VCPI
page!" message
with GVFM.EXE from the DOSCDRB3 -- a graphic file manager.
It only happen in my PCCHIPS 810 motherboard.
regards,
bahcl
_
MSN 人氣搜尋，有齊城中熱門話
Blair Campbell schreef:
When using EMM386 there is a problem with help where help either
reboots or gives an error and locks-up the machine. It could be a
problem with the kernel, though, because the problem goes away when I
don't use DOS=HIGH. I am using the latest development kernel.
this i
When using EMM386 there is a problem with help where help either
reboots or gives an error and locks-up the machine. It could be a
problem with the kernel, though, because the problem goes away when I
don't use DOS=HIGH. I am using the latest development kernel.
--
Fall is my favorite season in
Hi. I just found a problem with the new EMM386 and with doslfn. I
tried to use devload to load usbaspi.sys while EMM386 was loaded,
however, this rebooted the computer. I tried the same thing with
UMBPCI, and it worked fine. I then tested loading from config.sys
with EMM386 and got the same pro
Hi!
7-Июл-2005 21:24 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> VCPI function DE01, Get Protected Mode Interface, saves the high word of
MD> EAX across the call, where it did not before. Nothing known needs this,
MD> but since the previous problem with W
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx204.zip, EMM386/HIMEM mostly executable package, and emms204.zip,
EMM386/HIMEM mostly source package.
EMM386 2.04 and HIMEM 3.11 are bugfix updates. HIMEM 3.11 is a recommended
update for all FreeDOS users. EMM386 2.
Michael Devore schreef:
Notice that I am at off-development status for the summer. This
notice directly applies to the clown attempting to revive moribund
driver projects so as to locate a developer more pliable to his
personal software vision. The notice does not apply to bugfixes and
Free
I just tested, it is working fine.
thanks,
Alain
Michael Devore escreveu:
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files
emmx203.zip, EMM386/HIMEM mostly executable package, and emms203.zip,
EMM386/HIMEM mostly source package.
EMM386 Version 2.03 is a minor update, r
1 - 100 of 326 matches
Mail list logo
