RamonUnch
Support even older Windows versions
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.
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.
Seems useless to support Win32s beta because it does not support codepages and WideCharToMultiByte/MultiByteToWideCharare stubs. https://github.com/RamonUnch/GreenPad/commit/0047c940646b355ec7dcccf753146343931c84e7
my build crashes with GPF in chicago build 58s:
I wonder if I completely disabling status bar will help or not.
yeah kind of working now, but it seems that WC2MB and/or MB2WC is failing:
I can type something but it returns empty lines.
Probably GetCharWidthW and TextOutW are also not supported on old Chicago builds.
For me it was enough to set StatusBar=0 in the ini file and I got the same problem tha you.
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.
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.
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)
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.
For me on NT3.10.340, I can barely use the open dialog. After a fresh restart it displays fine, but then
- If I do Ctrl+O then I press esc,/cancel I get insta crash.
- 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.
2. Notepad does not have the problem though.
because notepad doesn't use common dialog templates and hooks.
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.
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)
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.
I got it finally!
NT 340's comdlg32.dll wants ofnHook returning TRUE when processing WM_INITDIALOG.
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.
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 https://github.com/RamonUnch/GreenPad/pull/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 https://github.com/RamonUnch/GreenPad/compare/19f51039...314b989d
- Win32s < 1.10.88 (cont.)
- ~~CreateFileMapping() fails without setting LastError~~ workarounded in https://github.com/RamonUnch/GreenPad/pull/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.
I did not test GreenPad under OS/2 warp.
It should be possible via two ways:
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.
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.
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.
Wow, that's so beautiful! Which Windows version does Odin identifies itself as?
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.
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