Re the MessageBox example that you took from here: Of course, if a language pack is not installed on your system, it won't display the text; but it launches the exe, apparently.
Evening Jochen,
Yes, it does launch the
Окносообщения.exe module but only because the Russian codepages are installed under my XP Sp3 Pro Rus and the system PE loader can make out the module file name's characters and tell them from a string of control characters of unknown origin and/or intent. Had the file been called
您可以将中文文本传递到应用程序。.exe, whatever that means, the PE loader would report file corruption with unpredictable consequences to the integrity of the system.
(I wouldn't allow it to even attempt lauching your sample in this case though.)Tell you more, file name corruption was widely popular as an exploit for the creation of unkillable bootable USB stick virii some half a decade ago or so. The virus would create a hidden
System Volume Information folder (which is nothing unusual for Vista+ platforms) but with spaces denoted by unpermissible characters
on a USB stick that never saw anything better than an XP! The spaces would make the "folder" undeletable and, moreover, unkillable even with the system's standard deep formatting! The system would just mark those USB sectors as bad but wouldn't delete the actual data written in them. So, the virus would then go dormant till the user decided to burn or copy a bootable ISO image onto their CD/DVD drive or USB stick/disk, in which case the virus would create a jump to the "bad" sectors from the stick's or disk's MBR (master boot record). The system being started from such an infected ISO image is yet unaware of any bad sectors in its data storage devices when it's still in the first 512 bytes of its MBR, so it would obediently jump over there to execute whatever the virus had to offer in its "
System Volume Information" sectors.
Moreover, Ubuntu that's installed on one of my multi-bootable disks with shared folders would use its standard screen capture utility to save its screenshots under unique PNG names but in a
YYYY:MM:DD:HH:MM:SS.PNG format with literal colons in it! The other Windows systems installed on the same physical disk wouldn't quite naturally accept those files as valid images but, what's the worst thing of all, they wouldn't allow me to rename, move or even delete them either! Bravo Linux and Linuxoids! You're halfway there to creating yet another virus on my Windows PC!
I tested your Resize.exe example, it works but the fan starts howling immediately, and one core is at 100%, even if I do nothing. Besides, it doesn't take other pictures when I drag them over the exe, it always shows auto.jpg, so I can't test it with the Chinese images. Is that desired behaviour?
The desired behavior of this sample is to show off the real speed with which the library is able to perform anti-aliased transformations, rather than what damage can be done to the OS file system with compromised image file names and time stamps that meddle with the NTFS security layout.
100% on just one core out of four wouldn't do any harm to your laptop and is only 25% of the total, after all. As you can see from the code, only the following lines are responsible for rendering while all the rest is just Windows standard app launching/benchmarking stuff:
(pseudocode!) Case WM_PAINT ' render sprites
Render(BeginPaint(ME, PS))
SpBack.ClearBuffer(cb)
SpTemp.LoadFromSprite(SpOrig, TrNone, Mx, My)
SpBack.Draw(SpTemp, 0, 0)
SpBack.PaintToDevice(hDC) ' copy to window
EndPaint(ME, PS)
InvalidateRect(ME, NULL, TRUE) ' !!! THIS IMMEDIATELY INVALIDATES WHAT'S JUST BEEN PAINTED TO INITIATE NEXT RENDER WITHOUT ANY DELAYS TO COOL OFF YOUR CPU/GPU/WHATEVER !!!
That's a standard procedure for GDI benchmarking and that's effectively also how DirectX and OpenGL would operate when your GPU is set to favor speed over quality (no VSYNC-ing et al.)
Now open up your ImageViewAndRotate, drag some (Chinese) photo onto it, maximize the window and keep on pressing your R key for awhile only to see your CPU rise up to 25% and your fans go humming again. So, is your viewer in fact any better than mine?
Now that raises an interesting question: When you launch ImageViewAndRotate.exe in a folder with ? ? ?.jpg images, do you see the content of these images? I understand that the window titles don't display properly, but GetFiles and the Files$() array should work ...
No, the content of these images is never shown in either your viewer or my authentic ACDSee Photo Editor I used to pay a damned lot of hard cash for.
(I thought you'd be able to read its blue window messages since you seem to be so fond of Russian sample stuff... 
) It says it couldn't find the respective image files and that they probably had been moved or deleted before it could decode them etc., except of course for my avatar that it obediently shows in its preview.
