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
Hi!
18-Авг-2006 14:27 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>>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 ma
Hi!
18-Авг-2006 13:36 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:
EA> Basically the updated patch means "free MCBs become unlinked
EA> when their memory is merged with the memory of adjacent free
EA> MCBs, but thear are no longer invalidated". Quite clean...
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
Hi!
18-Авг-2006 11:26 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:
EA> I hope you also like my kernel patch for it...
EA> [... QuickBASIC frees a block, resizes another block to the max after
EA> finding the max size with resize to -1 size, then frees the first
EA>
Hi!
17-Авг-2006 21:20 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
MD> 1. QuickBASIC (I assume) frees a block of memory via INT 21h function 49h
MD> 2. QuickBASIC resizes a second block of memory via function 4ah with value
MD> 3. QuickBASIC resizes the second
Eric Auer escreveu:
>
> How about marking free blocks as unresizable at the moment
> when joinMCBs splices them out of the chain, leaving an
> unlinked but "double-freeable" data structure in RAM?
For what I could understand, only one such "double freeable" block is
needed. And it could be cle
Hi!
>> --- kernel/memmgr.old 2006-08-18 10:22:33.0 +0200
>> +++ kernel/memmgr.c 2006-08-18 10:22:33.0 +0200
>> @@ -66,7 +66,12 @@
>> /* join both MCBs */
>> p->m_type = q->m_type; /* possibly the next MCB is the last one
>> */
>> p->m_size += q->m_size
> I would suggest the following patch for kernel 2036 (stable) -->
> --- kernel/memmgr.old 2006-08-18 10:22:33.0 +0200
> +++ kernel/memmgr.c 2006-08-18 10:22:33.0 +0200
> @@ -66,7 +66,12 @@
> /* join both MCBs */
> p->m_type = q->m_type; /* possibly the next
Hi Michael!
Very nice analysis :-).
I hope you also like my kernel patch for it...
> 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
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
11 matches
Mail list logo
