IMHO they found it without my post, as the forum still shows 'under investigation'. However, glad that it's fixed now. ...but some suspiciousness remains.

Seems to be fixed with 16.5.4

Problem after Update 16.5.2 - Developer Community[^] Status is: Under investigation, but it's one problem of > 1k... @Richard MacCutchan: Thanks for testing. So, I'm not alone :-D

Yep, done so.

Same, but one element earlier. When looking to the assembly code the loop is not visible. Instead AX and XMM0 are loaded, but both from the wrong index. As the target address is szin[KEYSIZE/2], which is szin[17] the pointer to element 0 gets added by 17. This is also done for the source pointer pchar, which is wrong. 002D10F2 66 8B 45 8E mov ax,word ptr [ebp-72h] 002D10F6 0F 10 85 7E FF FF FF movups xmm0,xmmword ptr [ebp-82h] 72 and 82 are 17 bytes to less. They should be: mov ax,word ptr [ebp-83h] movups xmm0,xmmword ptr [ebp-93h]

Just sample code to show the problem, so no problem with array sizes. The code works ok when compiling in VS2013 and it worked up to VS2019 16.5.1. I made a console sample using the code and compiled it with VS2013 and VS2019. The output is different when printing the arrays. In case I switch off optimization it works ok, too.

// ConsoleApplication2.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

#define KEYSIZE 35
int _tmain(int argc, _TCHAR* argv[])
{
unsigned char szin[2 * KEYSIZE] = {"--------------------------------------------------------------------"};
unsigned char szin2[2 * KEYSIZE] = {"--------------------------------------------------------------------"};
unsigned char szarr[2 * KEYSIZE] = {"blah1blah2blah3blah4blah5blah6blah7blah8blah9blah10blah11"};
unsigned char* pchar;

pchar = &szarr[1];
for(int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
szin[i] = *(pchar++); // This worked up to now. After update it is broken
printf("Hello\r\n");
printf("%s\r\n", szin);
pchar = &szarr[2];
int jj = 0;
for(int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
{
szin2[i] = pchar[jj]; // This is my current workaround
jj++;
}
printf("%s\r\n", szin2);
return szin[jj + 3] * szin2[jj];
}

VS2013 prints: Hello -----------------lah1blah2blah3blah--------------------------------- -----------------lah1blah2blah3blah--------------------------------- This seems to be ok. VS2019 prints: Hello -----------------h4blah5blah6blah7b--------------------------------- -----------------lah1blah2blah3blah--------------------------------- Line after hello is not what to be expected. Printing indexes does not help as the code is strongly optimized by the compiler. Already adding the printf did change the assembler code produced. IMHO the compiler has a problem. ...and Debug version in VS2019 is also OK.

Hi all, This code in the first loop worked up to now:

unsigned char szin\[200\] = { 0 };
unsigned char szarr\[50\] = { "blah1blah2blah3blah4" };
unsigned char\* pchar;

pchar = &szarr\[0\];
for (int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
  szin\[i\] = \*(pchar++);  // This worked up to now. After update nothing is copied

pchar = &szarr\[2\];
int jj = 0;
for (int i = KEYSIZE / 2; i < KEYSIZE; i++)// Transfer random bytes to second half of in
{
  szin\[i\] = pchar\[jj\]; // This is my current workaround
  jj++;
}

Obviously MS changed something in the compiler, which breaks the release build. Debug still works. Any glue? Regards, Franz

My app is MFC, yes. Found out that snap functionality works only with CFrameWnd inherited windows and not with CDockablePane, as they do not have a DWM caption bar.

Why not using GPU?

I managed to get MDI tear off functionality into my app, like VS does. I placed the teared off view window to a dockable pane. Now I would like to get the Aero Snap (Dragging caption with mouse to monitor top, corners, etc.) functionality for the teared off window. Someone out there to get me into the right direction? Regards, Franz

Hi all, I've had some preview on VS2019. They implemented a new feature, which places the application menu onto the title bar. Any thaughts on how to get this in an MFC application, too? Regards, Franz

As I do only need the country where my app was started the following code does the job:

std::string get_country_code()
{

HINTERNET net = InternetOpen("IP retriever",
INTERNET_OPEN_TYPE_PRECONFIG,
NULL,
NULL,
0);

HINTERNET conn = InternetOpenUrl(net,
"http://ip-api.com/csv/?fields=countryCode",
NULL,
0,
INTERNET_FLAG_RELOAD,
0);

char buffer[12096];
DWORD read;

InternetReadFile(conn, buffer, sizeof(buffer) / sizeof(buffer[0]), &read);
InternetCloseHandle(net);

return std::string(buffer, read);
}

No, this is a normal PC without GPS. I just need the country where my app was started in order to access the right webaddress provided for the country.

spLocation->GetReportStatus(IID_ILatLongReport, &status) returns REPORT_NOT_SUPPORTED. The code is from one of the Microsoft samples.

My app is C++ based (no .net) and I need to know where on earth my app is started. This is in order to access a website (e.g. www.xyz.cn/info for china; www.xyz.com/info for the rest) with the correct region. I've tried with ILocation Com interface but it tells me that there are 'no devices detected'. Any thaughts?

Thank you all for answering. I did the VS2008 makefile way. There were a lot of new afx...cpp files to add. It did compile (and yes, it worked fine at a first glance) and I tried to go further into the replacement of some feature pack subclassed windows. Finally I've stopped as there were too many changes necessary, which might cause side effects. Just wanted to get the beautiful MDI tear off feature of newer VS. :sigh:

The reason for trying to get the hands on the MFC source are necessary changes (public vs. protected...) in the feature pack. Subclassing it not possible as the corresponding classes are already subclassed by the MFC feature pack itself. So, there's no access to the inner parts. Thanks for the response!

Yes, some years ago with an older version of MFC as there was a bug inside... Thanks for the response.

Newer versions of Visual Studio are installed without a makefile for the MFC library. As I want to change some inner parts of MFC I need to compile the library. ...but without a makefile (or solution file) this is not possible. Anybody out there which has got a working makefile for newer Visual Studios?

Regards, jung-kreidler

Changing the visual style of an application causes handle leaks. In CMFCVisualManager there exists a function UpdateSystemColors, which is called three times when the style is changed. Every call opens theme handles. Below the UpdateSystemColors is a function CleanUpThemes, which closes the theme data handles. This function is only called once when the style changes. This causes 38 handles which will not be closed afterwards. I've looked for a possibility to fix this in source code, but this needs to compile the MFC lib on my own, but there is no makefile for it... Any thoughts?