locked
WINVER woes.

    Question

  • Can someone explain to me exactly what the constant WINVER does for me? Words of one syllable would be good.

    I mean, presumably I can define  WINVER=xxx  in my code and the compiler should stop me using anything which came in after Windows xxx?  Then later I can up my base platform by compiling with a later WINVER.

    Is that it?

    [Setting WINVER to XP (0x0501) causes me problems with incompatibility of Themes headers (one of which has comments indicating that it is obsolete after XP).   I don't include that particular header explicitly, and if I have a later value of WINVER it doesn't get used and all is well.  So VS2010 is doing something deep there somewhere.  But I'm starting to think that this isn't the issue.]

    My new VS2010 app is still crashing when I try to open a file or create a new one, when I run it on Vista, and my suspicions are focusing on my WINVER (which is 0x0601).    I have homed in a little on where it is happening: somewhere within CWinAppEx::OpenDocumentFile() after CMyDocument::OnOpenDocument() has successfully done its stuff.

    Browsing the MFC source code, I come to the point where stuff is added to the recent files menu.  And functions around there - like CWinApp::AddToRecentFileList() but also many others - are peppered with a spaghetti bowl of statements involving

    #if( WINVER<0x0601 )
      <do this>
    #else
     <do that>
    #endif

    Now the WINVER is 0x0601, so it looks like using that on a Vista system (0x0600) might be bad news.   This looks like an area to explore.

    But hang on a mo, this isn't my WINVER, this is the WINVER compiled in the MFC DLLs!    So is there any point in my changing it in my EXE and my DLLs? And if this is the root of the problem, can I conclude that no application done with VS2010 using the MFC framework (and in particular an MRU menu) can work on Vista or XP?

    (My app works on Vista, if I right click the exe and set it to run compatibly with XP.)

    Any ideas or enlightenment would be very gratefully received, while I work out how to do remote debugging.

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Monday, July 26, 2010 8:00 PM

All replies

  • If a smart person like David Webber, with many years of experience developing in MFC, cannot figure this out, what hope is there for the rest of us?
     
    But (just guessing), with respect to the MFC source code, since VS2010 is supposed to support XP (but not Win2K), don't you think it must be compiled with WINVER=0x0501?
     
    Maybe these branches are for some future time when Visual Studio will not support XP, and XP need not force a lowest common denominator on the compilation?
     

    David Wilkinson | Visual C++ MVP
    Monday, July 26, 2010 8:33 PM
  • My new VS2010 app is still crashing when I try to open a file or create a new one, when I run it on Vista, and my suspicions are focusing on my WINVER (which is 0x0601). 

    David,

    I'm confused as to why you're having difficulty pinning this down
    precisely. Have you managed to debug your code on the platform where
    it's having the problem?

    Does it run fine on the system where you're developing the code?

    I have homed in a little on where it is happening: somewhere within CWinAppEx::OpenDocumentFile() after CMyDocument::OnOpenDocument() has successfully done its stuff.

    Do you have the call stack?

    What's the nature of the crash - an access violation or something
    else?

    Dave

    Monday, July 26, 2010 9:51 PM
  • "David Lowndes [MVP]" wrote in message news:d344589e-0d29-4337-8a7f-e7c63df111e9@communitybridge.codeplex.com...

    My new VS2010 app is still crashing when I try to open a file or create a new one, when I run it on Vista, and my suspicions are focusing on my WINVER (which is 0x0601).

    David,

    I'm confused as to why you're having difficulty pinning this down
    precisely.

    I got distracted by other problems, and a saxophone engagement at the weekend.

    Have you managed to debug your code on the platform where
    it's having the problem?

    Not yet, I am about to try to learn how to do remote debugging, (following your kind advice earlier), but I thought I'd figure out roughly where to look first, and then I found all these WINVER-dependent branches.

    Does it run fine on the system where you're developing the code?

    Yes.  (Win7 64 bit system).  It's fine on that - no sign of any problems.

    I have homed in a little on where it is happening: somewhere within CWinAppEx::OpenDocumentFile() after CMyDocument::OnOpenDocument() has successfully done its stuff.

    Do you have the call stack?

    Not yet - so far it's a couple of message boxes spanning where the crash happens.  Primitive,  but a start.

    What's the nature of the crash - an access violation or something

    I think it's an access violation: the app just goes semi transparent, and I get a message box I haven't seen before complaining that something in windows is being interfered with.  But so far I'm just running a release version of the code on the 32bit Vista system.

    I was sort of hoping it was something obvious in my code, but it seems to be deep in MFC somewhere around where the file name is added to the MRU menu, and when I looked there I found all these WINVER branches and started wondering what they were for

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Monday, July 26, 2010 10:55 PM
  •  "davewilk [MVP]" wrote in message news:cb4aa50a-11d9-424a-ab53-f29fa41a1196@communitybridge.codeplex.com...

    If a smart person like David Webber, with many years of experience developing in MFC, cannot figure this out, what hope is there for the rest of us?

    It isn't rocket science.  Which is at the heart of my problem - I can do rocket science :-)

    But (just guessing), with respect to the MFC source code, since VS2010 is supposed to support XP (but not Win2K), don't you think it must be compiled with WINVER=0x0501?

    Sounds good to me.   I'd understand if it were.

    Maybe these branches are for some future time when Visual Studio will not support XP, and XP need not force a lowest common denominator on the compilation?

    That explanation would also make good sense but...

    ..the MFC stdafx.h reads

    #include <winsdkver.h>
    #undef _WIN32_WINNT
    #define _WIN32_WINNT _WIN32_WINNT_MAXVER
    #include <sdkddkver.h>

    and that means (eventually in the maze of #ifdefs)  it has WINVER = #0601.

    Following the debug code on the system where it all works, it takes the WINVER>=0x0601 branches confirming this.   These branches occur in

    void CWinApp::AddToRecentFileList(LPCTSTR lpszPathName)
    void CRecentFileList::Add()

    including many overloads of the latter.   Because WINVER is 0x0601,  I have no idea why these branches have been left in the MFC code.  So I'm confused.

    But I've also just this minute noticed, the CRecentFileList::Add() overloads also have an interesting-looking run-time switch - typically something like:

    if (!afxGlobalData.bIsWindows7)
    {
     Add(lpszPathName);
     return;
    }

    which is one possible reason why it may behave differently on different systems.

    Looks like I'm going to have to debug it on a pre win7 system :-(    But I'm rather apprehensive about what on earth I can do about it when I find the offending lines of code.  But I suppose there must be some reason why this is hitting me and not every other MDI app which saves files.

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Monday, July 26, 2010 11:06 PM
  • Have you managed to debug your code on the platform where
    it's having the problem?

    Not yet, I am about to try to learn how to do remote debugging

    I'd make that your #1 priority - you'll get there quicker in the end.

    Dave

    Tuesday, July 27, 2010 7:07 AM
  • Following the debug code on the system where it all works, it takes the WINVER>=0x0601 branches confirming this. These branches occur in
     
    void CWinApp::AddToRecentFileList(LPCTSTR lpszPathName)
    void CRecentFileList::Add()
     
    including many overloads of the latter. Because WINVER is 0x0601, I have no idea why these branches have been left in the MFC code. So I'm confused.
     
    But I've also just this minute noticed, the CRecentFileList::Add() overloads also have an interesting-looking run-time switch - typically something like:
     
    if (!afxGlobalData.bIsWindows7)
    {
     Add(lpszPathName);
     return;
    }
     
    which is one possible reason why it may behave differently on different systems.
    So it seeems that the WINVER tests in the MFC source code are redundant (though harmless) because MFC is always compiled with the latest WINVER, and that the way MFC avoids using later API's on earlier systems is through runtime checks.
     
    Some thoughts:
     
    1. You say you are having trouble (different troubes) using either WINVER = (0x0501) or (0x0601). But what about (0x0600)?
     
    2. Do these things happen if you create a new MFC project, or do you think they are happening because you have upgraded a project from VS2008 (which was upgraded from VS2005 (which was upgraded from VS2003 (which was upgraded from VC6...)))?
     

    David Wilkinson | Visual C++ MVP
    Tuesday, July 27, 2010 3:36 PM
  • "davewilk [MVP]" wrote in message news:a339848c-a12e-4a8a-82a7-0ca44bcb82b8@communitybridge.codeplex.com...

    So it seeems that the WINVER tests in the MFC source code are redundant (though harmless) because MFC is always compiled with the latest WINVER, and that the way MFC avoids using later API's on earlier systems is through runtime checks.

    Maybe :-)

    Some thoughts:

    1. You say you are having trouble (different troubes) using either WINVER = (0x0501) or (0x0601). But what about (0x0600)?

    This was on, but has just fallen off, my to-do list, as I am currently convinced that the crash is happening from deep within MFC and it is MFC's response to different operating systems which is the key.   (I think 0x0600 would be ok as the problem I was getting in my code when I set 0x0501 was to do with the fact that all the visual styles headers seem to have changed from XP->Vista, but I don't think it has anything to do with my problem.)

    2. Do these things happen if you create a new MFC project, or do you think they are happening because you have upgraded a project from VS2008 (which was upgraded from VS2005 (which was upgraded from VS2003 (which was upgraded from VC6...)))?

    A very pertinent question!

    First I did the latter (and you can continue the upgrades back a bit: Mozart 1 was 16bit compiled with Borland C++.   Mozart 2 was specifically recreated with 16bit MFC specifically to use the automatic upgrade tool to create a 32bit program - in 1995!   I'm not sure it was even called Visual Studio back then!  Since then I've upgraded through lots of versions, and Mr Gates has become rich.)

    Anyway, this failed to run completely on a machine without VS2010.   I suspected it was something to do with the manifest stuff I carefully crafted so the VS2008 version would run as a sand-alone app with MFC and CRT in its own directory.   But tinkering didn't fix it, and what with the long sequence of upgrades, I felt it was time to have a new project. [Fortunately the CView hasn't changed much and most of my music functionality happens within there, so that was fairly straightforward to import.]   But the infrastructure has changed a lot with CWinAppEx, replacing CWinApp and all the feature pack toolbars and menus and so on. It is this new app (heavily edited to import my functionality) which is crashing somewhere around where commands are added to the MRU list. (Under Vista, unless I set the exe to run in compatibility mode with XP.)

    [I have had a frustrating day today failing to get remote debugging working. I answered more questions about firewalls than the Spanish Inquisition had, signed my life away by saying yes to everything and sharing everything I could think of, and all it is saying at the moment is "Access denied". Access to what, by what, denied by what is not exactly clear, but that's what you expect with the Spanish Inquisition.  Still tomorrow is another day - and August is another month :-(  ]

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Tuesday, July 27, 2010 8:01 PM
  • >[I have had a frustrating day today failing to get remote debugging working.

    You're not trying to use the default (secure) transport communication
    option are you? That's always painful in my experience.

    On the other hand, the native only (no authentication) transport mode
    is relatively pain free.

    Dave

    Tuesday, July 27, 2010 9:22 PM
  • 2. Do these things happen if you create a new MFC project, or do you think they are happening because you have upgraded a project from VS2008 (which was upgraded from VS2005 (which was upgraded from VS2003 (which was upgraded from VC6...)))?
    A very pertinent question!
     
    First I did the latter (and you can continue the upgrades back a bit: Mozart 1 was 16bit compiled with Borland C++. Mozart 2 was specifically recreated with 16bit MFC specifically to use the automatic upgrade tool to create a 32bit program - in 1995! I'm not sure it was even called Visual Studio back then! Since then I've upgraded through lots of versions, and Mr Gates has become rich.)
     
    Anyway, this failed to run completely on a machine without VS2010. I suspected it was something to do with the manifest stuff I carefully crafted so the VS2008 version would run as a sand-alone app with MFC and CRT in its own directory. But tinkering didn't fix it, and what with the long sequence of upgrades, I felt it was time to have a new project. [Fortunately the CView hasn't changed much and most of my music functionality happens within there, so that was fairly straightforward to import.] But the infrastructure has changed a lot with CWinAppEx, replacing CWinApp and all the feature pack toolbars and menus and so on. It is this new app (heavily edited to import my functionality) which is crashing somewhere around where commands are added to the MRU list. (Under Vista, unless I set the exe to run in compatibility mode with XP.)
    I meant if you just create a new MFC project of the appropriate type and do not add any code to it.
     

    David Wilkinson | Visual C++ MVP
    Tuesday, July 27, 2010 11:46 PM
  • Regarding remote debugging, if I may suggest a tutorial video I did:  http://msd n.microsoft.com/en-us/visualc/bb608713.aspx
     
    -- David
     

    Efficiently access this forum with newsreaders like WLM, Thunderbird, and Forte Agent: http://communitybridge.codeplex.com
    Wednesday, July 28, 2010 1:34 AM
  •  "David Lowndes [MVP]" wrote in message news:a01f88d3-a4ba-4d39-a79e-208d766ab5e2@communitybridge.codeplex.com...

    [I have had a frustrating day today failing to get remote debugging working.

    You're not trying to use the default (secure) transport communication
    option are you? That's always painful in my experience.

    I don't know - possibly.   I don't think I did anything which is not "default".

    I put the debug build on the remote machine.
    I shared the folder in which I put it.

    I shared the folder on my local VS2010 machine which contains msvsmon.exe. And on the remote machine I told the firewall to let msvcsmon do what it likes.

    On the remote machine: I opened msvsmon over the network and ran it.

    I set up remote debugging in the VS2010 project on the local machine, and ran it.   It asked me all sorts of questions to which I replied "Yes go ahead and do that"  and it finished with "Unable to start debugging. Access is denied."

    And that's where I am now.  It knows if I forget to run msvsmon on the remote machine, so obviously it knows something about what is going on there.   But if it is running, access is denied.

    I thought that was what the instructions told me to do but it obviously isn't that simple.

    On the other hand, the native only (no authentication) transport mode
    is relatively pain free.

    Thanks, I'll see if I can work out whether I did that, and if not how to do that!

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Wednesday, July 28, 2010 10:25 AM
  •  "davewilk [MVP]" wrote in message news:a5793e5d-f0df-4387-9241-905160949441@communitybridge.codeplex.com...

    I meant if you just create a new MFC project of the appropriate type and do not add any code to it.

    Yes, and I now have the answer to that question - it works!

    This is infuriating.

    I have also compiled the full program on a lap top running XP.  (I didn't want to as it's quite an old machine and, as I suspected, VS2010 runs like treacle flowing uphill.)   But (eventually) the full program runs fine.

    Summary:

    Full program:
       a - runs fine on Win7 machine with VS2010
       b - runs fine on XP machine with VS2010
       c - crashes on Vista machine without VS2010
       d - runs fine on Vista machine without VS2010 if
             it is set to run in compatibility mode with XP

    App wizard program of same type with no added code:
       A - runs fine on everything.

    There must be a clue there somewhere!   Should I now be suspecting the drawing code? (The latter program obviously doesn't draw anything in the document window.)  But then the crash seems to happen before it can process any WM_PAINT messages.

    I was starting to suspect it might be a deployment problem.    The deployment on the Vista machine simply puts mfc100u.dll msvcr100.dll and msvcp100.dll in the same folder as the executable.   But that works fine with the vanilla program.    Dependency walker tells me some low level DLLs are missing  (IESHIMS.DLL and GPSVC.DLL) and one has missing exports (IEFRAME.DLL) but it tells me that on all the machines whether program runs or not (with the most 'errors' on the original VS2010 machine), and so I don't think it is relevant.

    I think WINVER must be a red herring - put into my mind by (d) above -  but it must be something obvious!

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Wednesday, July 28, 2010 10:25 AM
  • David Webber wrote:

    I set up remote debugging in the VS2010 project on the local machine,  and ran it. It asked me all sorts of questions to which I
    replied "Yes go ahead and do that" and it finished with "Unable to  start debugging. Access is denied."

    Set up the monitor this way:

    http://msdn.microsoft.com/en-us/library/ms164723.aspx


    Igor Tandetnik

    Wednesday, July 28, 2010 12:41 PM
  • You're not trying to use the default (secure) transport communication
    option are you? That's always painful in my experience.

    I don't know - possibly.   I don't think I did anything which is not "default".

    In that case you probably were using the (hard to configure your
    systems to communicate) secure transport option.

    I put the debug build on the remote machine.
    I shared the folder in which I put it.

    Not sure why you shared that - it's not necessary for debugging.

    I shared the folder on my local VS2010 machine which contains msvsmon.exe. And on the remote machine I told the firewall to let msvcsmon do what it likes.
    On the remote machine: I opened msvsmon over the network and ran it.

    OK, you need to alter the settings of that to use the native
    (unsecured) transport too.

    I set up remote debugging in the VS2010 project on the local machine, and ran it.   It asked me all sorts of questions to which I replied "Yes go ahead and do that"  and it finished with "Unable to start debugging. Access is denied."

    You need to set the options for debugging to the location on the
    remote machine & to use the native (unsecured) transport.

    The easiest thing to check if debugging will work is to use the Attach
    to Process option in VS. Once you get to see the list of processes on
    your remote machine you're mostly home and dry.

    Dave

    Wednesday, July 28, 2010 12:50 PM
  • "David Ching [MVP]" wrote in message news:3aee8097-c41a-4f70-b7b6-90dc038b0cd4@communitybridge.codeplex.com...

    Regarding remote debugging, if I may suggest a tutorial video I did: http://msd n.microsoft.com/en-us/visualc/bb608713.aspx <http://msdn.microsoft.com/en-us/visualc/bb608713.aspx>

    David, you're genius: that is absolutely crystal clear to anyone like me, who has never tried this before!

    It tells me exactly where to make the settings (in msvsmon) which David L suggested, and almost everything I have to do in the VS2010 project properties.

    On the debugging page of my application project properties, I have by default.

    Working Directory:  $(ProjectDir)
    This is the directory containing the vcxproj file and source code for the main program (but not the sln file which is in the parent directory).
    When I try to run it expands the directory name and tells me it is "not a valid working directory".

    I notice yours was blank.
    But if I leave Working Directory blank, then I get
    "Cannot launch the debugger.  RemoteDebuggerWorkingDirectory is missing or empty"

    Third try:
    Working Directory:  $(SolutionDir)

    and bingo - I'm remotely debugging!    [The remote computer's in another room, but hey, I have to get exercise somehow.]

    Thank you and thanks to David L and David Wi  (and Igor).

    If it weren't for our Prime Minister, I'd conclude that people called David are a really helpful, intelligent bunch of guys :-)

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Wednesday, July 28, 2010 1:32 PM
  • "David Lowndes [MVP]" wrote in message news:f778ae03-5caf-4c4c-9bfa-7a502d046efe@communitybridge.codeplex.com...

    You're not trying to use the default (secure) transport communication
    option are you? That's always painful in my experience.

    I don't know - possibly.   I don't think I did anything which is not "default".

    In that case you probably were using the (hard to configure your
    systems to communicate) secure transport option.

    Yes - I was but it's all fixed now - see answer to David C who provided the expanded version of your advice "for dummies" on video :-)
     >> I put the debug build on the remote machine.

    I shared the folder in which I put it.

    Not sure why you shared that - it's not necessary for debugging.

    Well, because it seemed to me logical that the local machine would need access to the remote folder so it could run the program.   (And that it wouldn't do any harm.)

    I shared the folder on my local VS2010 machine which contains msvsmon.exe. And on the remote machine I told the firewall to let msvcsmon do what it likes.
    On the remote machine: I opened msvsmon over the network and ran it.

    OK, you need to alter the settings of that to use the native
    (unsecured) transport too.

    Yes - that did the trick.   Thanks.

    I think I now know where the crash is happening.   As usual, not where I guessed!  I have a 'magnification' toolbar (one of the new fancy CMFCToolBar's) with an edit control on it showing a 'percentage magnification' next to the zoom-in and zoom-out buttons.    When a new CView opens, it is supposed to update itself to show the magnification in the new window.   For some reason it is updating itself and the whole program into oblivion.  Heaven knows why it didn't do that when I set the release version to run compatibly with XP, or why it doesn't do it on a machine with VS2010 installed.   There is an access violation, but it's happening at a function call which looks very innocent.

    So I haven't solved the problem yet - but I am a happy bunny because I have MASTERED REMOTE DEBUGGING!   (Albeit with a ____ of a lot of help.)

    So thanks everyone - these groups are the coolest thing since sliced cucumber.

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Wednesday, July 28, 2010 1:45 PM
  • On Wed, 28 Jul 2010 13:45:43 +0000, David Webber wrote:

    So thanks everyone - these groups are the coolest thing since sliced cucumber.

    and nearly as good as the NNTP groups they replaced!

    Steve


    Neural Planner Software Ltd                  www.NPSL1.com
    EasyNN-plus. Neural Networks plus.           www.easynn.com
    SwingNN.     Forecast with Neural Networks.  www.swingnn.com
    JustNN.      Just Neural Networks.           www.justnn.com


    npsl1
    Wednesday, July 28, 2010 1:52 PM
  • So thanks everyone - these groups are the coolest thing since sliced cucumber.

    and nearly as good as the NNTP groups they replaced!

    ... now that we've got the community NNTP bridge. Several wouldn't be
    here otherwise.

    Dave

    Wednesday, July 28, 2010 2:21 PM
  • "David Lowndes [MVP]" wrote in message news:61005109-4b90-4d4b-ad31-68aa1edb645d@communitybridge.codeplex.com...

    So thanks everyone - these groups are the coolest thing since sliced cucumber.

    and nearly as good as the NNTP groups they replaced!

    ... now that we've got the community NNTP bridge. Several wouldn't be
    here otherwise.

    I was speaking inclusively of the old NNTP groups.    But more precisely:

    The old groups were the coolest thing since sliced cucumber;
    This forum is the second coolest thing since sliced cucumber, although it would be significantly more tepid than the first coolest thing if it weren't for Jochen's bridge.

    So thanks Jochen.  :-)

    Dave


    David Webber
    Mozart Music Software
    http://www.mozart.co.uk
    For discussion and support see
    http://www.mozart.co.uk/mozartists/mailinglist.htm


    David Webber Author of Mozart music notation software http://www.mozart.co.uk
    Wednesday, July 28, 2010 7:41 PM
  • Glad you got it working, David!  The empty remote debugger working directory might have defaulted differently in VS2008.  Thanks for the update on how to make it work.  I agree about the "David's".  :-)
     
    -- David
     
     
    It tells me exactly where to make the settings (in msvsmon) which David L suggested, and almost everything I have to do in the VS2010 project properties.

    Thank you and thanks to David L and David Wi  (and Igor).

    If it weren't for our Prime Minister, I'd conclude that people called David are a really helpful, intelligent bunch of guys :-)


    Efficiently access this forum with newsreaders like WLM, Thunderbird, and Forte Agent: http://communitybridge.codeplex.com
    Wednesday, July 28, 2010 11:07 PM
  • Back to WINVER whats it for ?

    the DLLs are compiled for Vista/Win7 so if your EXE is built for XP there is a mismatch.

    The MFC dll code includes run time checks to try and mitigate this - hopefully that is OK on XP

    HOWEVER the same binary will NOT reliably run on Vista/Win7 because the run time checks see Vista/Win7 (and the MFC code is not good enough!)

    The 'only' way round this is to set XP compatiblity mode!

    For example

    BOOL AFX_GLOBAL_DATA::GetNonClientMetrics (NONCLIENTMETRICS& info)
    {
        struct AFX_OLDNONCLIENTMETRICS
        {
            UINT    cbSize;
            int     iBorderWidth;
            int     iScrollWidth;
            int     iScrollHeight;
            int     iCaptionWidth;
            int     iCaptionHeight;
            LOGFONT lfCaptionFont;
            int     iSmCaptionWidth;
            int     iSmCaptionHeight;
            LOGFONT lfSmCaptionFont;
            int     iMenuWidth;
            int     iMenuHeight;
            LOGFONT lfMenuFont;
            LOGFONT lfStatusFont;
            LOGFONT lfMessageFont;
        };

        const UINT cbProperSize = (_AfxGetComCtlVersion() < MAKELONG(1, 6))
            ? sizeof(AFX_OLDNONCLIENTMETRICS) : sizeof(NONCLIENTMETRICS);

        info.cbSize = cbProperSize;

        return ::SystemParametersInfo(SPI_GETNONCLIENTMETRICS, cbProperSize, &info, 0);
    }
    Since the MFC Dll is built with WINVER=601 AFX_OLD is smaller than NONCLIENTMETRICS (by an int) but if you are building your EXE with WINVER set for XP the struct passed in is ALSO smaller however info.cdSize will be set to the larger value - so ::SystemParametersInfo writes into this extra (unallocted) int.

    How many other variations of this problem there are I do not know but since various structures vary in size between XP and Vista/Win7 there must be a few!

    As far as I can see MFC from VS2010 (and 2008) do not (properly) support building a single binary that will run on XP and Vista/Win7 unless you are willing to mark it as NOT Vista/Win7 compatible!

    At the moment the only option I can see is to build for Win7 and 'catch' all the oddities if your running on XP!

    (or rebuild MFC and distribute that as SXS!)

    Hopefully I've missed something

    Patrick

     

     

    Tuesday, September 07, 2010 12:23 PM