Is my Pelles C Debugger skipping lines?

[Bitbeisser]

Ralf speaks the truth ...    (Hi Ralf)

Hi and thanks as well! 

Looking at the part of your code where you open your file, there is a far simpler way of doing that...

1) Use GetFileAttributesEx() to get the file size and attributes.
2) Use calloc() or malloc() to create the buffer, with a few extra bytes for good measure.
3) Open the file using the winapi  CreateFile() call
4) Read the whole thing into memory in one go with ReadFile()
5) Close the file with FileClose()

Now you have an array of bytes and can access the entire thing using simple notation like ...  bmp[offset] without any seeks pre-reading or backtracking...
 
Think what happens if the file size in the header is wrong...

Even more clever you can design a struct for the header information and overlay that on the buffer to access the variables directly from the buffer... none of this Read4Bytes crap.

Well, I do not quite agree with you here...

Reading in a whole file might work for small or even midsize (a couple 100KB) files, but for larger files, you are just wasting time (and RAM!). Windows caching is pretty good, so there is no real a penalty in doing so, and when taking a brief look at the over all code, I rather feel it enhances a bit the readability of the code...

And certainly, none of this is the source of his debugger problems... 

Ralf

[CommonTater]

Reading in a whole file might work for small or even midsize (a couple 100KB) files, but for larger files, you are just wasting time (and RAM!).

It's a BMP file... he needs the header to know the setup of the file, he needs the entire bitmap available at one time if he's going to bitblt or otherwise copy it to a window.  So, read the whole file then parse the header... it's the easiest way.
 
With 4 and 8gb of ram becoming common place, space is hardly a problem.
Plus he can free it when he's done, so nothing is wasted.

I do this all the time Ralf... 100mb+ files with no problems.  It's blinding fast when you can work the data from memory and it's really quite simple code-wise. 
 
It is (IMO) "old think" --a mistake-- to cling to character by character or line by line methods that were made necessary by limited resources when those limitations are long gone.

Consider this trivial example...

Code: [Select]

typedef struct t_FILEHDR
  {
     DWORD DataSize;
     DWORD DataOffset;
     CHAR  TagName[256];
   } FILEHDR, *pFILEHDR;
 
PVOID Data;
 
// now read the entire 10mb file into memory  at Data
 
printf("Data Size = %u", ((pFILEHDR) Data)->DataSize);
printf("Data Offsert = %u", ((pFILEHDR) Data)->DataOffset);
printf("Tag Name = %s", ((pFILEHDR) Data).TagName);
 
ParseData(Data + ((pFILEHDR) Data)->DataOffset, ((pFILEHDR) Data)->DataSize);

How much easier do you want it to be?
 

And certainly, none of this is the source of his debugger problems... 

Absolutely.  This has nothing to do with his debugging problems... it was just a suggestion from looking at his code... which is rather convoluted at the moment. 
 

[TimoVJL]

Example for debugging.
At line 30 debugger lost control.

Code: [Select]

#define UNICODE
#define WIN32_LEAN_AND_MEAN
//#define WIN32_DEFAULT_LIBS
#include <windows.h>
#include <ole2.h>

#pragma comment(lib, "ole32.lib")

CLSID const IID_IScriptControl = { 0x0E59F1D3, 0x1FBE, 0x11D0, {0x8F, 0xF2, 0x00, 0xA0, 0xD1, 0x00, 0x38, 0xBC} };

TCHAR *szAppName = TEXT("MSScriptTest");

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
{
HRESULT hr;
GUID clsid;
IDispatch *pISC = NULL;

hr = CoInitialize(NULL);
hr = CLSIDFromProgID(L"MSScriptControl.ScriptControl", &clsid);
if (hr)
MessageBox(0, TEXT("Error CLSIDFromProgID()"), szAppName, 0);
else {
hr = CoCreateInstance(&clsid, NULL, CLSCTX_ALL, &IID_IScriptControl, (void **)&pISC);
if (hr)
MessageBox(0, TEXT("Error CoGetClassObject()"), szAppName, 0);
else {
//MessageBox(0, "OK", szAppName, 0);
pISC->lpVtbl->Release(pISC);
pISC = NULL;
}
}
CoUninitialize();
return 0;
}

[Hydronium]

What I would test in your case, place a breakpoint right in front and right behind the function call in question. If the call to the DLL returns properly, the second on should stop the program again.

Sorry if my description is vague, but I can't think of any other way of describing it. Also, if anyone has an nVidia or ATI (specifically ATI in my case, since nVidia's might not do this strange stuff) graphics card you should have the associated drivers and wglGetProcaddress should find it. Even an integrated GPU should have drivers for simple OpenGL graphics, I would think (but I'm not sure).

I can do what you've described above, and it does as you say. This is why I'm unsure why I explicitly need to tell the debugger to stop. I've never built a compiler or debugger, so it's probably something way over my head, design-wise. I suppose it is not a huge problem, but it will make debugging slightly more tedious.

Thanks.

Looking at the part of your code where you open your file, there is a far simpler way of doing that...

Even more clever you can design a struct for the header information and overlay that on the buffer to access the variables directly from the buffer... none of this Read4Bytes crap.

At the time, I was looking up purely C related functions to do the job. Honestly, I hadn't even thought of what WinAPI calls windows had available and didn't think to look. I'll investigate it, though the more transferable my code is between platforms the better so that I have less to change if I ever move to a different OS. The WinAPI calls may be the best bet for this particular implementation anyways. Thanks.

Even more clever you can design a struct for the header information and overlay that on the buffer to access the variables directly from the buffer... none of this Read4Bytes crap.

It's a BMP file... he needs the header to know the setup of the file, he needs the entire bitmap available at one time if he's going to bitblt or otherwise copy it to a window.  So, read the whole file then parse the header... it's the easiest way.

I designed those little procedures because the bytes are in little-endian format, and I needed to reverse them for those particular entries in the header. Does your suggestion take care of that, or do you mean I should do the byte-twiddling after having all the information in memory?

Also, the bmp data is only read in so that I can then load it into GPU memory with the glTexImage2D call. It only requires the data, not the header. I thought it would be simpler to read and not store the header data, and only read the data into memory, as the call requires a pointer to the texture data (not including the header, which the GL can not interpret). Is this irrelevant, given what you've said (ie, did you take it into account, or does it not matter)?

Absolutely.  This has nothing to do with his debugging problems... it was just a suggestion from looking at his code... which is rather convoluted at the moment. 

Could you expand on that? Is the design convoluted, the implementation, something else (hopefully not all of it )? Thanks.

[CommonTater]

Looking at the part of your code where you open your file, there is a far simpler way of doing that...

Even more clever you can design a struct for the header information and overlay that on the buffer to access the variables directly from the buffer... none of this Read4Bytes crap.

At the time, I was looking up purely C related functions to do the job. Honestly, I hadn't even thought of what WinAPI calls windows had available and didn't think to look. I'll investigate it, though the more transferable my code is between platforms the better so that I have less to change if I ever move to a different OS. The WinAPI calls may be the best bet for this particular implementation anyways. Thanks.

Grab a copy of the Windows 7 sdk ... HERE You only need to install the desktop documentation, pretty much everything else is supplied by Pelles C...
 
As for the fantasy of platform independent code... my friend, you're playing with DRIVERS which are just about the least platform independet code you're going to find. 
 

I designed those little procedures because the bytes are in little-endian format, and I needed to reverse them for those particular entries in the header. Does your suggestion take care of that, or do you mean I should do the byte-twiddling after having all the information in memory?

Windows is natively little endian.  Overlay a struct on the header portion of the file... do the values it gives you make sense?
 

Also, the bmp data is only read in so that I can then load it into GPU memory with the glTexImage2D call. It only requires the data, not the header. I thought it would be simpler to read and not store the header data, and only read the data into memory, as the call requires a pointer to the texture data (not including the header, which the GL can not interpret). Is this irrelevant, given what you've said (ie, did you take it into account, or does it not matter)?

Take another look at the example I supplied to Ralf... The hints are all there....
 

Absolutely.  This has nothing to do with his debugging problems... it was just a suggestion from looking at his code... which is rather convoluted at the moment. 

Could you expand on that? Is the design convoluted, the implementation, something else (hopefully not all of it )? Thanks.

There's no such thing as bad code, provided it actually works... But there is always a way to simplify your approach and make things work better.  I would suggest your code reflects a lack of planning... the bright idea, straight to keyboard approach seldom gives you the best outcomes.
 
 

[Bitbeisser]

What I would test in your case, place a breakpoint right in front and right behind the function call in question. If the call to the DLL returns properly, the second on should stop the program again.

Sorry if my description is vague, but I can't think of any other way of describing it.

Well, the main problem with trying to give help in a forum like this is that we can't see what yo are doing. So a description you write down can sometimes interpreted in different ways and might therefor need clarification...

Also, if anyone has an nVidia or ATI (specifically ATI in my case, since nVidia's might not do this strange stuff) graphics card you should have the associated drivers and wglGetProcaddress should find it. Even an integrated GPU should have drivers for simple OpenGL graphics, I would think (but I'm not sure).

I haven't been much into graphics programming on Windows for almost two decades now, pretty much since OpenGL was first pulished. But I thought that it's purpose is to provide a device independent way to do 2D and 3D graphics on Windows, so I am not sure why your code depends on a specific DLL. And as I am currently be short on time due to RL issues, just stopping by the forum for a couple of minutes, I haven't had the time to take a closer look yet....

I can do what you've described above, and it does as you say. This is why I'm unsure why I explicitly need to tell the debugger to stop. I've never built a compiler or debugger, so it's probably something way over my head, design-wise. I suppose it is not a huge problem, but it will make debugging slightly more tedious.

Well, if it works the way I suggested, then this means that something in the DLL (or with the parameters call functions in it) isn't quite kosher and messes with the debugger environment. I think it would take a bit more investigating as to why this is happening...

Ralf

[Hydronium]

As for the fantasy of platform independent code... my friend, you're playing with DRIVERS which are just about the least platform independet code you're going to find. 

But I thought that it's purpose is to provide a device independent way to do 2D and 3D graphics on Windows, so I am not sure why your code depends on a specific DLL.

OpenGL is platform-independent, and only needs the drivers supplied by the graphics card makers. ATI supplies Linux drivers, and I assume Apple has drivers somewhere or another. Same for nVidia, and possibly other GPU makers. The drivers will be specific to the machine, but the API will always be the same (glClear on Windows is glClear on Apple is glClear on Linux).

Windows is natively little endian.  Overlay a struct on the header portion of the file... do the values it gives you make sense?

I never even though to do that, that's pretty clever. The only thing I'm worried about is the first few pieces of data. I'd have to make sure the struct is packed to a 2-byte alignment, instead of whatever Pelles C chooses. I'm away from my regular computer at the moment, so I'm not able to start looking into this. I definitely will though, as it could make this much simpler (maybe not quite yet though, as I'd like to reach the point of code which started this thread topic to see if my Access Violation error is gone).

Thanks.

[CommonTater]

I never even though to do that, that's pretty clever. The only thing I'm worried about is the first few pieces of data. I'd have to make sure the struct is packed to a 2-byte alignment, instead of whatever Pelles C chooses. Thanks.

Look in the help file at pragmas... I believe you will want #pragma pack(2)  before your struct definition then #pragma pack() after.  You may also have to add some filler bytes in the event the compiler decides to insert them in different places than you want...  But it is doable.
 
I'd also check in your header files... you may find a bmp header struct already defined that you can use.