A question about platforms

[chazste]

@davepl I have another idea to shave a few bytes from tiny original by deleting a function call. But after a little thought I realized that the change would most likely keep the program from running correctly on anything prior to Windows Vista, but it definitely works fine on Windows 10 (and presumably 11, though I can't test that easily). So since I suspected it was broken on older versions of Windows I reached out my left hand and turned on my Win2k laptop (yes I am one of THOSE people). So as is TinyOriginal.exe does not run on Win2k at all. It exits when the call to CreateWindowEx fails. This is true on Windows XP as well.

So my question is would you prefer the fix for Win2k, or a slightly smaller TinyOriginal that runs correctly on Win 10? Specifically the proposed change would be to not call GetClientRect and use the rcPaint from the paint struct. This depends on DWM and the compositor which is why I believed it would render incorrectly on Windows versions prior to Vista. (Or is it 7, I never used Vista)

As an aside while investigating the behavior on Win2k I actually read the docs for WNDCLASSEXA and discovered that COLOR_3DSHADOW is not a valid HBRUSH to pass to RegisterClassEx. It does seem to work but its not in the contract 😃

[chazste]

The other interesting (to me anyway) platform would be Wine. On Ubuntu 22.04/Wine 6.0 the compositor is not quite as good and there are some drawing artifacts. So I guess my vote would be to fix the bug to allow the application to execute older versions of Windows (and test on at least Windows 98 since I have a laptop with that installed (even if it is hiding at the moment).

[davepl]

Thanks! If I had to make up a rule, and I guess we do, I’d prefer it worked on all 32-bit Windows. From Win95 and NT 3.51 on forward. But if that’s not possible because of crinkler or something else beyond our control, then Win7 is fine with me. I’d rather be a few bytes fatter and not have to make excuses. The point was to do everything the right way, but still be small :-) I’ll set up Win2K so I can maybe debug it, unless you have a hunch as to why CreateWindowEx fails. Cheers, Dave

…

On Mar 4, 2023, at 6:21 PM, Charles Stevens ***@***.***> wrote: @davepl <https://github.com/davepl> I have another idea to shave a few bytes from tiny original by deleting a function call. But after a little thought I realized that the change would most likely keep the program from running correctly on anything prior to Windows Vista, but it definitely works fine on Windows 10 (and presumably 11, though I can't test that easily). So since I suspected it was broken on older versions of Windows I reached out my left hand and turned on my Win2k laptop (yes I am one of THOSE people). So as is TinyOriginal.exe does not run on Win2k at all. It exits when the call to CreateWindowEx fails. This is true on Windows XP as well. So my question is would you prefer the fix for Win2k, or a slightly smaller TinyOriginal that runs correctly on Win 10? Specifically the proposed change would be to not call GetClientRect and use the rcPaint from the paint struct. This depends on DWM and the compositor which is why I believed it would render incorrectly on Windows versions prior to Vista. (Or is it 7, I never used Vista) As an aside while investigating the behavior on Win2k I actually read the docs for WNDCLASSEXA <https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-wndclassexa> and discovered that COLOR_3DSHADOW is not a valid HBRUSH to pass to RegisterClassEx. It does seem to work but its not in the contract 😃 — Reply to this email directly, view it on GitHub <#29>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF2UBBFVDEDBCSS3JN3W2P2BDANCNFSM6AAAAAAVP4GHJE>. You are receiving this because you were mentioned.

[rbergen]

I'm glad Dave already answered this, because I would have said we're good as long as things work on supported versions of Windows. And that boils down to all versions of Windows 10 and Windows 11, at the moment. But, as I'm not in any position to overrule Dave, his answer stands. :)

[chazste]

@davepl Sorry I did debug it on WinXP and Win2k. The root cause is that hSmIcon is not initialized so the garbage stack value is not NULL, an ATOM or a handle to an Icon. I would guess that someone optimized the path we are on where we are using a system icon to not bother looking at the small icon. Actually fixing the bug does not (necessarily) increase the size of the exe. I propose switching to an initial memset() (obviously the intrinsic version using rep stosb) and then not setting any of the zero value elements. I'll dig out my Win98 laptop and test on that too before I submit a patch.

[chazste]

Windows 98, back when fill in the blank and error messages told you what was wrong 😄 "The e:\TINY.EXE file is improperly linked with alignment less than 0x1000. Fix the error, and then link it again."
I guess Windows 98 does not want to play our game.

[davepl]

Win98 isn't real Windows anyway :-). Except the shell part. If you’re amenable, can you fix it for XP and 2K? Or open an issue and assign it to me… but you likely know more about this issue than I do by now! Cheers, Dave

…

On Mar 5, 2023, at 6:52 PM, Charles Stevens ***@***.***> wrote: Windows 98, back when and error messages told you what was wrong 😄 "The e:\TINY.EXE file is improperly linked with alignment less than 0x1000. Fix the error, and then link it again." I guess Windows 98 does not want to play our game. — Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3CE2XOUDXT6JRBXS3W2VGPJANCNFSM6AAAAAAVP4GHJE>. You are receiving this because you were mentioned.

[chazste]

@davepl
Issue created. Though it does not look like I can assign it unless I am missing something. Hopefully I will create the PR tonight.

[rbergen]

I've assigned the issue to @davepl.