Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx226.zip, EMM386 2.26 and HIMEM version 3.26 memory manager, mostly
executable files; and emms226.zip, source code files. The FTP-challenged
may find the files at http://www.devoresoftware.com/emm386 .
EMM386 2.26 is r
At 11:27 PM 8/24/2006 +0400, Arkady V.Belousov wrote:
> >>Both executables now run and produce a help screen when run as EXE;
> >>they used to crash right away, so this is already an improvement.
>MD> That's good enough for me. I'll stick a "Requires 80386" message in the
>MD> help screen feedback
At 08:31 PM 8/24/2006 +0200, Joris wrote:
> > Welp, anyone who has an 8088 or 8086, or 80186 or 80188, or 80286, can try
> > test EXE's at ftp://ftp.devoresoftware.com/download/emm386 called
> > HIMKIK86.EXE and EMMKIK86.EXE for --8086 compressed HIMEM and EMM386,
> > respectively, and report their
At 03:23 AM 8/24/2006 +0400, Arkady V.Belousov wrote:
>Hi! 24-á×Ç-2006 01:01 [EMAIL PROTECTED] (Japheth) wrote to
>[email protected]: >> Welp, anyone who has an 8088 or
>8086, or 80186 or 80188, EMM386, >> respectively, and report their
>results. It should kick out a message f
At 05:25 PM 8/23/2006 -0500, I wrote:
> >MD> not make a difference. Does anybody here have an 8086 and can act as a
> >MD> test subject in a reasonable turn-around time frame?
> >
> > You yourself?
>
>Nope, I haven't had an 8086 in over a decade. Maybe two.
Come to think of it, it wasn't a
At 06:22 PM 8/23/2006 -0400, Lyrical Nanoha wrote:
>On Wed, 23 Aug 2006, Michael Devore wrote:
>
> > Not good enough? Probably not. I'll compress EMM386 with the option next
> > time, but unless a person with an 8086 is available for pre-testing, it may
> > not mak
At 02:21 AM 8/24/2006 +0400, Arkady V.Belousov wrote:
>MD> but unless a person with an 8086 is available for pre-testing, it may
>
> Isn't your emulators allow to emulate 8086?
Isn't anything in VPC or Qemu, unless it's a hidden advanced option like
UPX does. Somebody could develop a singl
At 01:48 AM 8/24/2006 +0400, Arkady V.Belousov wrote:
>Hi! 23-á×Ç-2006 16:16 [EMAIL PROTECTED] (Michael Devore)
>wrote to [email protected]: >>HIMEM.EXE (HIMEM64 3.12)
>crashes on "shl cx,4" even when invoked >>as "himem /?". MD&g
At 11:02 PM 8/23/2006 +0200, Joris van Rantwijk wrote:
> > And how about emm386 and himem?
>
>HIMEM.EXE (HIMEM64 3.12) crashes on "shl cx,4" even when invoked
>as "himem /?".
>Same problem with HIMEM64 3.23.
>Same problem with EMM386.EXE 2.08.
>Same problem with EMM386.EXE 2.23.
That's from UPX.
At 09:49 PM 8/21/2006 +0200, tom ehlert wrote:
>b) I was referring to MKEYB anyway ;)
> > There would remain the problem of loading EMM AFTER KEYB,
>c) EMM386 can have the int15 first always - EMM386 is *the* BOSS
>in a virtual environment (it call the real mode int's itself)
>d) this would be
At 09:41 PM 8/21/2006 +0200, Aitor Santamaría wrote:
> > int 15/4f is only supported on AT+ style maschines, but this should be
> > true for anything with 386+ CPU's
>
>For the rare cases in which this should not happen,
>KEYB xx /9
>does install such handler for int15h (as the rest of KEYB is also
At 09:40 PM 8/21/2006 +0200, Bernd Blaauw wrote:
>EMM386 already has the ability to detect Vmware (some magic backport),
>so EMM386 can set the proper option (be it ALTBOOT or NOALTBOOT) default
>for VMware. The detection ability has been used to exclude some UMB
>range previously (and might still
At 02:00 PM 8/21/2006 -0500, I wrote:
>Okay, here's where we have a fundamental conflict. It's also causing
>problems with FDAPM and WARMBOOT options, perhaps other FDAPM options. It
>is the difference between ALTBOOT and NOALTBOOT options in EMM386.
Incidentally, if anyone happens to know why t
At 09:37 AM 8/21/2006 +0200, Norbert Remmel wrote:
>During testing I discovered a bug concerning STR-ALT-DEL usage.
>When pressing these keys, freedos crashes with invalid opcode outputting
>some memory addresses and registers.
>As I remember this wasn't like this using earlier versions of
>himem/
At 08:20 PM 8/20/2006 +0400, Arkady V.Belousov wrote:
> MD> On the good news front, I am semi-reliably informed via
> semi-reliable MD> gossip that a new or greatly revised EMM386 model is
> being worked on. As May you share with us these gossip? Who, when,
> which model?
Now, now, it's
At 03:13 PM 8/20/2006 -0500, I wrote:
>At 09:59 PM 8/20/2006 +0200, Aitor Santamaría wrote:
> >That works, many thanks!
> >Would EMM386 be in webspace too? (the obvious /emm386 didn't work)
>
>I'll stick in there somewhere after we make Arkady happy. Well, happier.
Okay, besides the ftp site, the
At 09:59 PM 8/20/2006 +0200, Aitor Santamaría wrote:
>That works, many thanks!
>Would EMM386 be in webspace too? (the obvious /emm386 didn't work)
I'll stick in there somewhere after we make Arkady happy. Well, happier.
-
U
At 12:03 AM 8/21/2006 +0400, Arkady V.Belousov wrote:
>MD> I needed to release 2.25 and you weren't available during that particular
>MD> time period,
>
> I _was_ available. But I not see any letters from you in my postbox -
>so how you decide, that I was not available?
No, I based it on when
At 09:03 PM 8/20/2006 +0200, Aitor Santamaría wrote:
>Sorry, again my problems to acceed Michael's FTP (I wonder why, I've been
>using FileZilla, any user/pwwd so that I can try?). Could someone send it
>in private to this mail?
You could try the HTTP protocol since the file is also placed in we
At 08:20 PM 8/20/2006 +0400, Arkady V.Belousov wrote:
>:( 1. Name scheme not changed
You can name it whatever you want. I can give you a regex that would work
with current names, if you want to get fancy.
>BTW, Michael, what was prevent you to integrate patch directly? It doesn't
>changes gene
At 09:56 PM 8/20/2006 +0400, Arkady V.Belousov wrote:
>AS> from you), but I wouldn't say that the port to NASM is
>negligible. Trick is, that sources are _not_ ported to NASM
>(explicitly). :)
Took my machine about 1 minute to convert it, last I checked. FreeBSD
apparently likes Nomyso be
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx225.zip, EMM386 2.25 and HIMEM version 3.25 memory manager, mostly
executable files; and emms225.zip, source code files.
This release of EMM386 and HIMEM works around a bug in some BIOS chips
which affects HIMEM, impro
At 09:00 PM 8/18/2006 -0400, Gregory Pietsch wrote:
>Alain M. wrote:
> >
> > May I offer a suggestion: we can have
> > FreeDOS 1.0 alfa
> > FreeDOS 1.0 beta 1
> > FreeDOS 1.0 beta 2
> >
> > That would keep the schedule *and* allow time to test...
> >
> >
>Boy, it seems like 1.0 is a perfection that
At 01:43 AM 8/19/2006 +0400, Arkady V.Belousov wrote:
>e> are disabled by INT 15, and restored by iret) You miss, that only
>recent releases of EMM386 do now respect original flags value on the stack
>- previous releases just directly manipulate IF flag and do "retf 2". te>
>So I assume th
At 11:39 PM 8/18/2006 +0400, Arkady V.Belousov wrote:
>MD> a popular compiler might be trouble.
> Let me again disagree with word "popular".
QB 4.5 must have sold into the hundreds of thousands. I owned a copy
myself and there was a huge community around it. It was _very_ popular,
more s
At 11:00 PM 8/18/2006 +0400, Arkady V.Belousov wrote:
>MD> make it work, but this is a compatibility issue that ought to be
>addressed
>MD> in some fashion. Even if it's a "QB4 is too stupid to live" announcement.
> 1. I think, this change may be delayed (for post-1.0).
Normally, I would be in
At 02:01 PM 8/18/2006 -0500, Jim Hall wrote:
> > Basically, what I'm asking for, and I can't believe I'm doing it, is for a
> > bit more time to pass, keeping the release based on feedback levels and
> > with an eye on a firm release date in a timely fashion. Your original
> > announcement of a
At 01:08 PM 8/18/2006 -0500, you wrote:
>I feel it's important to get "1.0" out there to draw a line in the sand,
>that we're at least "1.0" quality. We can do what MS-DOS could do. Maybe
>we have a few bugs, but (and maybe this is a sad fact) what "1.0"
>software doesn't have bugs? People expect i
At 10:54 AM 8/18/2006 -0700, Blair Campbell wrote:
>So to end this thread, since Michael already seems to own MS-DOS but
>just wants an easier way of getting it on his hard drive, it is
>perfectly legal to use.
Well, who doesn't have legal MS-DOS, if they ever had a machine back
when. It was inc
At 01:06 PM 8/18/2006 +0200, Andre Tertlingwrote:
>P.S. I am sure I have a stack of MS-DOS licenses somewhere in the
>basement. If someone really wants to have one, feel free to apply.
Heck, I still have at least two sets of MS-DOS floppies down in basement
somewhere. Don't know if they work, b
While testing out a users bug report, I found a terribly obscure difference
between the way MS-DOS kernel works and FreeDOS kernel works. It shouldn't
matter, but it does to QuickBASIC 4.x applications, at least for some using
BRUN40. I don't know the scope of how many QB applications are aff
At 04:54 PM 8/17/2006 -0400, Mark Bailey wrote:
>Try www.bootdisk.com. boot622.exe will extract a usable MSDOS boot
>floppy.
Cool deal. What you sent boots up under Qemu no problemo. Thanks.
-
Using Tomcat but need to do
[sent again with the right SourceForge-approved e-mail address this time]
Anybody have a MS-DOS 5.x or 6.x image around I could use? I need to do
some side-by-side testing in Qemu of MS-DOS against FreeDOS. I had an
image, but it seems to have gone missing. Thanks.
-
At 09:52 PM 8/17/2006 +0200, tom ehlert wrote:
> > I was a bit worried about the return address getting munged myself,
> > but the fact of AX modification is a good reason for why the BIOS bug
> > didn't keep biting, and the first patched worked.
>
>the 'first patch' actually was the original - fro
At 12:49 PM 8/17/2006 -0500, I wrote:
> > And? Why return address isn't damaged? Let me ask again:
> >
> >stack:
> >| ret address |
> >+-+
> >| pushf | <- tom thinks, this value damaged
> >+-+
> >| INT15 call |
> >
> >stack after tom's patch:
> >
> >stack:
> >| r
At 02:18 PM 8/17/2006 +0400, you wrote:
> >>looks like sometimes someone damages something on the stack, which
> >>goes unnoticed most of the time
>
> Unless found precise reason, there are no assurance, that your patch
>fixes (not masks) anything and not damages anything else.
It wouldn't da
At 09:20 AM 8/17/2006 +0200, tom ehlert wrote:
> >> May you explain here and/or, better, in comments in source, why
> >> decreasing SP solves issues (and which issues there are)? >>Only
> >> plausible explanation: >>THIS BIOS damages (sometimes ?) the
> >> flags; Do you mean "flags, _sav
At 06:19 AM 8/17/2006 +0400, Arkady V.Belousov wrote:
> May you explain here and/or, better, in comments in source, why
> decreasing SP solves issues (and which issues there are)? >>Only
> plausible explanation: >>THIS BIOS damages (sometimes ?) the
> flags; Do you mean "flags, _save
At 03:21 PM 8/16/2006 +0200, tom ehlert wrote:
>'solved' the original bug (sort of) by changing
>
>disable_enable_a20_BIOS:
> ;pushf
> ;cli
>
> shr ah,1; ah to 0 or 1
> mov al,24h
> xchgah,al ; ax == 2400h to turn off, 2401h to turn on
>
I've uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ the file
himem324.zip, containing a revised HIMEM executable and source file changed
from version 3.23.
This is an alternative version of HIMEM I'm making available for
testing. It is only slightly modified from the previous versi
>
>My report was made because of your kind invitation:
>
> > Please post any questions, comments, bug reports, or feedback to the list
>
>made at the beginning of this thread.
Yup, all useful feedback on HIMEM and EMM386 is invited. Or potentially
useful feedback; sometimes it's hard to say un
At 02:19 PM 8/15/2006 +0400, you wrote:
>But yes, this also not very common situation. But, I suggest, we may
>prepare next release at any time, even before releasing FD1.0 - existing
>new release not necessarily mean, that distributive maker _must_ include
>this newer release (whereas delaying
At 08:45 AM 8/15/2006 +0200, Japheth wrote:
>but of course you will argue now that this is also very uncommon, because why
>installing EMM386 if no UMBs are wanted? ;)
Nah, I'm still waiting for a good explanation of how using UMBPCI and
EMM386 is a common, or a not very uncommon, or even a desir
At 08:32 AM 8/13/2006 +0200, Japheth wrote:
> > Don't see exactly where this would happen in a supported configuration,
> > since EMM386 requires HIMEM/XMS manager presence and handles UMB's
> > internally. Nonstandard, unsupported configurations, well, can always
> plan
> > for that later.
>
>D
At 01:49 AM 8/13/2006 +0200, Japheth wrote:
>Not a severe problem (IMO it's more like a feature), but the A20 line
>switching will only work if an UMB handler has been installed. There are some
>constellation where this is not true, and then the A20 gate is unhandled by
>Emm386.
Don't see exactly
At 01:18 AM 8/11/2006 +0400, Arkady V.Belousov wrote:
>MD> I suppose it could be an artifact of GDB breaking into the program, but
>MD> since Stargunner is an infinite loop at that point, and this would
>qualify,
>MD> I'm thinking it's real.
>
> This may mean only that port emulator code is
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx223.zip, EMM386 and HIMEM version 2.23 memory manager, mostly
executable files; and emms223.zip, source code files.
This release of EMM386 and HIMEM should improve compatibility with some
DOS-extender applications, suc
At 09:57 PM 8/9/2006 -0700, Blair Campbell wrote:
>If I qualify, I updated the htmlhelp documentation for HIMEM and
>EMM386, which will find its way into 1.0 :-).
Well, as to that updated documentation prize...much to my mortification, I
am informed by an interested party in completely unambiguou
At 10:55 PM 8/10/2006 +0400, Arkady V.Belousov wrote:
>Hi! 10-á×Ç-2006 13:28 [EMAIL PROTECTED] (Michael Devore)
>wrote to [email protected]: MD> GDB remoted to Qemu
>shows Stargunner in an infinite loop reading from port MD> 3DAh, Just
>interesting, wha
At 06:35 PM 8/8/2006 -0500, I wrote:
>And sadly, it appears that while DOOM works in VPC and Qemu, Stargunner
>remains problematic in virtual environments, though works here in real
>DOS.
GDB remoted to Qemu shows Stargunner in an infinite loop reading from port
3DAh, so looks like it's a video
At 06:20 AM 8/10/2006 +0400, Arkady V.Belousov wrote:
>MD> Nothing like a little challenge. And
>MD> competition. So here it is:
>MD> Write the most compatible A20 handler and submit it for inclusion in the
>MD> EMM386 release. Three simple rules: 1) has to work with EXEPACK, 2) you
>MD> test
At 11:02 PM 8/9/2006 +0400, you wrote:
> >>The current implementation seems very simple, for example, the XMS
> functions
> >>to enable disable A20 usually increase/decrease a counter
>MD> It is simple, deliberately so since its whole purpose in life is to avoid
>MD> EXEPACK and PKLITE issues.
>
At 08:39 PM 8/9/2006 +0200, Eric Auer wrote:
>... and yes, the "local" enable/disable can be quite dummy:
>Apps call local-off when they no longer need that a20 on, but
>they that does not mean that it has to be actually off after
>the call :-). Of course, calling local-on has to have the
>"effect
At 07:35 PM 8/9/2006 +0200, you wrote:
> > I didn't know if you were still working on it or whether it was just an
> > example patch. If an example, it wasn't worth your time (or mine,
> frankly)
> > to go into further detail. If you're interested, the removal of the
> 16-bit
> > stack check an
At 11:54 AM 8/9/2006 +0200, Japheth wrote:
>I meant the first, but also think this option should be implemented pre-1.0.
>The current implementation seems very simple, for example, the XMS functions
>to enable disable A20 usually increase/decrease a counter
It is simple, deliberately so since its
At 11:54 AM 8/9/2006 +0200, Japheth wrote:
>This may be true, but I dont know what you mean with "it appears", possibly
>you should be more specific.
I didn't know if you were still working on it or whether it was just an
example patch. If an example, it wasn't worth your time (or mine, frankly
At 09:36 AM 8/9/2006 +0200, Robert Riebisch wrote:
>Michael Devore wrote:
>
> > DOS. Given that the best protected mode debugger, 386SWAT, is fatally
> > incompatible with my FreeDOS development machine, I'm afraid that leaves me
>
>Did you report these problems to Bo
At 03:50 PM 8/8/2006 +0200, Japheth wrote:
>And I disabled this feature temporarily not because of speed reasons, but
>because there are situations thinkable where this "feature" may cause a crash.
>
>Such situations may be rare and almost impossible if DOS is loaded in the
>HMA,
>but they exist.
At 03:25 PM 8/8/2006 +0400, Arkady V.Belousov wrote:
> MD> No, doesn't look right. A20 handling was turned off,
> Japhet not tun off A20 handling, he just comment out call to INT67/3F.
Which turns off A20 handling enable/disable, unless it's resupported
elsewhere. It's straight-forward l
At 05:11 AM 8/8/2006 -0500, I wrote:
> > What about fix for issue with DOOM, which you found under VPC?
>
>MD> 2) (hopefully) the protected mode
>MD> stack fix or whatever's going on with certain DOS-extended stuff under VPC
>^^^
>T
At 01:32 PM 8/8/2006 +0400, you wrote:
>If you wish, I extract for you from Japhet' work fix for "sti/ret 2" bug
>(in new15 proc)
I already revectored that to the new IRET handling routine when you
mentioned it earlier on list. CMC is slightly neater code, but not enough
to go back in and goo
At 03:49 AM 8/8/2006 +0400, Arkady V.Belousov wrote, and I reconstituted:
>MD> Here's my final offer: I'll split off a new subdirectory on the source
>MD> tree, call it TCBUILD or somesuch (but avoiding the temptation to call it
>MD> ARKADY), and you can put all your shiny new C source changes in
At 11:07 PM 8/5/2006 +0400, Arkady V.Belousov wrote:
>MD> I still can't read your list mails very well,
>
> In this letter, there shouldn't be 8-bit characters, so recoding
>through base64 shouldn't happen. Is it readable to you?
Yes.
>MD> to "EMM386 may never get build subsystem".
>
>
At 12:12 PM 8/7/2006 +0200, Eric Auer wrote:
> But I'm not sure why you're using 2.11, anyway. It's at least a couple of
> > iterations back...
>
>Argh. I said 2.11 while I meant 2.21 of course... You also have
>to replace 2.10 by 2.20 in my previous mail to get things right.
Well, since 386SWAT
At 03:40 AM 8/7/2006 +0200, : Eric Auer wrote:
>There are new EMM386 2.11 troubles: Jazz Jackrabbit
>crashes (returns to DOS) with either a page fault or
>a GPF as soon as you use the NOEMS option of EMM386
>now. Lemmings 3d needs a page frame anyway, so it
>"cannot find EMS" if you use the NOEMS
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
At 12:08 AM 8/1/2006 -0700, Blair Campbell wrote:
>Due to the serious nature of the recent bug reports for the latest
>testing release, I would like to release one more testing release (at
>least) that would hopefully fix the users' problems. (Probably coming
>out tomorrow).
Tangentially related
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files
emmx221.zip, EMM386 version 2.21 memory manager, mostly executable files;
and emms221.zip, source code files.
This release of EMM386 has a few fixes and changes, mostly directed to Qemu
and FDAPM users, although those modi
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
At 11:19 AM 7/30/2006 -0500, Jim Hall wrote:
>Michael Devore wrote:
> > [...]
> > Heh, "she". Has anyone seen a female within a mile/kilometer/furlong of
> > FreeDOS development? Too bad about the lack of them, though. We could
> use
> > a few.
>My w
At 11:13 PM 7/28/2006 -0500, I wrote:
>You or anyone else can rewrite and submit whatever code you want with my
>blessing. The rules are simple:
Considering the circumstances, I have a couple of notes to add to the five
rules for code submission -- not new rules, just notes to help avoid
mis
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
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
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
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
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
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 09:22 AM 7/26/2006 +0200, Japheth wrote:
> > environment. Even better would be a good explanation for why the problem
> > only manifests itself with that specific environment and application.
>
>I've looked into the Qemu BIOS code for int 15h, ah=C2. Usually the code
>found
>in "real" BIOSes i
At 02:22 PM 7/26/2006 -0500, I wrote:
>I can't duplicate the XMS memory block fragmentation with DOOM or anything
>else handy, so whatever's happening depends upon the gameplay or memory
>configuration or moon phase or any of the usual suspects.
Okay, I can get minor XMS free block fragmentation
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
At 02:24 PM 7/26/2006 +0200, tom ehlert wrote:
>INT xx enters the interrupt handler with IF cleared, so this should be
>done also when being rerouted through the v86_monitor; looks like a
>plain bug to me
> > Changing a long-standing fundamental behavior to fix a single problem in a
> > virtual
At 09:02 PM 7/26/2006 +0200, tom ehlert wrote:
> > Well, heck, if I already to have to change some A20 behavior to get a few
> > ancient programs to work with that idiotic EXEPACK 0h address-wrapping
> > (assuming EXEPACK makes A20 calls),
>*VERY* early PKLITE (~1992) versions had the same bug
At 06:20 PM 7/18/2006 +0200, Japheth wrote:
>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 "p
At 07:01 AM 7/26/2006 +, Imre wrote:
>Isn't it more logical to change ctmouse then?
Depends on what is actually at fault, i.e. violating spec'ed behavior. I
don't have a good answer for that, yet.
-
Take Surveys. Earn
At 09:48 PM 7/25/2006 +0200, Japeth wrote:
> >
> > QEMU has never liked CTMOUSE under FreeDOS, and possibly MS-DOS. I don't
> > know why.
>
>when I modify emm386.asm, proc v86_monitor, so that the IF in real-mode is
>cleared for all interrupts routed to v86-mode, not just the IRQs, it works
>with
At 02:09 PM 7/25/2006 +0200, Japheth wrote:
>Some minor issues so far are:
>
>- if I select one of the configs with EMM386 the machine seems to hang after
>ctmouse is loaded (last command in autoexec.bat). If I remove that last
>line, everything is fine. This problem may be specific to qem
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
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 ..
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
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
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
At 12:41 PM 7/17/2006 -0700, Blair Campbell wrote:
>The only two timeouts are the first timeout which defaults to boot
>from the hard drive rather than the CD-ROM (nothing wrong with that
>IMHO), and the second just boots defaultly into installation mode,
>which is what most people will be after.
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
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.
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
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 08:05 PM 7/9/2006 +0400, Arkady V.Belousov wrote:
>Hi!
>
>1. emm386.lsm file isn't updated (old version).
It was updated in the distributed zip file. That's all I can do for it.
>2. source code bug: emm386c.c, line 679 introduced nested /*, which in
Nope. Closer examination will reveal no n
At 01:16 PM 7/9/2006 +0200, Aitor Santamaría wrote:
>Thanks for the update! I am unable to get the file via FTP (unable to
>connect), could you please give alternative ways, or upload it to
>ibiblio?
Nope. I'm offline in approximately 2.17 minutes for a couple of
days. Works okay via IE or dir
1 - 100 of 522 matches
Mail list logo
