Posts by toolmanx

I believe I have solved my own question.
Here is the way it appears to work.

LowPart in little endian then HighPart in little endian

Of course, little endian is for my machine. Others
may differ. If I am in error, please let me know.

This is the hex output from a LARGE_INTEGER.
"EA 00 0B 00 A1 00 00 00"
On my machine a DWORD is read "00 0B 00 EA"
How do you place the high 32 bits in the
sequence?

This leads me to the question of how to
output this to screen. I use _snprintf
normally to ready my data for "TextOut".

I don't have largeint.h on my machine. I am
guessing that there might be some API to
prepare a LARGE_INTEGER for output in it.
Does anyone know how to read and write
these things?

I'm running AMD SP1 with Bcc55.

Just to let everyone know. The suggestion works great. That was my problem.

OK, I'll try that. When you explained it to me in the timer thread, I thought you were suggesting that I leave the paint code right at the timer code. I'll try your suggestion now and put it in the paint case.

I spent a lot of time trying to find out why "Message Box'
made my program act like it crashed. Originally I had to
bring up the Task Manager every time I allowed "Message
Box' to run to shut down the program. After much
experimentation I found that if I hit the "Alt" key,
the MB would show on the screen. "OK"ing the MB allowed
my program to proceed normally. All along I suspected
a focus problem but since MB is a black box, I had no
idea what was happening. By pure chance, I put a little
TextOut code snippet into the function. I do this to
see what's going on inside functions quite a bit. With
these four lines of code, MB started working normally.
This is exactly the same solution to the SetTimer
problem I had posted a thread about in this site a week
or so back. It bothers me that I need a BeginPaint and
EndPaint entry to prevent strange things from happening
in my programs. I can force things to work right with
a fudge but that's not right. I'd sure like one of you
experts to tell me why this is occurring. I'm
running AMD with SP1. Compiling with either "cl" or
BCC55 gives me the same results. I'll include a small
program with the code in it so you can compile …

To Ancient Dragon:

I appreciate all the work you did. I've been working on it too. Without the paint sequence, the stack loads differently. It seems the compiler leaves out one line of code "POP EBX". This causes the stack to get one less line.

I hate to have a program with a fudge like this. I use this little program as a blank to compile various api's so I can see them in assembly.

If you've given up, I will too and just keep the fudge in.

toolmanx@ij.net

I've been doing some experiments while waiting for further replies.

If I move the two timer functions above the "DoMenu" function, then MessageBox will work. I don't know why but you can't beat success.

If I block off the TextOut portion inside the SetTimer it still does not work even with both functions above the DoMenu.

I blocked off the print text code in the time function and then raised the time to 10 seconds. Thaat failed. Then I killed the timer in the procedure as you suggested. That failed. Maybe I am not understanding what you suggest correctly. Please clarify.

Sorry I got onto the wrong thread. Please delete this from this thread. I have copied it all over to the recommended thread.

I have a simple program that I am having trouble debugging.
It contains two different problems.

1. If I run a MessageBox in this program after the program is
up and running, the program crashes. I have to call the
Task Manager to shut down the program.

2. SetTimer will not work unless I put other code in the
funtion containing it. I've pinned down what happens using
a debugger but don't know how to cure it. I'm popping BPX
with a bad momory position after SetTimer completes.

The program is in working order now by fudging and the
"points of failure" are documented in the program.
I tried to eliminate compiler problems by compiling
using two different compilers. "cl" and Borland BCC.
Both act the same.

I run an AMD with SP1.

I have a simple program that I am having trouble debugging.
It contains two different problems.

1. If I run a MessageBox in this program after the program is
up and running, the program crashes. I have to call the
Task Manager to shut down the program.

2. SetTimer will not work unless I put other code in the
funtion containing it. I've pinned down what happens using
a debugger but don't know how to cure it. I'm popping BPX
with a bad momory position after SetTimer completes.

The program is in working order now by fudging and the
"points of failure" are documented in the program.
I tried to eliminate compiler problems by compiling
using two different compilers. "cl" and Borland BCC.
Both act the same.

I run an AMD with SP1.

Thanks for the thread. It looks interesting. I have only given it a quick scan so far. I will carefully look it over in the next day or so and see if it solves the problem.

I program using Win32 API's. I compile with Borland or Microsoft "CL".
I am on an XP machine. I use .cpp extensions to compile so C++ rules apply.

I'm trying to get the bytes from my screen and send them to a disk file.
I get a handle I call "MemDC" from the CreateCompatibleDC, use it in
a CreateDIBSection. I select the DIB into the "MemDC, then blit the
screenDC to MemDC. That works fine. I can blit it to hDC and repaint
it back to my screen as a test. No problem, that works.

My problem begins because the system sends the bytes to memory that I
can't seem to get to. I GlobalAlloc for "MyBits" with "ppvBits" pointing
to "MyBits" in DIBSection. I believe this is right. The blit "on my
machine" sends the bytes to 0x008F0020. "MyBits" on the heap starts
at 0x00820020 waiting for the bytes to come in. The bytes go to where
the system wants to send them. I accept that, but need them in "MyBits".

1. I don't know why DIBSection doesn't get "MyBits" filled in.

2. I can't memcpy from MemDC(0x008F0020) to MyBits(0x00800020)
because I don't know how to use the assigned DC handle to "MemDC" in
memcpy, as the memcpy source. Sorry, if I should know, I don't. I
thought I did, but nothing worked.

3. I tried to GlobalAlloc memory with "MemDC" …

For anyone following this thread, I am giving up. I have read through loads of .h's and
other help files to no avail. I worked around using my "found and then lost" style symbol by using SetWindowPos to adjust the MDI window to the desired size. Maybe some day I'll find it again.

I looked in SWP and all the WM's and other places I could think of. Like I said, if I had not
used it in the program I am working on and seen it work, I would think there is no such thing. This is why I am so ticked at myself. I assumed I could easily get it if I needed it. You know what assuming does.

I am working with a MDI in my program. I use .cpp
to compile although I program primarily with api's.
I'm not sure whether that places me in C++ or
Windows threads. Since using .cpp I have to obey C++
rules so I'll list my thread in the C++ area. Feel
free to move my thread if you are so inclined.

I normally compile with a Borland BCC32 compiler. So
much for background.

My problem was a stupid move on my part. When
creating my MDI Client Window I came across either
a style setting or something similar that allowed me to
change the size of the Client Window.

Without that WM_,SWP_,CS_, or other, the Client Window
cannot be sized by moving the edge like the child
windows can. I deleted off that particular item assuming
I could just find it and pop it back on if I needed it.
WRONG! I can't find it anywhere. If I hadn't personally
used it, I would swear it doesn't exist.

It had to be somewhere in WIN32.HLP but I'll be dog gone
if I can find it. I did a web search but most articles
are in vb or MFC and were no help.

Can anyone tell me the the correct item I'm looking for?
I would have sworn it was SWP_RESIZABLE but I've had no
luck finding that.

I'm running AMD Xp1 compiling with Borland bcc32 with cpp
extensions.

When I minimize and then bring my window back up to normal, the
buttons in my toolbar disappear. I can bring them back up to
the top by doing a resize (mouse on edge of window with a
button down), or by opening the system menu and reclosing it.
I can also fish around at the location where the butons are
and a mouse button down will force the buttons to the top.

I've tried a SetWindowPos() with HWND_TOP and HWND_TOPMOST to
try to force the buttons to the top of the "Z" order. That
didn't work. Since the bar the buttons run on always shows, only
the buttons disappear, I'm guessing changing the "Z" order of
my toolbar window is not the answer. I think my toolbar itself
is O.K. Any ideas as to how I can keep my buttons showing?

I hope I can get an answer without sending my source code. It's
getting pretty big. I'd have to insert the whole file as a file,
otherwise I'd fill up too much thread space.

I have my toolbar code in a function and call the function
from the Create case.

case WM_CREATE:
            {
             CreateToolbar(hwndMainFrame);
             GetClientRect(hwndMainFrame, lprect); 
             InvalidateRect(hwndMainFrame,NULL,TRUE);
            }
                break;

Thanks for gettting back to me so quickly. I've downloaded the article you sent me. I'll mark the thread as solved if I am able to now pass my file as mapped.

I'm running AMD, XP Service Pack 1
Compiling with a .cpp extension using Borland Bcc32

I'm trying to teach myself how to use File Mapping.
This is just the pertinent parts of my program.

Any file can be used for lpstrFile. I'm presently using
a .txt file for testing, but I plan to put in a .bmp
once I get this working.

When I place "GetLastError" under each API, I get "The
operation completed successfully" until I get under
"ReadFile", then I get "The handle is invalid"

// -------------------------------- MAPVIEW STUFF

HANDLE MyFile;
LPVOID lpvObject;
HANDLE hMap;
HANDLE MyDataMap;
char *hData;
DWORD size;

hfile = CreateFile(lpstrFile, GENERIC_READ | GENERIC_WRITE,FILE_SHARE_READ,
        (LPSECURITY_ATTRIBUTES) NULL,OPEN_EXISTING, FILE_ATTRIBUTE_READONLY,
        (HANDLE) NULL);

size = GetFileSize(hfile,NULL);

hMap = CreateFileMapping((HANDLE)INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE,0,size,"MyView");

MyDataMap = (HANDLE)OpenFileMapping(FILE_MAP_READ,TRUE,"MyView");

hData = (char*)MapViewOfFile(hMap,FILE_MAP_ALL_ACCESS,0,0,0);

hmem6 = GlobalAlloc(GHND,size);

lpvObject = (LPVOID)GlobalLock(hmem6);

ReadFile(MyDataMap,lpvObject,size,dwRead6,(LPOVERLAPPED)NULL);

UnmapViewOfFile(hMap);
UnmapViewOfFile(MyDataMap);

MyFile = CreateFile("Map.txt", GENERIC_WRITE,FILE_SHARE_WRITE, 
         (LPSECURITY_ATTRIBUTES) NULL,CREATE_ALWAYS, 
          FILE_ATTRIBUTE_NORMAL,(HANDLE) NULL);

WriteFile(MyFile,lpvObject,size,lpNumberOfBytesWritten1,LPOVERLAPPED(NULL));

Sorry. Just found another mistake I made when posting the code. I was experimenting and left an ampersand in front of lpvBits in the ReadFile. It doesn't belong. The bits are not pointed to by lpvBits when the ampersand is there.

Sorry if this thread isn't wrapped correctly. I wrapped it as I have in the past and it went crazy.

Running AMD XP SP1 - Bitmap can be any bitmap
with a bitcount of 24. Compiling with Borland using .cpp
extentions.

I'm still having trouble getting CreateDIBitmap to
work for me. The hex bits from my bitmap are saved
in memory. I can see them.

I've read that Windows just sets lpvBits to zero
and I must fill lpvBits with the data from the
bitmap. Since memory is holding the bit information
and lpvBits appears to be pointing to it, I can't
see why CreateDIBitmap won't paint the bits to
the screen. What am I doing wrong?

Incidently, my screen is being painted black. This
tells me lpvBits is pointing to zero but I don't
know why and what to do about it.

#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <tchar.h>
#include <commctrl.h>

//***** START Prototypes

int WINAPI WinMain (HINSTANCE hInstance , HINSTANCE hPrevInstance , LPSTR lpCmdLine , int nCmdShow);
LRESULT CALLBACK MainWndProc(HWND hwndMainFrame, UINT uMsg , WPARAM wParam , LPARAM lParam);

//*******END Prototypes
//----------------------------------- GENERAL VARIABLES
   HWND hwndMainFrame;
   WPARAM wParam;
   LPARAM lParam;
   HINSTANCE hInstance;
   WNDCLASSEX wc;
   UINT uMsg;
   MSG msg;
   MSG message;
   HDC hdc;
   PAINTSTRUCT ps;
   RECT rect;
//--------------------------------- BITMAP VARIABLES

HANDLE hfile;
LPCTSTR lpstrFile = "C:\\MyPrograms\\BCC55\\bin\\D1.bmp";
//LPCTSTR lpstrFile = "C:\\MyPrograms\\BCC55\\bin\\Bitmap1.bmp";
LPDWORD dwRead1 = new DWORD;
LPDWORD dwRead2 = new DWORD;
LPDWORD dwRead3 = new DWORD;
LPVOID lpvBits;
HBITMAP hbitmap;
HDC hdcMem;
HGLOBAL hmem0;
HGLOBAL hmem1;
HGLOBAL hmem2;
HGLOBAL hmem3;
BITMAPFILEHEADER *fileHdr;
BITMAPINFOHEADER *infoHdr;
BITMAPINFO *lpbmi;
RGBQUAD …

I'm not a moderator but I do have some info that may help. You can send for a free DDK from Microsoft. It has sample code, tutorials, and a lot of good info on driver writing. You just have to pay shipping and handling. About $16.00. You better be pretty comfortable with writing code before you start though. It doesn't teach you basic stuff.

I recently sent a request for help because ReadFile
kept crashing for me. The moderator sent me some code
which cured my problem. My next step was to
experiment to see what I had originally done wrong.
(For further info see ReadFile crashes by toolmanx.)

I started by replacing each item back to the way I
had originally written it to make sure dwRead was my
only problem since the moderator's code made several
code changes to mine. dwRead was my only problem. I
initialized with several different int values
finally even using my original "0". It still worked.

The only change that caused failure was using LPDWORD
as written in Win32.HLP instead of plain DWORD. That
apparently was my mistake. I copied Win32.HLP
verbatum. My understanding, correct me if I'm wrong,
is, LPDWORD indicates to the compiler that dwRead is
a pointer, not just a variable.

The moderator had also added an "&" in front of
dwRead in the function. This tells me that I am asking
for the address of dwRead, not what is in the location of
dwRead. That made sense to me and was reinforced
because BCC32 would error if I sent a pointer in
the function without the ampersand.

My next step was to try to find out why LPDWORD wouldn't
work. The compiler would not accept
"LPDWORD dwRead = …

That did it. Thanks.

I put MyLength+1 to make sure I don't run over
my allowed memory. Doesn't that allow room for end of file?

This is one of my many attemps. I have brought down most of my
declarations so you can see them.

HANDLE hfile;           
HGLOBAL hmem;
LPDWORD dwRead = (LPDWORD)0;
LPVOID lpBuffer;
LPDWORD lpFileSizeHigh; 
DWORD Mylength;

hfile = CreateFile(lpstrFile,GENERIC_READ,
        FILE_SHARE_READ,(LPSECURITY_ATTRIBUTES)NULL, 
        OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,(HANDLE)NULL);

Mylength = GetFileSize(hfile,lpFileSizeHigh);

lpBuffer = GlobalAlloc(GPTR,Mylength);

ReadFile(hfile,lpBuffer,Mylength+1,dwRead,NULL);

I am having trouble getting ReadFile to work for me.
I am runnng an AMD with XP SP1. I compile with a .cpp
extention normally using Borland Bcc32 but I have
also compiled using cl.exe.

I declare LPVOID lpBuffer and have tried assigning
memory using malloc. I also tried GlobalAlloc. Using
GlobalAlloc, I have tried GMEM_FIXED, GPTR and GHND.

I have also tried GlobalLock with lpBuffer in the
() to reassign lpBuffer from a handle (hmem) to a
pointer as described in WIN32.HLP. All failures
crash at the same point.

My CreateFile works fine and returns a good handle.
CreateFile sucessfully loads the file location into
memory. GetLastError tells me that CreateFile worked
and my memory allocation has been successful. I also
tried a call to GetFileSize which worked fine before
calling ReadFile.

Tracking what happens in SoftIce, all is well until
the ReadFile function calls a tick count. Before the
tick count, lpBuffer "seems" to be pointing to a good
location. On return from the tick count, EBP+0x14
contains zero. This is later used as a memory
address which naturally fails.

I'm at a loss to see what I'm doing wrong. Any
ideas?

Maybe Microsoft caught their error. I got my WinHlp as part of my Windows supplied with my computer. On my machine there is one copy of some code and then an exact duplicate of the same section. It is part of the code in the above snipit. It's not a problem for me, I merely mentioned it via thread in case someone read our threads and tried to copy and use the stuff with out looking closly at it.

Since I closed my thread, I will just open this new one for a comment.

I told you I had discovered an item in WinHelp called:

"Opening and displaying a bitmap file" If you want a laugh when you get
bored, pull that up and look it over. I wonder if Microsoft ever proof reads
their stuff before posting it. Somebody hit paste twice on that one.

Prior to sending such a large block of code, I re-read the thread on
enclosing my code in code and /code. When back lighting my code
and hitting the provided button which I assumed would complete the
job, I did not back light the [] items which I had typed in. I later
deleted those since the code was in yellow blocks.
Would backlighting them and leaving them in have done the job?

For folks that are not familiar with what you want, a nice step by
step would help. One other time that I sent a small piece of code,
I did not do it right and one of the narrators said, back light the
code and hit "#". Some time has passed since then. I didn't see a "#"
button, but the tool help message read, "Wrap code tags around code"
which appeared to be what you wanted. I guess it wasn't.

Incidently, I just used the word "code" with [] and learned how to put
the yellow backing behind code. (The reason for this edit.)

It seems I stepped on your toes explaining that I got some of my
code from WinHelp. We're even. You explained to me that
CreateDIBSection creates a bitmap, not a file. My typedef for the
name I chose for my CreateDIBSection clearly reads (HBITMAP DIBFile;).
I just grabbed a name off the top of …

I have to admit I haven't mastered the method you guys want when including code. I back lit all the code and hit the button "Wrap code tags around code" found above. Last button on the right. Clue me in as to what other way to do it.

I didn't understand why you felt my code was in "C". It was written using Win32 API's in C++.

There is a Microsoft supplied item called WinHelp. In it there is about a thousand functions using the Win32 API functions. All of my functions and structures were pulled from there. I saw you placed "&bmi" in the CreateDIBSection function. That works if the structure does not have BITMAPINFO *bmp: BCC32 will let you know if you don't have the syntax right. Also, I copied the "CONST" from the WinHelp stuff. I've tried it with and without the "CONST" and still I don't get a good handle.

I haven't tried to allocate memory before calling CreateDIBSection. WinHelp gave me the impression that if I don't allocate, the system will allocate it for me. I'll give that a try tommorrow.

I almost forgot. If I use "bmi.bmiHeader.biWidth", BCC32 will fail. It will complain that bmi has already been declared. It also adds an error saying a structure must be left of a "." or a "->".

I've tried to clean down this code so that it will demonstrate my problem but
contains little else. Just enough to make a window. This code will compile on
"BCC32" or "cl". I can't figure out why I get an "Invalid handle error" when
trying to create a DIB. I'm running AMD, XP pack 1. I've included a little
snippet that will show you the returned handle. For me, it's always "0". I'm
missing some point but I can't see what.

#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <tchar.h>

    HDC hDC;
    void *ppvBits;
    HWND hwnd;
    MSG msg;
    WNDCLASS wc;
    HDC hDCDIB;

// ***********START********PROTOTYPES*****

int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow);
LRESULT WndProc(HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam);

// ***********END**********PROTOTYPES*****

   int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
    (void)UNREFERENCED_PARAMETER(hPrevInstance);
    (void)UNREFERENCED_PARAMETER(lpCmdLine);
    (void)UNREFERENCED_PARAMETER(nCmdShow);


    wc.lpfnWndProc = (WNDPROC) WndProc;
    wc.hInstance = hInstance;
    wc.hIcon = LoadIcon((HINSTANCE) NULL, IDI_APPLICATION);
    wc.hCursor = LoadCursor((HINSTANCE) NULL, IDC_ARROW);
    wc.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
    wc.lpszClassName = "DIB";

    if(!RegisterClass(&wc))
         return FALSE;

    hwnd = CreateWindowEx(NULL,wc.lpszClassName,"",WS_OVERLAPPEDWINDOW,CW_USEDEFAULT, CW_USEDEFAULT,
                        CW_USEDEFAULT, CW_USEDEFAULT,(HWND)0,(HMENU)0,hInstance,(LPVOID)0);
    if(!hwnd)
        return FALSE;
    
    ShowWindow(hwnd, SW_SHOW);
    UpdateWindow(hwnd);
     
    while(GetMessage(&msg, (HWND)0, 0, 0) > 0)
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }             

    return msg.wParam;
}                            // ********************* END WINMAIN

   LRESULT WndProc(HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam)

{                            // ********************* START WNDPROC 1

   switch(message)
      {                        // ******************* START SWITCH

    case WM_CREATE:
     {

//--------------------------------- BITMAPINFO Page 370
   CONST BITMAPINFO *bmi; 
   BITMAPINFOHEADER bmiHeader;
   RGBQUAD bmiColors[1];
//---------------------------------- BITMAPINFOHEADER Page 364
   DWORD  biSize = (sizeof(BITMAPINFOHEADER)); 
   LONG   biWidth = 340; 
   LONG   biHeight = 255; 
   WORD   biPlanes = 1; 
   WORD   biBitCount …

I don't know if I am the only one having trouble with StretchBlt
or if my symtom is a normal situation.

StrechBlt works fine as I zoom the picture larger. I expect the
pic to loose quality if I zoom out too far.

My problem is: As I zoom smaller, the picture quality drops off and
the colors start to bleed into each other. At 1/3X the pic is
unusable.

I am using COLORONCOLOR. I played around with HALFTONE but I didn't
see any improvement. I called SetBrushOrgEx with lppt set both to
the 0,0 point and NULL. Again no difference. I have to admit I don't
know all I need to know about setting SetBrushOrgEx.

My question is-- Is this normal or am I doing something wrong?

Problem solved. I learned quite a bit from the help I've gotten from this site.

thanks again.

First let me thank you for setting up my code correctly. I read the thread that
told me to put <code> at the top and bottom. I assumed that the system would handle the rest when sent. Now I know about the # sign. I would never have guessed about
the way to send a file was under advanced. I'll bet if I searched long enugh I'd find something about it somewhere on your site. When all else fails, read the directions, right?

The exact way my Borland library reads in winuser.h is:

_declspec (dllimport)HMENU _stdcall CreateMenu(void); Can I assume that yours
reads the same?

I put your suggested way into my program and I get a compile error "bypasses
initialization of a local varible in function". I then cleaned off all code
except the IsMenu block in case the stuff in format message was causing the
error. Still the same error message.

Prior to asking for help, I had read a lot on CreateMenu and tried every
way others had used that I found. I tried ::CreateMenu, CreateMenu(VOID)
which is the way Microsoft printed it in the Win32 Help, CreateMenu(void)
like it is in winuser.h. None gave me a handle. I also compiled using my
DDK compiler which has it's own library. Still no handle. I'm frustrated.

I didn't want to fill up a thread with a bunch of code, but I couldn't find a way to attach a file to an e-mail using this site's "send a message" system. I would have inserted the .CPP file.

This is a basic windows program to run tests on what started out to be two problems I had. Comrade Ogilvy solved one of them for me and my large program now is displaying the mouse position in my status bar the way I wanted. I've cleaned out all the unneeded code so only the "CreateMenu" problem code is left. I stepped through SofeIce to try to see what is happening but when SI gets to "SysEnter", if I single step through, my box blue screens. I've had that happen to me before in other programs when the program tries to step through "SysEnter". I don't know why. If you compile and run this you will get a "Get System Error" stating "The system cannot find the file specified." Why not? Isn't CreateMenu suppose to return a new handle?

#include <windows.h>
HINSTANCE hInstance;
HWND hwndMain;
HMENU hMenu;

char szBuff3[128]="TEST";                   

MSG msg;
WNDCLASS  wc;
WPARAM wParam;
LPARAM lParam;

//***** START Prototypes

int WINAPI WinMain (HINSTANCE hInstance , HINSTANCE hPrevInstance , LPSTR lpCmdLine , int nCmdShow);
LRESULT CALLBACK MainWndProc(HWND hwndMain, UINT uMsg , WPARAM wParam , LPARAM lParam);
//HMENU NewMenu(HMENU hMenu);

//*******END Prototypes

int WINAPI WinMain( HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
    
    (void)UNREFERENCED_PARAMETER(hPrevInstance);
    (void)UNREFERENCED_PARAMETER(lpCmdLine);
    (void)UNREFERENCED_PARAMETER(nCmdShow);

        wc.style = CS_VREDRAW | …

Your suggestion worked like a charm.

After seeing so many viewers looking at my thread I
thought maybe I would have to put the source code in
so people could understand what I was talking about.
Obviously not for a sharp dude, you nailed it on first
try with minimum info.

I put my little test program together because I was
having 2 problems chasing me. I didn't want to have
to plow through lots of code if I went into SoftIce
to chase them down. Since you smashed my first problem
I thought I might as well bounce my second one off
you also.

When I "CreateMenu", a handle for one does not return
as expected. I get an error message that reads:
"The system cannot find the file specified".

I usually compile using Borland BCC32 but I get the error
using "cl" from my DDK too so it's not a compiler problem.

If you don't mind and if I can find your e-mail address in
your profile, I'll shoot you the source code. You may need
it to duplicate the problem to see it. If I can't find your
addrress, e-mail me at [email removed] and I'll send you
the code.

I think I may have confused the issue based on the above reply. Instead of calling my functions "DoPaint", I should have called them "DoChaChaCha" I am doing some painting in the function but I am not doing it in the Case WM_Paint.

I am not having trouble getting the coordinates to my status bar. I am having trouble getting more than one update after the first one. This is true whether I paint the text in my temporary window or in my large program that has a status bar in it. It's not getting a second WM_MOUSEMOVE or getting it to do anything that is causing my problem.

I was trying to send mouse positions to my status bar in
a larger program. I could not get them to write more than
one position to the status bar, then it stops changing.

To test why, I wrote a small window using one "Do Paint"
function first. I still got only one position print out
but nothing more. I then put in a "Do Paint1" and "2".
The WM_MOUSEMOVE would print out either "1" or "2" but not
both. It will print both lines if I keep it all in one
function. I would like to know why it won't run two
functions, one after another.

I'm sure I'm doing something dumb but I can't come up
with why I only get one position print and why a
second WM_MOUSEMOVE message doesn't seem to do anything.
I'm assuming that as the mouse moves, the program
should get more WM_MOUSEMOVE messages. I cut off the
returns in 1, 2, and then the case. No change. I can't
figure out why MMove will only do one and not both of
my functions either. It's all got to be tied together
some how.

I'm running AMD with SP1. Here's the case.

case WM_MOUSEMOVE:


wsprintf(szBuff1,"%s x=%04d y=%04d","Cursor Location",
LOWORD(lParam),HIWORD(lParam));
wsprintf(szBuff2,"%06s %04X %s x=%04d y=%04d","Msg = ",
message,"    ",LOWORD(lParam),HIWORD(lParam));
DoPaint1(hwndMain);
DoPaint2(hwndMain);
return 0;

and here's the 1 and 2.

HWND DoPaint1(HWND hwndMain)
{
GetWindowRect(hwndMain,&rc);
hDC …

I have been using the Borland BCC32 compiler and love the CPP32 line numbering tool. Now I want to switch to the cl.exe compiler. Is there a tool like CPP32 in the Microsoft system?

Can anyone tell me what this type of command structure
is and what type program uses it? It isn't ASM and it isn't C
language as far as I can tell. Sorry guys, I'm still learning.

T=10000:
F=loader.exe:
O=securomfix_cc.exe:
P=5A12A6/75/CC: ; 0137:005A12A6 753B JNZ 005A12E3
$

For those readers who have an interest but didn't feel as though they had enough to contribute, here are some interesting sites to visit to learn more.

Wikipedea has a lot of info on SecuRom and in general, CD protection.

There are 2 sites worth looking at. CD Freaks and Alcohol forum.

Moderator, you can close this thread.

My old thread was marked as complete so I am starting a new thread on this.

Who knows a bit about Securom from Sony? I discovered my original disk is keyed with Securom. I have made a runnable copy using Alcohol 120% but I need an emulator running on my HD to use the new backup disk.

The majority of my program resides on my HD with an icon to start it. The backup disk contains an Autorun.exe which must be in place in my cr-rom drive before the icon will start the program. I would like to have all of my program on my HD and be able to start by clicking the icon. The Securom is preventing me from doing this. Therefore I am gathering information on this key system. If an emulator can read the key and allow the program to run, how does it do that? Anybody know? Am I right on my assumption that Securom places the key info on abnormal length sectors?

I've monitored the activity as the Autorun does it's thing. There is a
high number of calls to the registry. I imagine, after the time stamp checks, it compares the key with a number hidden in the registry. If I can find the "jump" call after the "compare" and I can rewrite a jump to the run position regardless of the "compare" result, I can then bypass the key altogether. The large size of the main exe is …

Alcohol helped some. It gave me the type of protection my disk has. It is Securom. I made a disk that will boot up in place of my original which is a partial help. I have to keep Alcohol active on my HD to use it's emulator in order for my new disk to boot. I really wanted to find out what key the program used so I could set up a way to run the program from an icon on my screen. As it stands now, the program is loaded and has an icon, but needs the original disk in to run the "Autorun" and load the key.

Thanks. I'll try a couple of these and see what happens.

toolmanx

I'm not sure where to put this post so feel free to move it to the most appropriate spot.

I am looking for a burner program that will do a bit to bit copy of my CD-ROM. One guy sent me a great step by step on how to run Nero to do this. The only Nero I have is ver.7 and it's newer than this step by step was derived for. It wouldn't work.

I bought a program that requires having the original CD in the drive everytime I run the program. I want to be able to run this program by clicking on an icon without constantly digging out my CD and putting it in before I can run. If my original disk ever gets scratched, I would be out all the bucks I paid for this thing, unless the company would send me a new disk to replace the old. Over time that gets less and less probable.

Even XP gives me a chance to make one copy for back up. These turkeys that put this out didn't even do that.

I had an old Makisoft source code that was supposed to read each bit and place it in memory but I've long since lost that code. For anyone interested in helping, I'm running XP 32 bit, I have the Borland C++ compiler, and I can partition my HD with enough room to run a DOS CD-ROM reader and unload the disk in …