Hi!


I've recently started to make some programs with the windows API using C++.
The problem I'm having right now is that I've created an application, and now I want to share it with the world (or at least some selected few). I've coded the program on my laptop win 7 32b and PC win 7 64 bit and on those computers the program works fine.

So I tried to start it on another computer running Windows XP SP3 and the only thing that happens is a console window is flashing for less than a second telling me "There is not enough memory for this application".

The icon that I added to the application doesn't show either. I googled a bit and some sites said that my program would need some DLL files that ships with Visual studio.
So I tried to make an installer for my program using visual studio but when I try to use that installer on any other computer it gives me this error message:
"This installation package could not be opened. Contact the application vendor to verify that this is a valid windows installer package" I translated it from swedish so the message on english might not be the same.

Now my questions are.
1. Why does my program not work? Could it be some code in my program that I use that WinXP Doesn't support?
2. If the only solution is to create an installer which installs the correct DLLs, how would I create one that actually works?

Sorry for long text and probably some bad english.
Thanks for reading
Kerp

There are several issues you have to take care at least about:
1. You cannot run code compiled for 64 bit OS on a 32 bit OS. You have to build a binary for each platform you want your program to run on.
2. When using API-s (even those from Microsoft) you have to read the compatibility notes in the documentation (use #ifdef to guard platform specific code)
3. Supply all nonstandard Dll-s used by your program in the installation, or link your program statically.

Thanks for your answers, however I've ran into another rather strange problem.

If I copy my program to C:\ or C:\Program Files(x86) or some other folder, the program will only work partially.
But if I copy my program to the desktop, or run it directly from the release folder create by Visual Studio, it works as it should.

Does it matter if I need administrator access to copy the files to the location or not?
I have administrator privileges on this computer but I don't know how it would affect my program. (Or if it would in fact affect my program at all)

The thing that doesn't work is this, when my main window is created I initialize all my windows that I'm going to use, but I hide the ones that shouldn't be visible on the start screen. On the start screen buttons are displayed with different options. When the user clicks a button a dialog window is shown and ask the user for some data and when the user clicks "Ok" the "start" buttons that was shown before should hide and the other buttons, editboxes, listboxes etc should be shown.

To show and hide all the different windows I use the function ShowWindow(Window, SW_HIDE) and ShowWindow(Window, SW_SHOW)

The problem is that when it's copied to C:\ for example the application only hides the "start" buttons, it doesn't show the other buttons.

I tried to link my program statically, (setting the Multithreaded option on Properties - C/C++ - Code Generation - Runtime Library)

however it did not fix the problems I had when starting my application on a windows XP SP3 PC. (I'm guessing I'm using some functions that is not supported by XP or something like that.)

As for compiling for 32/64b I am compiling on a 64b operating system but I compile with "Win32" set and the program works fine on my laptop running Windows7 32b.

Thanks

It may be worth installing Oracle VirtualBox and create a new Virtual Machine that runs Windows XP SP3.
Once Windows XP SP3 is installed, create a snapshot for you to easily revert back to.

On this virtual machine you can now debug in 2 ways.
1: Install visual studio and use it to debug your source code
2: Use the remote debugger. The way to set this up is a little more complex and you will have to include code that delays the start of your application so that you have time to hook the process before it crashes.


Personally I would do option 1. If it works, then it's something to do with Visual Studio (maybe it is using a library you aren't aware of that VS installs). In that case I would then move onto option 2.

Thanks for the suggestion, I will try that.

Anyone have any idea why my installer that I created with visual studio behaves like it does? (Refer to first post)
I just kinda expected it to work since I followed the walk through on MSDN step by step.

I could guess...But it might do more harm than good ^^

Ok, I did as you suggested Ketsuekiame and installed Oracle VM Virtualbox and used that to install Windows XP SP3. I then installed visual studio 2010 ultimate and copied over my project.

With Visual Studio installed the program now starts as it should but nothing else is working. I called getlasterror() after the program tried to create my buttons using the default class "Button", the error code returned from GetLastError() was 1411(Class does not exist) and thats very strange in my opinion since I'm using a system class. I googled a bit and I can't find any info about microsoft changing their system class names.

Isn't the class called CButton?

I don't know about that, using "Button" has worked fine for me. I changed it on both my Win7 and Win XP and neither worked. Though the error code changed from 1411(Class does not exist) to 1407(Cannot find window class). Which sounds almost the same to me :/

Sorry I don't use WinAPI, I've only had experience with MFC. It stands to reason that the class wouldn't work when I think about it ^^

Ok, just to clarify.
I'm using CreateWindow() to create a button like this:

CreateWindow("Button", "New", WS_CHILD | WS_VISIBLE, 140, 100, 250, 50, MainWindow, HMENU(BUTTON_NEW), GetModuleHandle(NULL), 0);

And on Win7 everything works fine, but on WinXP I get the error 1411(Class does not exist)

Double post :S

Did you register your Button class first? The first parameter of CreateWindow is the class name of the window you wish to create (in this case it's a button).

You must first call RegisterClass with a valid WNDCLASS structure to register your button class.

Note: A class defined in code such as class CButton { /* stuff */ }; is not the same as a registered windows class, which must be registered using a WNDCLASS structure. Also, you might want to switch to using the "-Ex" versions such as RegisterClassEx and CreateWindowEx and WNDCLASSEX. Not necessary but I thought I'd throw it out there. ;)

(I apologise if you already know all this, I don't mean to patronise but I'm unaware of how much you know so I find it safer to cover all bases just in case ^^)

I know the difference between a C++ class and a registered window class, the problem as far as I know is this.

"Button" along with for instance "Edit", "Listbox" and "Static" are predefined system classes as shown here in the remarks section.

That's why I'm a little confused to why my XP installation won't recognize those classes as I haven't found anything indicating that they have changed since win XP.

Maybe it's case sensitive on XP. Try it in full caps.

(I'm running out of things to think of now :P)

Me too, unfortunately it didn't make any difference.

I found out the solution after a couple of hours googling on different search terms :/

The problem was that I was using a .manifest.exe file to enable common controls in my program, which would enable the use of WinXP theme (this meaning prettier buttons).

If you want to use that on WinXP you have to make a call to InitCommonControls(); otherwise CreateWindow() and CreateWindowEx will fail when passing a system class as argument they will return NULL and GetLastError() will return error code 1411 (CLASS_DOES_NOT_EXIST).

I just thought I post it here if anyone else encounter the same problem as me.

Special thanks to Ketsuekiame for trying to help me.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.