News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Can't load a bitmap resource?!?!?

Started by NoCforMe, May 12, 2024, 07:49:21 AM

Previous topic - Next topic

NoCforMe

This is bugging the shit out of me.
I've done this many times before: embed a bitmap in a program using the resource compiler, then loading the bitmap and using it. Works fine.

Now, all of a sudden for some strange reason I can't do that. When I try to load the bitmap I get an error.

Here's what I'm doing:
  • Creating the bitmap (I use Paint Shop Pro, which has always worked for me in the past)
  • Create a resource (.rc) file with the name of the bitmap file and a resource ID:
    500 bitmap "some picture.bmp"
  • Define a constant for that bitmap in the program source:
    $somePictureID    EQU 500
  • Assemble the program
  • Run the resource compiler against the .rc file
  • Run the cvtres program against the resulting .res file to create an .obj file
  • Link everything together into an .exe
  • In the program code, load the bitmap as a resource:
    INVOKE   LoadImage, InstanceHandle, $somePictureID, IMAGE_BITMAP, 0, 0, LR_SHARED
This has worked every time up to now. But now I get an error from LoadImage():

The specified resource type cannot be found in the image file.

WTF?????

So far as I can tell everything's the same as it's always been. But now every single program I write that uses this method fails. It's like there's some kind of gremlin loose in the machine.

I've tried a lot of things:
  • Something wrong with the BMP? I save it with Microsoft Paint; it still fails.
  • Tried taking out the LR_SHARED and replacing it with zero: still fails. (See note below.)
  • I checked all my MASM tool executables (ml, link, rc, cvtres) to see if they might have gotten corrupted somehow: nope.
  • Tried making different size BMPs; makes no difference.
If you run PE Explorer against the .exe it always finds the bitmap resources, no problem.

I have an older program that uses the exact same method to load BMPs. I remade it (reassemble, re-resource compile, relink); it still works. ?????

I say everything's the same, but obviously it's not; but what could be different?

I've attached an exe for testing. Could someone run this and report what it says? All it does is try to open a bitmap resource in the .exe, and report on the result using GetLastError() and FormatMessage() (result appears in the status bar at bottom).

If you felt like it you could load this up in a debugger and see what happens when LoadImage() executes (it's only in there one time).

Thanks!

Note: I've always used LR_SHARED with LoadImage(), which has this advantage according to Microsoft:
QuoteWhen you use this flag, the system will destroy the resource when it is no longer needed.
But then they throw this wrench into the works:
QuoteDo not use LR_SHARED for images that have non-standard sizes, that may change after loading, or that are loaded from a file.
Now I don't think that's even true; I've loaded lots and lots of bitmaps with definitely nonstandard sizes with nary a problem.
But I tried removing this flag anyhow; as I said above, it made no difference.
Assembly language programming should be fun. That's why I do it.

jj2007


zedd151

#2
Works okay here.
    include \masm32\include\masm32rt.inc

    .data
        hInstance  dd 0

    .code
    start:
        invoke GetModuleHandle, 0
        mov hInstance, eax
        invoke LoadImage, hInstance, 500, IMAGE_BITMAP, 0, 0, LR_SHARED
        invoke ExitProcess, eax

    end start
Running in olly, LoadImage returns the bitmap handle

The exe you attached NoCforMe, has a bitmap with resource ID of 504 not 500
:azn:

zedd151

#3
 Okay, I see that you ARE trying to load the bitmap with resource ID of 504. Apologies. I looked at it in olly.
Your post was mentioning ID 500 that is why I noted it.

There are times when I save an indexed bitmap with GIMP, I have to check the option "Do not write color space information" for compatibility. Maybe that is the case for your image? Is it RGB or indexed?

How about for images that were not created with Paint Shop Pro??? I am think that there is some option/setting in Paint Shop Pro (that you had inadvertantly changed causing you this grief) which you said has always worked for you in the past... until recently.
---- later ---- I have extracted the bitmap from your executable ---------
I have resaved the image using GIMP, without writing color space information (attached)
See if it makes a difference for you..  it is in 504.zip

Also I made a test using that image.. in Bitmap_504,zip. Run it in olly - it is not a GUI program - only for demonstration that the bitmap loads successfully.



And I notice in your executable, you are NOT using LR_SHARED when loading the bitmap:wink2:
I tweaked your exe in ollydbg... The image then loads (with LR_SHARED)
:azn:

NoCforMe

Sorry 'bout the 504/500 mixup. I changed it to 504 at the last minute (both the resource file and the ID used for LoadImage()) out of superstition, as I used that # to load the very same image in another program (which worked).

Dunno if you missed it, but I wrote that I saved the image with Microsoft Paint before making the project, so the problem has nothing to do with Paint Shop Pro.

The bitmap is an ordinary 16-color BMP, so it has a palette. The exact same BMP loads perfectly in another program.

There's a resource file. If anyone likes I can attach the whole shebang.
Assembly language programming should be fun. That's why I do it.

zedd151

No, I am satisfied that LoadImage works with LR_SHARED. Even in your attached exe from your post above. (patched in ollydbg) Dunno what happened on your end though, as mentioned in your first post...

You can post it though, for anyone else that might like to explore it.  :thumbsup:

Now if you do discover what caused the issues for you in the first place, I am sure that others will be interested in what had happened.
:azn:

NoCforMe

So I'm not sure what result you got when you ran my .exe; did it fail or not?

Complete project attached here.
Assembly language programming should be fun. That's why I do it.

zedd151

Originally it failed since LR_SHARED was not used. I added it in ollydbg then the image loaded okay, while stepping the code. (the changes made to that piece of code corrupted the code that followed, though) so had to abort.  :tongue:
:azn:

NoCforMe

Well, it still fails for me both ways (using LR_SHARED or not). You can play with the source now to change that.
Assembly language programming should be fun. That's why I do it.

zedd151

#9
Quote from: NoCforMe on May 12, 2024, 10:29:29 AMYou can play with the source now to change that.

I made a few minor changes .bat file, .rc file, and removed the .list - .nolist in the asm file
and resaved the bitmap file with the GIMP -  saved it as "fixed.bmp"...
:azn:

NoCforMe

OK, so you made a few cosmetic changes. (Uppercasing "BITMAP"? really?)

But you failed to mention: what was the result?

Deleting the .rsrc and .obj files is NOT gonna make this work, believe me.

Well, I ran your .exe and guess what? it worked.
Question now is, why?
I'm 120% sure it has nothing to do with removing .nolist/.list, but what the hell, I'll try that ...
That's the only change you made to the source, right?
Assembly language programming should be fun. That's why I do it.

zedd151

It works.

Also the resource ID then "BITMAP" in the .rc file.  You had "bitmap" then the resource ID.

The .bat file is from one of my templates, hence renaming the resource file to rsrc.rc.

I only delete the .res and .obj files, if succesfully assembled and linked.
Use your own batch file, its okay with me. I only made adjustments to what I am more familiar with, hence no cvtres either - not needed. The .res file gets linked just fine.
:azn:

zedd151

#12
Here this should be more to your liking. It also uses the original bitmap. But I still adjusted the rc file

I did however need to fix the paths in your batch file. Not all of us have masm32 in our environment 'PATH' or however your setup is configured.
:azn:

zedd151

Quote from: NoCforMe on May 12, 2024, 11:35:54 AMI'm 120% sure it has nothing to do with removing .nolist/.list, but what the hell, I'll try that ...
That's the only change you made to the source, right?
Yes, the only change there. I have no need for the listing file. Nor the debugging stuff.
:azn:

sinsi