Support even older Windows versions

[RamonUnch]

For now GreenPad works fine on:
Windows NT3.1 build 404 (oldest build I tested)
Win3.1 + Win32s 1.15a

I tested Windows 3.1 + Win32s 1.1 (build 88) and the System freezes without other errors when I try to start GreenPad,
If I delete the .ini file it gets created again, so the lockup does not happen immediately.

[RamonUnch]

Actually I just needed to define NO_ASMTHUNK and the exe works on Win3.1+Win32s 1.1
I just need to try with even older Win32s versions.

[RamonUnch]

Seems useless to support Win32s beta because it does not support codepages and WideCharToMultiByte/MultiByteToWideCharare stubs.
0047c94

[roytam1]

my build crashes with GPF in chicago build 58s:

I wonder if I completely disabling status bar will help or not.

[roytam1]

yeah kind of working now, but it seems that WC2MB and/or MB2WC is failing:

I can type something but it returns empty lines.

[RamonUnch]

Probably GetCharWidthW and TextOutW are also not supported on old Chicago builds.

[RamonUnch]

For me it was enough to set StatusBar=0 in the ini file and I got the same problem tha you.

[roytam1]

Probably GetCharWidthW and TextOutW are also not supported on old Chicago builds.

since I'm testing win32s builds not NT31 ANSI builds so this is not a problem here.

[roytam1]

for NT 340, I can make it opening Open File dialog but it looks quirk:

and Save File dialog can't be shown right now.

[roytam1]

changed dialog template font, open dialog works now:

but Save File (As) still returns LastError 6 unless I remove OFN_ENABLEHOOK flag (but this is deal breaker)

[RamonUnch]

Quite some progress indeed, congratulations!

[roytam1]

but Save File (As) still returns LastError 6 unless I remove OFN_ENABLEHOOK flag (but this is deal breaker)

for further testing, I used its SDK samples\multipad adding OFN_ENABLEHOOK for both GetOpenFilename and GetSaveFilename with a stub ofnhook function which just returns FALSE, such save hook works on later versions but not in 340.
I wonder that 340's comdlg32.dll may need some binary patching.

[RamonUnch]

How do you get status bar on NT build 340?

[RamonUnch]

Actually copying comctl32.dll from build 404 did the trick for me!

[RamonUnch]

For me on NT3.10.340, I can barely use the open dialog. After a fresh restart it displays fine, but then

1. If I do Ctrl+O then I press esc,/cancel I get insta crash.
2. When I select a file everything is OK, however later instances of GreenPad get a glitched Open dialog that aslo crashed on cancel.
   So I need a full restart. login/logout does not do it.
   Notepad does not have the problem though.

[roytam1]

2. Notepad does not have the problem though.

because notepad doesn't use common dialog templates and hooks.

[RamonUnch]

So I guess we have to drop the hook and resolve to the simple open dialog.
The codepage can be selected later via the reopen dialog.
For saving that is a bigger issue. So we should allow to change current cs even on unsaved files, so that it gets used for saving.

[roytam1]

So I guess we have to drop the hook and resolve to the simple open dialog.

it has no problem on open dialog (I can't test via hotkeys, but via menu is no problem here)

[RamonUnch]

it has no problem on open dialog (I can't test via hotkeys, but via menu is no problem here)

You are right, I just had problems because I was using "MS Shell Dlg" font, with "Helv" I get no problems.

[roytam1]

I got it finally!

NT 340's comdlg32.dll wants ofnHook returning TRUE when processing WM_INITDIALOG.

[RamonUnch]

Amazing, I will give it a try.

[RamonUnch]

According to the doc, we should return TRUE for the WM_INITDIALOG processing even (i guess) for the open dialog even though it works with return FALSE.

DOC: for OFNHookProcOldStyle

Return Values
If the hook procedure returns zero, the default dialog box procedure processes the message.
If the hook procedure returns a nonzero value, the default dialog box procedure ignores the message.
...

The default dialog box procedure processes the WM_INITDIALOG message before passing it to the hook procedure. For all other messages, the hook procedure receives the message first. Then, the return value of the hook procedure determines whether the default dialog procedure processes the message or ignores it.

For the new style dialog it is also safer to return nonzero value from WM_INITDIALOG:

If you provide a hook procedure for an Explorer-style common dialog box, the system creates a dialog box that is a child of the default dialog box. The hook procedure acts as the dialog procedure for the child dialog. This child dialog is based on the template you specified in the OPENFILENAME structure, or it is a default child dialog if no template is specified. The child dialog is created when the default dialog procedure is processing its WM_INITDIALOG message. After the child dialog processes its own WM_INITDIALOG message, the default dialog procedure moves the standard controls, if necessary, to make room for any additional controls of the child dialog. The system then sends the CDN_INITDONE notification message to the hook procedure.

So I guess this return TRUE should always apply.

[roytam1]

remaining systems:

• NT Builds < 329/340
  • since EXE format differences from later versions, there is no good way to support them
• ReactOS
  • Dynamically loading VC1-compiled DLL kills app, see https://jira.reactos.org/browse/CORE-18796, https://jira.reactos.org/browse/CORE-18797 fix approved and merged
  • CS_OWNDC redraw issues, see https://jira.reactos.org/browse/CORE-18800 (workarounded in Get rid of CS_OWNDC #67 , but still a problem in ROS itself)
  • context menu not showing when right-click in edit control, see https://jira.reactos.org/browse/CORE-18801 fix approved and merged
  • Global IME debug log spams
• Chicago Build 58s and Win32s < 1.10.88
  • WC2MB and MB2WC are stubs workarounded in 19f5103...314b989
• Win32s < 1.10.88 (cont.)
  • CreateFileMapping() fails without setting LastError workarounded in Use ReadFile for Win32s beta #69

for later two, WC2MB and MB2WC need wrappers.
for CreateFileMapping, may need to fallback to ReadFile.

1.00.61 CreateFileMappingA shows:

so it only supports CreateFileMapping() from a "-1" handle which is not our case.

[RamonUnch]

I did not test GreenPad under OS/2 warp.

It should be possible via two ways:

1. Installing Win32s under WIN-OS2
2. Using Odin

The odds are high everything works fine already but I will ll need to test this when I get a working OS/2 environment.
OS/2 came back to my memory when I heard about ArcaOS. This latter should also have a native support for Win32 programs, it seems to be a continuation of eComStation that stopped development in 2011.

[RamonUnch]

From quick testing it seems that Win32s build of GreenPad works fine on WIN-OS2+Win32s1.25a (with comctl32.dll from beta) under OS/2 Warp 4.51.

[roytam1]

2. Using Odin

my old odin install is still working.

odin can only work with ANSI versions, and it work best with my NT31-ansi version.

[RamonUnch]

Wow, that's so beautiful!
Which Windows version does Odin identifies itself as?

[roytam1]

Which Windows version does Odin identifies itself as?

XP.

[RamonUnch]

Interesting to report that since it does not support proper Unicode...

[RamonUnch]

I took a glance at ReactOS source and It seems the DC is released on ReleaseDC()/EndPaint() even when the CS_OWNDC style is specified,
the CS_OWNDC style is checked however to create a DC when calling CreateWindow which is good, I am unsure however how it is handled elsewere, But I need to check if the OWNDC version of GreenPad would work if I remove the EndPaint() and use ValidateRect() instead.

[roytam1]

I took a glance at ReactOS source and It seems the DC is released on ReleaseDC()/EndPaint() even when the CS_OWNDC style is specified,

but ros winetest doesn't show that:
https://github.com/reactos/reactos/blob/master/modules/rostests/winetests/user32/dce.c
https://jira.reactos.org/browse/CORE-18800?focusedCommentId=138102&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-138102

[RamonUnch]

Well at least if I replace BeginPaint/EndPaint with GetUpdateRegion/ValidateRect in the old greenpad, I no longer have huge problems, and the Window content can still get repainted even after minimizing/restoring a lot the window. There are still drawing problems though, but none that can't be resolved by a window resize.
Hwever I do not know if that proves anything because in the end if we remove Begin/end paint we only call GetDC() once and then never release it, so it cannot change, However I checked that if I add a call to GetDC() in the WM_PAINT handler, every call to GetDC() gives the same DC than the one that was saved in the Painter, and it is the case on both ReactOS and Server2003.
So if we never call ReleaseDC or EndPaint() it seems to go mostly fine.

[roytam1]

opening settings dialog cause a app freeze in NT 340 in my tree, does it happen in yours?

[RamonUnch]

I have no problems on NT3.10.340 with settings dialog, both using the Unicode beta build or win32s beta:

[roytam1]

ah, I just forget to pass TARGET_VER to RC, fixed my side. :)

[RamonUnch]

Windows NT 3.10.340 cannot set the text on the help dialog, is it just me?
The rest works fine...

[RamonUnch]

Forget it, it is because of big font, If I set font size back to 8 then everything is fine.
In all cases the SendDlgItemMessage() returns true and sets lasterror to 1447 (ERROR_NO_SCROLLBARS)

[roytam1]

ported changes into my nt31 tree now:

[roytam1]

more screenshots:

[RamonUnch]

That is beautiful indeed!
I also tried to run greenpad on Win32s beta 32, and it runs and kinda work. The problem is that the GetCharWidth does not work (I think). I did not invest an time into it for now.

[roytam1]

BTW I tried to dedup and correct some open/save dialog codes and logics:
roytam1/rtoss@edfb61d...b1ebfb3

[RamonUnch]

I will import your changes.
A change I made is to remove extra checks for the First if after dialog opening failed.
As soon as you have the dlgEvenOpened_ variable there is no need for any extra checks other than OFN_EXPLORER before trying again with old dialog.

[RamonUnch]

Thanks for your browsers builds btw,
I noted an issue, even with the latest IceApe-UXP build:
Sometime, after posting in a GitHub thread and reloading the page (not 100% sure on how to reproduce), The whole thread gets dplicated: ie:

Initial post:
Post1
Post2
Post3
Post1
Post2
Post3

I do have the problem right now, You can see that tin the middle of the page the whole thread repeats with my first post abiut disabling asmthubk :

Not sure if you ever experienced this issue.
I did experience it also using palefill before WebComponents were enabled in UXP

[roytam1]

Not sure if you ever experienced this issue.

didn't notice this, maybe palefill and/or MC's WebComponents/ShadowRoot implementations are not good enough for github.

[RamonUnch]

I will try to find a reproducible way to trigger it with a clean profile on NM28, and I will report on the MSFN thread. Excuse me for this off-topic tangent.

[roytam1]

so my tree builds on AXP32, buildable for AXP64 but not tested.

P.S.: no MLang support.

[RamonUnch]

Wow that is cool, MLang is not really needed when you got chardet.dll.
I guess you are not using the internal memory manager either because it ignores all alignment rules.
Should not be hard to fix though, rounding up 4bytes the allocated size should be enough I conjecture.

[roytam1]

I added a way to detect Win9x KernelEx in my tree:

related commit: roytam1/rtoss@0066039

[RamonUnch]

nice trick, indeed on Win9x the system directory is does not end with 32,
Would there not be a false positive on 64 bit windows were the System32 is for 64 bits dlls and SysWow64 is for 32 bits dlls?

[roytam1]

Would there not be a false positive on 64 bit windows were the System32 is for 64 bits dlls and SysWow64 is for 32 bits dlls?

thats why you need to call Wow64DisableWow64FsRedirection to disable WoW filesystem redirection. otherwise it always return system32 for compatibility.

[roytam1]

BTW tried on NT 3.1 Build 311, and it doesn't start.
I think its PE format may be still immature as QuickView can't see its DLL dependency. On Build 347 it works like on Build 340.

[roytam1]

just upgraded one of my win10ltsc vm to win11ltsc, and RtlGetNtVersionNumbers still works.