I have just finished converting some 16 bit programs to 32 bit. On Win 98 and ME, they load fine. But when I load them using Win XP, they take forever to load (approximately 10 seconds, which is too long for a small program to take to load). I am changing resolutions on the way in, but it takes about 10 seconds before it ever gets to the black screen. None of the other programs I run do this, just my programs.

Any ideas on what I'm doing wrong?

No real way to tell without seeing some of your code..

It's a small program, but way too much code to post and since I have no idea what's causing the program, I wouldn't know what to post anyway.

I was just wondering if anyone had any general ideas. Ideas of why it would load quick on 98 and ME, but not XP. I'm new to XP (only been using it for a while) so I don't know all the quirks yet.

I'm guessing from the lack of posts, that it's nothing real common so I'll just have to debug a little more.

Run it through a profiler or just put timer statements in between pieces of your loading code until you narrow it down.

I second the profiler suggestion. I have found that most people are aware of the importance and benefits of profilers, but few actually use profilers!

So, for those of you who are not using profilers at the moment, go on and download the AMD CodeAnalyst, a basic, simple and free profiler. An yes, it works on non-AMD processors as well.

Using a profiler isn't really necessary in this case. A few well-placed OutputDebugString() (or printf) statements should be enough to indicate just what part of the program is taking so long to startup on XP.

Yes, true, but I still think it is better to get into the habit of using a profiler. If you are used to it, it's quicker than placing those OutputDebugString()'s.

I put in code to check where the program is delaying loading and it appears to be when it is creating the main window and when it is initializing directdraw. Under Win98/Me it takes .2 seconds to create the window and another .4 seconds to initialize directdraw. Under XP, it takes 3.4 seconds to create the window and another 1.3 seconds to initialize directdraw. Here are the routines I use. Can you see any reason why this code would work under Win 98/ME but not XP?

// create main window:
HWindow = CreateWindow
(
"ProgWIN",
"Program Win",
WS_POPUPWINDOW,
CW_USEDEFAULT,
CW_USEDEFAULT,
WINWIDTH,
WINHEIGHT,
NULL,
NULL,
HInstCurrent,
NULL);
if (!HWindow) return FALSE;


if(FAILED(DirectDrawCreate(NULL, &lpDirectDrawObject, NULL)))
{LogText("DirectDrawCreateEx"); return FALSE;}
//
// set cooperative level
if(FAILED(lpDirectDrawObject->SetCooperativeLevel(hWnd, DDSCL_EXCLUSIVE|DDSCL_FULLSCREEN)))
{LogText("SetCooperativeLevel");return FALSE;}
//
// change screen resolution
if(FAILED(lpDirectDrawObject->SetDisplayMode(SCREEN_WIDTH, SCREEN_HEIGHT, COLOR_DEPTH)))
{LogText("SetDisplayMode"); return FALSE;}

If you don't see anything in the code, do you think it could be the fact that I originally wrote the code in 16 bit and then I converted it to 32 bit? I just imported the files into Visual C++ and made whatever changes it made when it came up with error messages.

You might try putting some timing checks around your handlers for WM_ERASEBKGND, WM_PAINT and WM_SIZE...just to see if something odd (and/or lengthy) is happening when you do the mode switch.

Also, have you tried this on another XP machine?
-Scorpio

IT would help to see your message handler, specially if you handle some events like erasebackground or NC_Create or the likes

apart from that i never had a problem with xp on that issue. About your 16->32 bits, I don't think it is a valid thing, but you can always try to create a new project and copy the source files in, and ignore all the other files, and do a rebuild all. It shouldn't make a difference unless your compiler is not rebuilding some files cause the .o's are there already,.

Originally posted by Akura
.o's

What do you mean by .o's?

Unlike GCC, MSVC calls them .obj, you know what they are :)

I think I might have found the problem. Just in case anyone else has this problem, here's an article I found on the Internet titled, "Glitch in Windows XP SP1 could slow systems":

http://www.nwfusion.com/news/2003/0327glitch.html

I'm still going to look at the code a little longer, but I'm not sure if it's my bug or Microsoft's.