Dialog don't show

[HSE]

i think that this error occurs due the fact of using old libraries.

Just use Polink instead of Link.  (No problem with ML14)

[daydreamer]

i think that this error occurs due the fact of using old libraries.

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

[Vortex]

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.

[jj2007]

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:

This 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

[TouEnMasm]

Best soluce is to download a sdk and use the ml and binaries provided by it.
It's FREE.

[jj2007]

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".

i started using ml.exe and link.exe version 12

[Amadeus]

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?

[jj2007]

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.

[Amadeus]

hi JJ2007,

increasing the alloc does the job.

Will try other version to check if they have that bug too.

[jj2007]

increasing 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?

[Amadeus]

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:

Code Select Expand


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