4

I have a 32bit program which I am trying to run on a 64bit computer. I'm running the vssadmin command to get the restore point info and saving it to a text file. Now, it works fine on my 32bit computer and I was testing it on my friend's 64 bit computer and it doesn't work.

If I use system() from within a 32bit application running on a 64 bit system, will it use a 32bit command prompt? That's the only thing I can think that would stop it working as I have manually run the command from a command prompt and it works fine.

If this is the case? Is there anyway to force it to use the right command prompt?

  • never use system(), use CreateProcess() – Jona Mar 21 '13 at 16:10
  • @JonathanD Rightio, I'm changing to using createprocess() but I'm having trouble converting my string to LPWSTR. I've found some code that is supposed to do that but it's not. right now I'm trying `std::wstring widestr = std::wstring(vsscommand.begin(), vsscommand.end()); wchar_t* widecstr = widestr.c_str();` but I'm getting `Error 2 error C2440: 'initializing' : cannot convert from 'const wchar_t *' to 'wchar_t *'` –  Mar 21 '13 at 17:00
  • u dont have to convert an std::wstring to wchar. the error you get is because you convert a constant to a nonconstant, thats impossible since its constant :D – Jona Mar 21 '13 at 17:13

2 Answers2

10

In both Linux and Windows [and I beleive BSD/MacOS too], 32-bit applications can start a 64-bit process using the relevant "create a new process" system call [which system() does some several layers down inside the shell that it starts].

The only restriction is that a 32-bit executable file can't use a 64-bit shared library (.so or .dll) or vice versa. But a new process starts by loading a new executable and at that point the process can be 32- or 64-bit based on the executable file itself.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • Is this true even if the 32-bit process is trying to start the 64-bit process to debug it (on Windows)? It seems CreateProcessW fails ("The request is not supported") when called from a 32-bit to launch a 64-bit process with DEBUG_ONLY_THIS_PROCESS. The other way around it works. – Adrian McCarthy Feb 21 '19 at 00:03
  • @AdrianMcCarthy: Can't say, as I haven't programmed/used Windows for more than reading email in the past 5-6 years and never tried that particular thing (all my machines run Linux both at home and work - at work I have a VM for accessing mail), but it's not unreasonable that a 64-bit process can't be debugged from a 32-bit process - it would at least require the API for debugging in general to be majorly changed to support all the relevant register information and state of the process - and the "read process memory" and "write process memory" would have to support 64-bit addresses too. – Mats Petersson Feb 22 '19 at 07:07
1

You should always avoid using system() because

  • It is resource heavy
  • It defeats security -- you don't know if it's a valid command or does the same thing on every system( see Mats Petersson answer), you could even start up programs you didn't intend to start up. The danger is that when you directly execute a program, it gets the same privileges as your program -- meaning that if, for example, you are running as system administrator then the malicious program you just inadvertently executed is also running as system administrator. If that doesn't scare you silly, check your pulse.
  • Anti virus programs hate it, your program could get flagged as a virus.

you should use CreateProcess().

You can use Createprocess() to just start up an .exe and creating a new process for it. The application will run independent from the calling application.

here's an example i used in one of my projects:

VOID startup(LPCTSTR lpApplicationName)
{
   // additional information
   STARTUPINFO si;     
   PROCESS_INFORMATION pi;

   // set the size of the structures
   ZeroMemory( &si, sizeof(si) );
   si.cb = sizeof(si);
   ZeroMemory( &pi, sizeof(pi) );

  // start the program up
  CreateProcess( lpApplicationName,   // the path
    argv[1],        // Command line
    NULL,           // Process handle not inheritable
    NULL,           // Thread handle not inheritable
    FALSE,          // Set handle inheritance to FALSE
    0,              // No creation flags
    NULL,           // Use parent's environment block
    NULL,           // Use parent's starting directory 
    &si,            // Pointer to STARTUPINFO structure
    &pi )           // Pointer to PROCESS_INFORMATION structure
    ) 
    // Close process and thread handles. 
    CloseHandle( pi.hProcess );
    CloseHandle( pi.hThread );
}

NOTE: as i said earlier, system() does not do the same on different machines, Mats Petersson explained why

Jona
  • 1,747
  • 2
  • 16
  • 22
  • 1
    Cheers matey. I'll look into that a bit more. Definitely seems better than using system(), considering it's already misbehaving for me. –  Mar 21 '13 at 17:57
  • Has it answered my question though? My question was how to run a 64bit process from a 32bit process, not "why shouldn't I use system()?" –  Mar 25 '13 at 22:59
  • Have you try'd running a 64bit process using my code? As i said system() does not work the same on every system. – Jona Mar 26 '13 at 14:28
  • I haven't got a 64bit system to test it on with me now but I will try it –  Mar 27 '13 at 16:35
  • 2
    I can't be bothered with this createprocess() it's a pain in the arse and it's not worth the trouble for what I need it for. Sick of converting strings and wstrings and LCPSTR's and LCPWSTR's and all the other damn things. I need to call C:\\Windows\\System32\\cmd.exe as opposed to letting it do it's default as it will no doubt use the 32bit one when running from a 32bit app on a 64bit system. I then have a std::string that I need to pass in but converting it to something it will even understand is just too much hassle –  Mar 29 '13 at 23:00
  • 1
    IF you find createprocess() hard you should def read some more c++ books – Jona Mar 30 '13 at 21:42
  • Probably but I don't have time –  Mar 31 '13 at 21:17
  • `CreateProcessA` will save you the trouble of converting strings. – Owen Jan 09 '17 at 16:01