Hello all,
i started using ml.exe and link.exe version 12
but compiled dialogs not showing.
As you can see, everything gets compiled without any errors.
If i compile it with old ml.exe and link.exe the dialog is visible!
Any help is much appreciated
rc /v "DlgMain.Rc"
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation. All rights reserved.
Creating DlgMain.res
Using codepage 1252 as default
DlgMain.Rc.
Writing DIALOG:1000, lang:0x409, size 66.
Writing 24:1, lang:0x409, size 612.
Writing RCDATA:5000, lang:0x409, size 54553
ml /c /coff /Cp "DlgMain.Asm"
Assembling: DlgMain.Asm
***********
ASCII build
***********
Microsoft (R) Macro Assembler Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
link /SUBSYSTEM:WINDOWS /RELEASE /VERSION:4.0 /OUT:"DlgMain.exe" "DlgMain.obj" "DlgMain.res"
Microsoft (R) Incremental Linker Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
Deleted: DlgMain.obj
Deleted: DlgMain.res
Make done.
Executing:
"DlgMain.exe"
p.s.:
i use RadAsm, maybe its only a compiler switch that i am missing?
Hi Amadeus,
Here is a simple dialog box example. Try to compare it with your project, maybe you can catch the error.
Hi Vortex,
thanks for your example.
Same game, compiling with your Make.bat working
compiling through RadAsm using older version of link exe also working.
Compiling through RadAsm using v12 link.exe still nothing is shown!
I am really out of ideas
here the project options under RadAsm
https://i.imgur.com/MC0k7Kn.png
perhaps the linker isn't really up to date,actual 14.28.29914.0
Try /VERBOSE (link) to see if there is problems.
Quote from: TouEnMasm on April 19, 2021, 02:54:13 AM
perhaps the linker isn't really up to date,actual 14.28.29914.0
The linker supplied with the Masm32 package, Version 5.12.8078 can be used for general purpose programming.
Quote from: Amadeus on April 19, 2021, 01:30:51 AM
If i compile it with old ml.exe and link.exe the dialog is visible!
Please zip both versions and post them here. It's probably a trivial problem.
i managed it to compile with simple DLG
apparently the issue is when a picture is placed on the DLG.
I suppose it have to do with a used library.
tia for your help
in attachement is the project and included are both ML.exe, LINK.exe and RC.exe in Ver. 5 and 12
[sorry could not make attach the other file they exceed allowed filesize]
Sorry, what I meant is attach your two executables - the one that works fine, and the other one that doesn't.
ah i missunderstood, sorry
here they are.
The exe assembled with v12 has a heap corruption problem (->critical error c0000374).
Even with a debugger, this problem is difficult to chase. Until call <jmp.&user32.DialogBoxParamA>, both executables are identical. Then one of them misbehaves on freeing some memory... no idea what causes that. Have you tried with different images?
In case you have MasmBasic installed, there is a handy program at \Masm32\MasmBasic\Res\DebugHeap.exe; if you drag your exe over DebugHeap.exe, it will run fine but display ## Critical error detected c0000374, which means heap corruption. Check in particular line 57 of gdiplusLoadBitmapFromResource.inc, maybe allocating some bytes more solves the problem.
thanks JJ2007
i made this change, removed the Local var and made it global.
.data?
hbuffer dd ? ; <<<<<<<<
.code
gdiplusLoadBitmapFromResource proc hInst:HMODULE, lpName:LPSTR, lpType:LPSTR, pBitmapFromStream:DWORD
local rcRes:HRSRC
local hResData:HRSRC
local pResData:HANDLE
local sizeOfRes:DWORD
; local hbuffer:HANDLE ; <<<<<<<<<
local pbuffer:DWORD
local pIStream:DWORD
the effect now is, if i run the v12 compiled exe in a debugger
all runs fine, DLG appears with the picture on it.
Out of the debugger nothings change.
Quote from: Amadeus on April 19, 2021, 07:50:10 AM
i made this change, removed the Local var and made it global.
That can be an issue if it's a WndProc callback, but not here: hbuffer gets set once, and used only inside the proc.
I attach my adapted version, tested with MASM 6.15 and 14.x versions. No problems detected...
hi JJ2007,
thanks for your example.
Well seems i have to use 6.15
problem of corrupted heap still persist.
Will do tomorrow another try, its past 1 a.m, and i am a bit tired.
Hi Amadeus,
This bug is very atypical. Usually \Masm32\MasmBasic\Res\DebugHeap.exe signals that heap memory is being accessed beyond the allocated number of bytes, here it just complains about corruption.
Tomorrow is another day. AFAICS you have no errors in your code...
Hello JJ2007,
i think that this error occurs due the fact of using old libraries. (the ones that comes with masm 6.x)
Anyway it was worth a try.
Thanks for your help
Amadeus
Quote from: Amadeus on April 20, 2021, 03:48:33 AM
i think that this error occurs due the fact of using old libraries.
:thumbsup:
Just use Polink instead of Link. (No problem with ML14)
Quote from: HSE on April 20, 2021, 05:31:53 AM
Quote from: Amadeus on April 20, 2021, 03:48:33 AM
i think that this error occurs due the fact of using old libraries.
:thumbsup:
Just use Polink instead of Link. (No problem with ML14)
replace any linker is good choice,because I had problems earlier with suspected corrupted linker,got strange behaviour when running .exe
Quote from: Amadeus on April 20, 2021, 03:48:33 AM
i think that this error occurs due the fact of using old libraries. (the ones that comes with masm 6.x)
Hi Amadeus,
The libraries shipped with the Masm32 package are not old. I always use them and never had any problems.
Quote from: Vortex on April 20, 2021, 10:17:48 PM
Quote from: Amadeus on April 20, 2021, 03:48:33 AM
i think that this error occurs due the fact of using old libraries. (the ones that comes with masm 6.x)
Hi Amadeus,
The libraries shipped with the Masm32 package are not old. I always use them and never had any problems.
I can echo that. It's also unlikely that the linkers cause such problems. OTOH it is known that some later versions of MASM have serious bugs, see e.g. MASM 14.0 .if signed comparison bug (http://masm32.com/board/index.php?topic=6447.0):
QuoteThis issue affects:
14.0.23026
14.0.23506
14.0.23918
14.0.24210
14.0.24218
14.10.25017
It doesn't affect:
12.0.40629 or older
However, as written above, the two versions (one fails, the other works) look identical under the hood :rolleyes:
Best soluce is to download a sdk and use the ml and binaries provided by it.
It's FREE.
Quote from: TouEnMasm on April 20, 2021, 11:44:04 PM
Best soluce is to download a sdk and use the ml and binaries provided by it.
It's FREE.
Yves,
Apparently the OP
does use an SDK. Btw it's "solution", not "soluce".
QuoteQuote from: Amadeus on April 19, 2021, 01:30:51 AM
i started using ml.exe and link.exe version 12
so little update.
the combination ml/link v12 causes this problem
so i tried ml v12 and link v5 and all is good!
Now the question is , why link v12 causes that heap corruption?
Funny that it is the linker. I've checked again, the two versions are identical and behave identically, except that
- the v12 version has an extra reloc section (useless, it seems)
- the v12 version throws an exception inside call near [<&ntdll.RtlFreeHeap>]. That's why I suggested that you try to increase (by a few bytes) the *alloc bytes.
hi JJ2007,
increasing the alloc does the job.
Will try other version to check if they have that bug too.
Quote from: Amadeus on April 21, 2021, 10:09:55 PMincreasing the alloc does the job.
Will try other version to check if they have that bug too.
Not sure if it's a bug, though - it could be a problem with the logic of your code, too. For example, does it need ony byte more to care for a zero terminator?
Does it work if you increase the alloc by only one byte?
well, you are right.
In this case if i have to add 4 bytes to the allocation and it will work.
Now from programmers reference i found this:
The SizeofResource function returns the size, in bytes, of the specified resource.
.
.
Remarks
The value returned may be larger than the actual resource because of alignment. An application should not rely upon this value for the exact size of a resource.
Need to do further test if those more bytes varies from resource to resource.
ps: tested with few differentpics and always have to add 4 bytes to the allocation
i think i can live with that.
Thanks to all for the help
Amadeus