C / C++ / MFC

Member 150124920-Apr-17 21:14

Member 1501249

20-Apr-17 21:14

It is even more complicated: if I put the above mentioned tests into one project, it behaves different in comparison to three separated test projects!
This behaviour let me think of some kind of memory corruption (stack?), but I can't pinpoint until now how this can occur in a trivial test application.

leon de boer22-Apr-17 19:17

22-Apr-17 19:17

I would say the WM_SETFONT call is working the reason the last digits are not displaying is because it doesn't have enough room in the box. That is the default behaviour to drop the last word that doesn't fit in the area. Try making the box just a fraction wider or reduce the font size. It's highlighting another issue that the font is coming out slightly different size to before but that is probably not surprising. You could try the height in pixels as a minus sign that tells windows not to round the value to best value but make the value absolute. I don't know what details the original MFC used to select the font but you could look up the code section.

LOGFONT structure (Windows)[^]
< 0 = The font mapper transforms this value into device units and matches its absolute value against the character height of the available fonts.

In vino veritas

Member 150124927-Apr-17 23:01

Member 1501249

27-Apr-17 23:01

Sorry, this doesn't solve the problem.
On different Windows 10 creator update PC's, we get different results, all of them are incorrect.

leon de boer28-Apr-17 14:57

28-Apr-17 14:57

If that doesn't work MS have a problem because that is a documented API call nothing to do with frameworks etc .. just log it with them as a bug and they will have to fix. It should get a reasonably high priority especially since it is easy to replicate.

In vino veritas

Member 150124913-Jun-17 23:06

Member 1501249

13-Jun-17 23:06

The problem is solved in Microsoft's update of June.

Michael E. Jones20-Apr-17 1:02

Michael E. Jones

20-Apr-17 1:02

Hi,

I can confirm the problem. Seem to be the Windows Creators Update... Two days ago one of our applications was displaying the date correctly and now it is only displaying a few random pixels. The same application run on a system that has not been updated works as expected. Using the, byte-for-byte, same executable - nothing to do with MFC or changes in the RTL.

EDIT: Adding a manifest with "Microsoft.Windows.Common-Controls" does improve things (apart from the fact that all controls look different, which might be a problem for the odd application) - Microsoft has definitely changed some visual behaviour...

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
	<assemblyIdentity version="1.0.0.0"	processorArchitecture="X86" name="XYZ, ABC" type="win32" /> 
	<description>ABC</description> 
	<dependency> 
		<dependentAssembly> 
			<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /> 
		</dependentAssembly> 
	</dependency> 
	<dependency> 
		<dependentAssembly> 
      <assemblyIdentity type="win32" name='Microsoft.Windows.GdiPlus' version='1.1.0.0' processorArchitecture='X86' publicKeyToken='6595b64144ccf1df' language='*' />
		</dependentAssembly> 
	</dependency> 
</assembly>

cu,
Michael

modified 20-Apr-17 7:37am.

leon de boer20-Apr-17 7:42

20-Apr-17 7:42

Yes but the API itself behaves correctly it's just frameworks that are breaking and that is fine it is just a framework support issue. The problem now is MFC is no longer a direct Microsoft support framework they have released the sourcecode as it reached end of it's commercial life. It will be interesting to see if they fix it or just tell us we have the sourcecode and we need to go and fix it ... really it isn't their problem anymore and they can wipe there hands of it.

Wonder if it's broken on .NET or WPF I will have to go and have a look later today, their response may differ depending on that.

In vino veritas

Richard MacCutchan20-Apr-17 22:34

See My (previously working) DateTimePickers have gone nuts! - .NET Framework Discussion Boards[^].

20-Apr-17 22:34

leon de boer wrote:
Wonder if it's broken on .NET

JamesA_Dev25-Apr-17 4:34

JamesA_Dev

25-Apr-17 4:34

I think there's a typo and the 2nd one should be "*" rather than "'*'" ?

Thanks, it's not feasible to replace old software on all customer sites.

Adding the manifest file and setting the reg key below to make it be used gives us an option in case Microsoft decide not to fix it.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
PreferExternalManifest
1

UrbanBlues4-May-17 9:37

UrbanBlues

4-May-17 9:37

Hello

I faced the same problem .. I decided to go to 64 bits Unicode (with a lot of work to migrate to Unicode)

and add the following lines to stdafx.h

#ifdef _UNICODE
#if defined _M_IX86
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
#elif defined _M_X64
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='amd64' publicKeyToken='6595b64144ccf1df' language='*'\"")
#else
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
#endif
#endif

It works perfectly. The 'new' is smarter and with a cleaner look ... It was finally worth the work

Thierry
www.tgmdev.be

JamesA_Dev25-Apr-17 21:58

JamesA_Dev

25-Apr-17 21:58

Can anyone else getting this problem please go to Microsoft Connect number 3129203 and vote it up.

Setting compiler name in win32.mak

JamesA_Dev13-Jun-17 23:02

JamesA_Dev

13-Jun-17 23:02

Fixed

June 13th Cumulative Update - kb4022725

ForNow16-Apr-17 11:20

ForNow

16-Apr-17 11:20

Hi
I don't know if this the right place for this i.e. meaning C/C++ Microsoft specific

but I am trying to use the INTEL C/C++ compiler instead of Microsoft

so in win32.mak

I replaced cc = cl with cc = icpc

I checked the PATH

but I still got this error on the makefile build

1>icpc : error #10236: File not found: 'icpc'

Re: Setting compiler name in win32.mak

Richard MacCutchan16-Apr-17 21:33

Re: Setting compiler name in win32.mak

16-Apr-17 21:33

Standard error message. Whatever "icpc" is it does not exist in any of the directories in your PATH environment variable, or Makefile macros.

ForNow19-Apr-17 5:28

ForNow

19-Apr-17 5:28

Richard

I was looking at benchmarks and it seems for native x86 calls ( non windows services ) the intel compiler produces better code I think the intel compiler on a windows machine though is icl.exe for win32.make I guess as you said it has to be in the path

Help

Member 1302311816-Apr-17 3:13

16-Apr-17 3:13

I'am a bigenner in cyptology. It's really an interested domain. I have started in cryptography by modifyiong the round function of xtea and by modifying the p-layer of PRESENT. I find it sample but when I will do differential and linear cryptanalysis on them it becomes more difficult because I didn't find a sample example to understand more the principle. Can anyone help me with code c of differential cryptanalysis of PRESENT and XTEA. I will be grateful for you

Richard MacCutchan16-Apr-17 3:46

16-Apr-17 3:46

Member 13023118 wrote:
code c of differential cryptanalysis of PRESENT and XTEA

That is a good question for Google, or Search[^] the CodeProject articles.

Member 1302311816-Apr-17 4:00

16-Apr-17 4:00

I have searched in different sites but I didn't find any code that can help me

Richard MacCutchan16-Apr-17 4:06

16-Apr-17 4:06

Then maybe no one has yet written any.

leon de boer16-Apr-17 4:30

16-Apr-17 4:30

You didn't look very hard the C code is right there in wikipedia (XTEA - Wikipedia[^])

#include <stdint.h>

/* take 64 bits of data in v[0] and v[1] and 128 bits of key[0] - key[3] */

void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
    unsigned int i;
    uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9;
    for (i=0; i < num_rounds; i++) {
        v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
        sum += delta;
        v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
    }
    v[0]=v0; v[1]=v1;
}

void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
    unsigned int i;
    uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds;
    for (i=0; i < num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

The C implementation for PRESENT you can get here in 8, 16 or 32 bit ... PRESENT Encryption

In vino veritas

modified 16-Apr-17 10:36am.

Member 1302311816-Apr-17 4:38

16-Apr-17 4:38

Thanks alot for your help but I have already got it and I also modify xtea round function to become more secure but my problem now is to understand the principle of differential cryptanalysis that's why I need code c of of differential cryptanalysis in both of algorithms xtea and PRESENT

leon de boer16-Apr-17 5:50

16-Apr-17 5:50

Okay I am just a boring old programmer you got me intrigued how do you produce code for the differential it would be incredibly long given the statistical spread of the output. I know for example AES is immune to any sort of differential attack if you look at the algorithm you can see why. I can tell you from practical doing it, that it's easier to just brute force attack these things.

That is why I suggest the code doesn't exist Smile | :)

If you want to find out how secure your modification is time the bruteforce attack on it.

In vino veritas

Member 1302311816-Apr-17 5:56

16-Apr-17 5:56

That is why I suggest the code doesn't exist

leon de boer16-Apr-17 6:01