How to prevent funny exceptions?

[HSE]

Hi Hutch!

There is no problem if function run in a thread.

Removing application messages prevent to run other function using same data, no problem neither.

Some messages from system apparently are also intercepted, then some window drawings only can be updated after thread finish (here I have a random popup that say one disk is full  that sometimes is drawed over the application).  If that become a problem I think is posible to filter what messages are removed, but perhaps don't worth the effort right now.

[LiaoMi]

Example from the old forum 

What's the purpose of offset flat:ButtonTxt_Stopped? The code generated is identical with or without the flat:

Hi jj2007,

Microsoft Corporation - Microsoft Macro Assembler 6.11 Reference Manual_Macro Assembler Reference-Microsoft Corporation (1992)

@data
The name of the default data group. Evaluates to DGROUP for all models
except FLAT. Evaluates to FLAT under the FLAT memory model (text
macro).

FLAT as a group override ("mov eax, offset FLAT:<symbol>") <-"OFFSET FLAT:" to reference memory locations in the .data section.

Code Select Expand

OFFSET FLAT is used when the memory model is flat. OFFSET would have translated to a segment selector (DS) and OFFSET, whereas OFFSET FLAT translates to an absolute address of the label xxx relative to 0 (seeing as that's the base of the DS segment in flat mode), which the linker resolves after it is assembled.

[jj2007]

Thanks, LiaoMi. That's what I imagined, but it doesn't make much sense in that code, because offset ButtonTxt works fine without the "flat". Where are segment selectors in a flat model anyway? Looks like a relic from the 16-bit world

Sometimes I declare read-only strings in the code section, and it makes no difference if the string is there or in .data - offset works:

Code Select Expand

.code
title db "Hello", 0
Sayhi proc arg
  invoke MessageBox, 0, arg, offset title, MB_OK
  ret
Sayhi endp

[LiaoMi]

@jj2007

Looks like a relic from the 16-bit world

I think so