|
The problem is solved in Microsoft's update of June.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Can anyone else getting this problem please go to Microsoft Connect number 3129203 and vote it up.
|
|
|
|
|
Fixed
June 13th Cumulative Update - kb4022725
|
|
|
|
|
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'
|
|
|
|
|
Standard error message. Whatever "icpc" is it does not exist in any of the directories in your PATH environment variable, or Makefile macros.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Member 13023118 wrote: code c of differential cryptanalysis of PRESENT and XTEA That is a good question for Google, or Search[^] the CodeProject articles.
|
|
|
|
|
I have searched in different sites but I didn't find any code that can help me
|
|
|
|
|
Then maybe no one has yet written any.
|
|
|
|
|
You didn't look very hard the C code is right there in wikipedia (XTEA - Wikipedia[^])
#include <stdint.h>
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.
|
|
|
|
|
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
|
|
|
|
|
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
If you want to find out how secure your modification is time the bruteforce attack on it.
In vino veritas
|
|
|
|
|
That is why I suggest the code doesn't exist
|
|
|
|
|
Have you tried brute forcing that cipher it's interesting, I just tried a small block
In vino veritas
|
|
|
|
|
Dear Sir/Madam,
Could you please send me the source code for 3D room on openGL
|
|
|
|
|
No, because it does not exist. You have to write code, you don't just ask for it from somebody. It's like asking someone to send you the plans to make a house. Well, how many bedrooms do you want? How many bathrooms? What size garage? 1 story or 2 story? What colors do you want? Etc, etc.
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
|
Look in the articles at this site, particularly in OpenGL section. I think there are a few that are about exactly what you are asking for.
|
|
|
|
|
What is GUID parameter in WinBioOpenSession() ?
|
|
|
|