Search results for query: *

fixed!

here is the code updated to fix a memory leak: #include <windows.h> LRESULT WndProc(HWND, UINT, WPARAM, LPARAM); struct dib { dib(void) { init(); } dib(int w, int h) { init(); make(w, h); } void init(void) { memset(&bmi, 0, sizeof(bmi)); bmi.bmiHeader.biSize =...

when I create a DIB with CreateDIBSection, I only seem to be able to write to the bits once. I inserted calls to GdiFlush throughout the code but that doesn't seem to solve the problem. here is the test code: #include <windows.h> LRESULT WndProc(HWND, UINT, WPARAM, LPARAM); struct dib {...

of course! I completely overlooked that - touche! good job, Dave. I think I've been spending too much time with the stl this week...must...take...break.

well, if it's even-sized the two center bytes are swapped; if it's odd-sized the center byte remains the same (as it should).

you can use a two-dimensional array of course: const int max = 10, size = 256; char strings[max][size+1]; strcpy(strings[0], "hello"); printf("%s", strings[0]);

of course, using your method we don't have to test length's non-zero-ness at the beginning of the loop...so I suppose you're right. =)

either way works fine since the end pointer is guaranteed to be greater or equal to the forward iterator (since length is unsigned).

>> any others bright optimisation? maybe: void * ReverseBytes(void * buffer, size_t length) { register unsigned char temp, * p, * e; if(length) { for(p = buffer, e = p + (length - 1); p != e; ++p, e--) { temp = *p; *p = *e; *e = temp; } } return buffer; }

Thank you. :)

I can't figure this out. All I need to do is mov the contents of sp into a register, but nasm complains 'invalid effective address'. I've tried it with every single register combination, but it won't let me do it. Please help!

I don't see any code for searching for the word? Why don't you try something out before you post here (attempt something, at least).

I haven't gotten it to work, yet, actually. It's really got me stumped. First of all, everyone is telling me you can't use 32bit code in real mode (which is what I'm in, entering the bootstrap process). So I modified all of my code accordingly, but nasm won't let me do: mov dx, [sp+2]; 'error...

Ok, I get it. Basically by using lea in that context I was creating a malformed pointer using the first four chars of msg - hence the error! Or in C: char * ptr = someBuffer; char * badptr = (char*)((int)(*ptr)); Thanks for all the help, by the way. :) Cheers. - Sebastian

Thank you very much, it's a lot clearer now, and everything is working properly! >> Calling interrupt is a violation in windows, especially BIOS interrupt I know. I'm just dabbling with a small OS, hence the BIOS code. >> Right. So you can just use MOV reg, [esp+4]. Oddly enough, lea didn't...

I guess the real problem is just that I do not know how to access data from the stack properly. I simplified the problem a bit in order to narrow down the possibilities, but each and every time the output is erroneous. Here is a simpler program I tried: (assembler: nasm, 32 bit environment)...

>> lea puts the offset of the thing you are aiming at into the destination register, while mov puts the thing. Right, but since I pushed an address, then that 'thing' would be an address, not the contents at that address (ie: the first element of the string) - right? >> Therefore near calls...

Okay, I read some more from the Intel manuals and see that I was accessing the stack incorrectly (obviously, right?). I made changes to the code but it still doesn't work. Here is basically what I understand now, and what I tried: 1) When a 'call' is invoked, the return address is pushed on the...

Before you ask a question like that, you need to thoroughly read and understand the specification for the image format you have to decipher (wotsit.org has some decent specs on many file formats, by the way).

Hello, I have a question with accessing stack variables - I am using NASM. Here is what I did on the calling side: push msg ; msg is a null-terminated string call print add esp, 4 And for the callee: print: mov si, [esp-4] ; more code... For some reason, esp-4 doesn't seem to hold the...