News:
MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite
Recent posts
#81
The Campus / Re: bmp viewer wish your optim...
Last post by dedndave - May 21, 2012, 05:45:06 PMby general clean-up, i mean better organize the flow of the source
for example, the INC files and the preamble are a bit out of whack :P
then, in bmp.inc...
then, in variables.inc...
:bg
it's like a jig-saw puzzle with a couple pieces missing
look at some of the example programs to see how they are organized
as for erasing the background, i will tell you a little trick i use :U
make a child window with no caption or borders for the image to be displayed in
you really only need 3 style flags: WS_CHILD or WS_VISIBLE or WS_CLIPSIBLINGS
when you load an image, size the child window to the same size as the image
when you register the class for the child, use NULL as the brush handle
the background will never be seen
if you have no image, hide the child window
in the child window WndProc, the only messages you have to handle is WM_PAINT and WM_CLOSE
in the WndProc for the main window, you do not have to handle WM_PAINT
so - it's basically moving some code around a little and registering a class :P
you can also get rid of the code in WM_PAINT that takes the lesser of the image size and the rcPaint size
for example, the INC files and the preamble are a bit out of whack :P
Code Select
.386
.model flat,stdcall
option casemap:none
Viewer proto :DWORD,:DWORD,:DWORD,:DWORD
;
;
SaveBmp proto
include bmp.inc
.code
start:then, in bmp.inc...
Code Select
include variables.inc
pixel_offset struct
;
;
.codethen, in variables.inc...
Code Select
.data
ClassName db "BmpView",0
;
;
;
lPixel dw 3
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\comdlg32.inc
include \masm32\include\gdi32.inc
include \masm32\include\comctl32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\comdlg32.lib
includelib \masm32\lib\gdi32.lib
includelib \masm32\lib\comctl32.lib
.data?
hInstance dd ?:bg
it's like a jig-saw puzzle with a couple pieces missing
look at some of the example programs to see how they are organized
as for erasing the background, i will tell you a little trick i use :U
make a child window with no caption or borders for the image to be displayed in
you really only need 3 style flags: WS_CHILD or WS_VISIBLE or WS_CLIPSIBLINGS
when you load an image, size the child window to the same size as the image
when you register the class for the child, use NULL as the brush handle
the background will never be seen
if you have no image, hide the child window
in the child window WndProc, the only messages you have to handle is WM_PAINT and WM_CLOSE
in the WndProc for the main window, you do not have to handle WM_PAINT
so - it's basically moving some code around a little and registering a class :P
you can also get rid of the code in WM_PAINT that takes the lesser of the image size and the rcPaint size
#82
The Campus / Re: bmp viewer wish your optim...
Last post by xiahan - May 21, 2012, 05:34:12 PMQuote from: dedndave on May 21, 2012, 12:00:54 PMcan you send me a sample bitmap with that problem yahoo-email:xia_han@yahoo.cn
however, the program crashes if i try to open certain bmp files
not sure why that is, but it may be something to do with accessing addresses in the heap that aren't allocated
Quote from: dedndave on May 21, 2012, 12:00:54 PMwhat do you mean
i would just work on general "clean-up"
#83
The Campus / Re: bmp viewer wish your optim...
Last post by xiahan - May 21, 2012, 05:30:54 PMabout the flicker i googled it and found is because i
set the CS_HREDRAW or CS_VREDRAW when i fill the WNDCLASSEX structure
besides every time my window is coverd by other window then it again get the focus to
display topmost it will flicker anyway
http://www.catch22.net/tuts/flicker-free-drawing the same as the article points out
the system first send the WM_ERASEBKGND ,then WM_PAINT, so the window flicked
but when i write this
it behaves flicker-free , but before i load a certain bmp , the bkgnd is already un-erased
why?
edit: i discover the reason ,cause i didn't call the DefWindowProc
it seems in my wm_paint handler except paint the bmp , i have paint the rest bkgnd in the
PAINTSTRUCT retrieved by the beginpaint
set the CS_HREDRAW or CS_VREDRAW when i fill the WNDCLASSEX structure
besides every time my window is coverd by other window then it again get the focus to
display topmost it will flicker anyway
http://www.catch22.net/tuts/flicker-free-drawing the same as the article points out
the system first send the WM_ERASEBKGND ,then WM_PAINT, so the window flicked
but when i write this
Code Select
.elseif uMsg == WM_ERASEBKGND
.if hbmp
mov eax,1
jmp @f
.endif
xor eax,eax
it behaves flicker-free , but before i load a certain bmp , the bkgnd is already un-erased
why?
edit: i discover the reason ,cause i didn't call the DefWindowProc
Code Select
xor eax,eax
jmp def
...
.else
def:
invoke DefWindowProc,hWnd,uMsg,wParam,lParam
ret
it seems in my wm_paint handler except paint the bmp , i have paint the rest bkgnd in the
PAINTSTRUCT retrieved by the beginpaint
#84
The Campus / Re: Help, creating a Malloc fu...
Last post by Vortex - May 21, 2012, 04:57:49 PMHi RHL,
Did you try to use C run-time malloc function from msvcrt.dll ?
Did you try to use C run-time malloc function from msvcrt.dll ?
#85
Assembler/Compiler Technology / Re: My Assembler Development U...
Last post by johnsa - May 21, 2012, 03:37:47 PMNext update...
Lots of pain ...
Many bugs, much re-factoring, unit testing and regression testing. Changes to lexer and parser.
I've decided the smart thing to do would be to group instructions together according to shared parser rules. My thinking is that there are a number of instructions which can be handled by exactly the same rule set.
IE: All instructions that take NO parameters... A group for instructions that take one parameter being a memory address and so on.
I realized my idea with multiple passes was still flawed.. you DO need as many passes as it takes to solve the problem, but my solution to solve the jumps will still work. I've subsequently implemented FULL multi-pass support so that after each pass it knows
the state of forward references and symbol definition completeness.
This was necessary to solve things like this:
While doing this I noticed that ML/ML64 handle a lot of things FAR better than JWASM. Like the above which works in ML but not in JWASM without funny errors if these values are all fwd. references and defined after use.
This also breaks jwasm:
Whereas ML and mine handle this as expected by hitting maximum pass warning.
My solution to only adding symbols to the symbol table on reference works nicely. I've fully implemented org, EQU, Expression evaluation and a bunch of built-in pre-defined symbols for things like $, $$, true, false, null. I've tested some ORGs, forward references,
offset operator and more.
I've added a dump of the symbol table to a .sym file when you build in debug mode with binary output.
The debug mode execution will also demonstrate the parser deciding where to evaluate through recurssion or linear-state matching.
I'm starting to look at building up the line number info necessary for debug mode output. As yet I'm not sure what COFF etc requires for this, I'm assuming it needs a line number+address reference for every instruction? As well as line number for symbol definitions (which is already stored in the symbol table). Any thoughts?
The one thing I do want to fix here over ML is that the line number in source of the actual MACRO must be stored (as this annoys me currently) when debugging you can't really step into a macro and there's no reason why not.. it should be much like a proc.
I've also used all the cpu manuals and MASM manual to finish capturing every single instruction and directive into the lookups... that was painful.
Attached is the next update including the usual release/debug version with added info coming from the SYMBOL TABLE sub-system and EXPRESSION system. I've included a test file which has just about every possible expression i could come up with to test it.
Once I can solve the line number debug info, complete a few more opcode group rules I should be able to start on doing the first simple OBJ generation with COFF that will actually link, run and debug properly.
(I will need some assistance or advice around what info needs to be captured to .xdata / pdata etc).
It's going slower than I would've liked.. but at least its going :) 8000 lines of code and counting...
Lots of pain ...
Many bugs, much re-factoring, unit testing and regression testing. Changes to lexer and parser.
I've decided the smart thing to do would be to group instructions together according to shared parser rules. My thinking is that there are a number of instructions which can be handled by exactly the same rule set.
IE: All instructions that take NO parameters... A group for instructions that take one parameter being a memory address and so on.
I realized my idea with multiple passes was still flawed.. you DO need as many passes as it takes to solve the problem, but my solution to solve the jumps will still work. I've subsequently implemented FULL multi-pass support so that after each pass it knows
the state of forward references and symbol definition completeness.
This was necessary to solve things like this:
Code Select
A equ B
B equ C
C equ D
D equ 2
While doing this I noticed that ML/ML64 handle a lot of things FAR better than JWASM. Like the above which works in ML but not in JWASM without funny errors if these values are all fwd. references and defined after use.
This also breaks jwasm:
Code Select
A equ B
B equ A
Whereas ML and mine handle this as expected by hitting maximum pass warning.
My solution to only adding symbols to the symbol table on reference works nicely. I've fully implemented org, EQU, Expression evaluation and a bunch of built-in pre-defined symbols for things like $, $$, true, false, null. I've tested some ORGs, forward references,
offset operator and more.
I've added a dump of the symbol table to a .sym file when you build in debug mode with binary output.
The debug mode execution will also demonstrate the parser deciding where to evaluate through recurssion or linear-state matching.
I'm starting to look at building up the line number info necessary for debug mode output. As yet I'm not sure what COFF etc requires for this, I'm assuming it needs a line number+address reference for every instruction? As well as line number for symbol definitions (which is already stored in the symbol table). Any thoughts?
The one thing I do want to fix here over ML is that the line number in source of the actual MACRO must be stored (as this annoys me currently) when debugging you can't really step into a macro and there's no reason why not.. it should be much like a proc.
I've also used all the cpu manuals and MASM manual to finish capturing every single instruction and directive into the lookups... that was painful.
Attached is the next update including the usual release/debug version with added info coming from the SYMBOL TABLE sub-system and EXPRESSION system. I've included a test file which has just about every possible expression i could come up with to test it.
Once I can solve the line number debug info, complete a few more opcode group rules I should be able to start on doing the first simple OBJ generation with COFF that will actually link, run and debug properly.
(I will need some assistance or advice around what info needs to be captured to .xdata / pdata etc).
It's going slower than I would've liked.. but at least its going :) 8000 lines of code and counting...
#86
The Campus / Re: bmp viewer wish your optim...
Last post by dedndave - May 21, 2012, 12:00:54 PM"optimization" - there is always a way to optimize code - even after it has been optimizied - lol
it's looking better and better, each time
however, the program crashes if i try to open certain bmp files
not sure why that is, but it may be something to do with accessing addresses in the heap that aren't allocated
i would just work on general "clean-up"
i.e., organize the source code a little better, is all
we could use a second compatible DC in the WM_PAINT code to get rid of the flicker when sizing the window
it's looking better and better, each time
however, the program crashes if i try to open certain bmp files
not sure why that is, but it may be something to do with accessing addresses in the heap that aren't allocated
i would just work on general "clean-up"
i.e., organize the source code a little better, is all
we could use a second compatible DC in the WM_PAINT code to get rid of the flicker when sizing the window
#87
The Campus / Re: Help, creating a Malloc fu...
Last post by dedndave - May 21, 2012, 11:30:15 AMthe Rtl (run-time library) functions are intended for drivers, i think
GlobalAlloc will work but, as i remember, it calls HeapAlloc anyways :P
the Create functions create a heap - but the process already has a heap
i usually use HeapAlloc, as Rob suggested
during program initialization, do this one time
then, to allocate a block...
for Flags, i use NULL or HEAP_ZERO_MEMORY
the value returned in EAX is the address of the allocated block - it is also a sort of handle used to free the block
when you are done using the allocated block...
it is fast and simple :bg
the Rtl functions probably work very similarly, if you want to play with them
GlobalAlloc will work but, as i remember, it calls HeapAlloc anyways :P
the Create functions create a heap - but the process already has a heap
i usually use HeapAlloc, as Rob suggested
during program initialization, do this one time
Code Select
INVOKE GetProcessHeap
mov hHeap,eaxthen, to allocate a block...
Code Select
INVOKE HeapAlloc,hHeap,<Flags>,<BytesRequired>
mov hBlock,eaxfor Flags, i use NULL or HEAP_ZERO_MEMORY
the value returned in EAX is the address of the allocated block - it is also a sort of handle used to free the block
when you are done using the allocated block...
Code Select
INVOKE HeapFree,hHeap,NULL,hBlockit is fast and simple :bg
the Rtl functions probably work very similarly, if you want to play with them
#88
The Soap Box / Re: New Forum
Last post by hutch-- - May 21, 2012, 06:52:55 AMYes, there was no way I could transfer the old database to the new forum.
#89
The Soap Box / New Forum
Last post by Neil - May 21, 2012, 06:41:46 AMTried to log in on the new forum & it says my user name does not exist, does that mean I have to re-register?
#90
The Campus / Re: Help, creating a Malloc fu...
Last post by Farabi - May 21, 2012, 03:50:03 AMYou can use this
Code Select
mAlloc proc nSize:dword
add nSize,4
invoke GlobalAlloc,GMEM_ZEROINIT or GMEM_FIXED,nSize
.if eax==0
invoke MessageBox,NULL,CADD("Unable to allocate memory"),NULL,MB_OK
.endif
ret
mAlloc endp