1. Win32Bug
- Posted by Michael Sabal <mjs at OSA.ATT.NE.JP>
Nov 16, 1998
-
Last edited Nov 17, 1998
Uh, I have some bad news. While working on ewinhelp (which is now part =
of the Store Manager program, but not yet released), I got the page =
fault error while trying to display dynamically created buttons. =
Between Rob's comments and this, it seems the problem may be this:
Since most structures in Windows are contiguous (because they are =
statically created), there usually isn't a problem with them. However, =
when you start using dynamic controls (in Win32Lib, only ListBox =
controls and my dynamic buttons have this property), you have the =
potential of writing data across pages. The page segment appears to be =
managed OK in the set... functions, but not in the get... functions (but =
I'm not positive about this). I look forward to finding a solution to =
this problem as much as anyone. If Rob or Dave or anyone else working =
on the problem wants to see my source code, let me know and I'll e-mail =
it to you. I'm not going to put it on my homepage, as it's still being =
worked on.
Michael J. Sabal
mjs at osa.att.ne.jp
http://home.att.ne.jp/gold/mjs/index.html
2. Re: Win32Bug
Michael Sabal wrote:
> Since most structures in Windows are contiguous (because
> they are statically created), there usually isn't a problem with
> them. However, when you start using dynamic controls (in Win32Lib,
> only ListBox controls and my dynamic buttons have this property), you
> have the potential of writing data across pages.
If controls need to be created on pages, it shouldn't be too hard to fix.
But I suspect that it's something more simple - a bug in the way I
allocate/deallocate memory structures, an error in the order of Windows
incantations (oops - I mean API calls), or (less likely) an error in
EXW.EXE.
-- David Cuny
3. Re: Win32Bug
I've finally solved the Win32 bug.
It all comes down to one small mistake in Win32Lib.ew
-- Type PAINTSTRUCT
psHdc = allot( Long ),
psErase = allot( Long ),
psPaintRect = allot( SIZEOF_RECT ), -- 16 bytes
psRestore = allot( Long ),
psIncUpdate = allot( Long ),
psRgbReserved = allot( Byte ), <----- !!!
SIZEOF_PAINTSTRUCT = allotted_size(),
SIZEOF_PAINTSTRUCT is set to 33 bytes. This
is wrong. According to Petzold Chapter 3, a PAINTSTRUCT
is defined as:
typedef struct tagPAINTSTRUCT
{
HDC hdc;
BOOL fErase;
RECT rcPaint; // 16 bytes
BOOL fRestore;
BOOL fIncUpdate;
BYTE rgbReserved[32];
} PAINTSTRUCT;
where I assume BOOL and HDC are 4 bytes.
The problem is that rgbReserved is 32 bytes, not 1.
I changed the last line to
SIZEOF_PAINTSTRUCT = allotted_size() + 32,
and now everything works. (I guess +31 would work too.)
I ran Win32Lib using safe.e in place of machine.e and
nothing illegal was detected, so I assume that Windows
is storing stuff into the rgbReserved area, not David.
This bug actually happens in almost all Win32Lib programs,
it's just that the storage block that comes after the paint structure
is rarely critical. When I ran the Win32Lib demo programs
using my debugging version of exw (loaded with extra sanity checks),
heap corruption was detected in almost all cases
i.e. an allocated block of memory had been scribbled on.
The programs reported by Ad Rienks work now.
The 12-character thing was just a coincidence.
I guess it made the heap corruption evident.
I ran through the full set of demo programs in Win32Lib again,
and they all work flawlessly now, even with safe.e and
the debugging version of exw.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
4. Re: Win32Bug
Robert wrote:
> I've finally solved the Win32 bug.
Hurrah!
Thanks to Robert (and everyone else) who helped track down this bug. I
certainly would not have been able to find it in a reasonable amount of time
(like, within my lifetime).
It's also heartening to see the error is in *my* code, and not Robert's or
Win32. 
-- David Cuny
5. Re: Win32Bug
Robert Craig wrote:
>I changed the last line to
> SIZEOF_PAINTSTRUCT =3D allotted_size() + 32,
I did that too, but the bug's still there! Are you sure this line is the
only that has to be changed?
Thanks,
Ad Rienks
6. Re: Win32Bug
- Posted by Rob Craig <rds at EMAIL.MSN.COM>
Nov 18, 1998
-
Last edited Nov 19, 1998
Ad Rienks writes:
> I did that too, but the bug's still there! Are you sure this
> line is the only that has to be changed?
Yes. To be sure, I just unzipped the latest Win32Lib 0.14b and changed
only this line. Your version of ex06.exw runs fine. No corruption detected,
and it runs fine with the debug or non-debug version of exw. If I put the
line back the way it was originally, corruption is detected by the debug
version of exw. Previously it was crashing almost every time using
exw. The only difference from you is I'm running Euphoria 2.1 alpha
(not released yet), but I don't think that would matter. (It's a bit
awkward for me to run v2.0 at the moment).
Please check that you have edited the Win32Lib.ew file that
will actually be picked up by "include win32lib.ew". Perhaps you have
corrected your copy in EUPHORIA\INCLUDE, but you also have a copy
in the current directory along with wasex06.exw. The one in the
current directory will be used.
Regards,
Rob Craig (posting from Web due to MSN mail problems)
Rapid Deployment Software
http://members.aol.com/FilesEu/
