News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Mysterious behaviour of Win98

Started by raymond, May 19, 2007, 03:56:34 AM

Previous topic - Next topic

raymond

A program I have been working on lately has a RichEdit control. There are 5 small files (32, 52, 90, 106 and 134 bytes respectively) which I try to load into that control by selecting one from a ComboListBox. After the desired file is chosen, the program opens the file, gets the file size, allocates memory for that size, reads the file, transfers it to the control, and then frees the allocated memory.

Everything works fine if the 52-byte file is not selected and I can keep on selecting the other four files ad infinitum in any order without any problem. However, whenever I select the 52-byte file after selecting any of the others, the program crashes within the kernel32.dll. When the 52-byte file is the first one selected, it loads without any crash; however, the crash occurs when another one is selected. :dazzled:

Such behaviour did not occur under WinXP.

Eventually, I solved that aggravation by allocating 256 bytes more than the file size :U. I did not however tried to determine what would have been the minimum amount of extra memory required to satisfy the kernel.

When you assume something, you risk being wrong half the time
http://www.ray.masmcode.com

hutch--

Ray,

How are you loading the text into the rich edit control ?
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

MichaelW

And is it a Rich Edit 1.0 or 2.0.
eschew obfuscation

raymond

QuoteHow are you loading the text into the rich edit control ?

After reading the file in the allocated memory hMem
invoke SendMessage,hEdit,WM_SETTEXT,0,hMem

QuoteAnd is it a Rich Edit 1.0 or 2.0.

This how I create it:
.data
  CtlStyle    db    "RichEdit",0
  szRich      db    "RICHED32.DLL",0
.code
WinMain proc
  invoke LoadLibrary,ADDR szRich
WndProc proc
  .elseif uMsg == WM_CREATE
    mov   edx,WS_VISIBLE or WS_CHILDWINDOW or \
    WS_VSCROLL or ES_NOHIDESEL or \
    ES_AUTOVSCROLL or ES_MULTILINE
    invoke CreateWindowEx,WS_EX_CLIENTEDGE,ADDR CtlStyle,NULL,
        edx,0,0,778,558,hWin,799,hInstance,NULL
    mov   hEdit, eax


Raymond
When you assume something, you risk being wrong half the time
http://www.ray.masmcode.com

hutch--

Ray,

Just a quick suggestion, try using the API SetWindowText() to load the data into the rich edit control. The one you are using is a rich edit 1.0 control and it should be trouble free in win98se.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

P1

Quote from: raymond on May 19, 2007, 03:56:34 AMEventually, I solved that aggravation by allocating 256 bytes more than the file size :U. I did not however tried to determine what would have been the minimum amount of extra memory required to satisfy the kernel.
Is the file size understated?  But the formating runs past file end?

Regards,  P1   :8)

raymond

Here's the message I was getting:

LIVRE caused an invalid page fault in
module KERNEL32.DLL at 018f:bff7a125.
Registers:
EAX=004116bc CS=018f EIP=bff7a125 EFLGS=00010212
EBX=0050ff54 SS=0197 ESP=0063fbec EBP=0063fc2c
ECX=0041000c DS=0197 ESI=004116bc FS=3a4f
EDX=00100000 ES=0197 EDI=000fe898 GS=3a3e
Bytes at CS:EIP:
8b 03 a8 01 74 25 25 fc ff ff 0f 8b 53 08 03 f8
Stack dump:
0063fc2c 000fe898 00411654 00000068
bff7a3a0 00410000 004116bc 000fe898
00000000 0041000c 00410000 00411654
00000040 00000000 0000050f 00000412


After further investigation, the error occurs while the LocalAlloc is being processed in the following code:

      invoke CreateFile,ADDR txtbuf,GENERIC_READ or GENERIC_WRITE,0,0,OPEN_ALWAYS,0,0
      mov   hFile,eax
      .if   eax == INVALID_HANDLE_VALUE
            ret
      .endif
      invoke GetFileSize,hFile,0
      mov   filesize,eax
;      add   eax,1
      invoke LocalAlloc,0,eax


Changing to GlobalAlloc made NO difference. Using LPTR instead of 0 also made NO difference. The problem could be repeated time after time whenever the opening of one of the two smaller files was followed by opening a larger file. It never would occur while cycling only through the three larger files at random.

Uncommenting the add eax,1 (or anything larger) is sufficient to avoid the error!!!! :dazzled:
MYSTERIOUS

Raymond

When you assume something, you risk being wrong half the time
http://www.ray.masmcode.com

Tedd

Try using "EM_STREAMIN" rather than WM_SETTEXT - it also handles all of the buffering, so you don't need to allocate.
No snowflake in an avalanche feels responsible.