From: Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] On Behalf Of Eliot Miranda Sent: Monday, April 23, 2018 16:24 To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] Raise minimum supported Windows API from XP to Vista (was: Identify console executable and standard one)
Hi Vincent,
On Mon, Apr 23, 2018 at 4:11 PM, Vincent.Blondeau@lamresearch.com wrote:
Hi Eliot,
*From:* Vm-dev [mailto:vm-dev-bounces@lists.squeakfoundation.org] *On Behalf Of *Eliot Miranda *Sent:* Monday, April 23, 2018 13:33 *To:* Open Smalltalk Virtual Machine Development Discussion <vm-dev@lists. squeakfoundation.org> *Subject:* Re: [Vm-dev] Raise minimum supported Windows API from XP to Vista (was: Identify console executable and standard one)
Hi Alistair,
On Mon, Apr 23, 2018 at 1:06 PM, Alistair Grant akgrant0710@gmail.com
wrote:
Hi Eliot & Vincent,
On Mon, Apr 23, 2018 at 10:00:12AM -0700, Eliot Miranda wrote:
Hi Alistair,
On Apr 23, 2018, at 2:46 AM, Alistair Grant akgrant0710@gmail.com
wrote:
Hi Everyone,
I have some test code that correctly identifies whether stdin on
Windows
is a console or redirected, in both windows command terminals
(cmd.exe)
and cygwin mintty (the current code only works for cmd.exe, not for
cygwin terminals).
However it relies on the Windows Vista API, i.e. _WIN32_WINNT >=
0x0600, and at the moment we set the minimum supported version to
Windows XP (0x0501).
Since Windows XP is no longer supported, I can't see any problem with
raising the minimum version to Windows Vista (which also isn't
supported, but should give us maximum compatibility), but wanted to
check first.
Are there any objections to raising the minimum API level to Windows
Vista?
Not from me. But it would be nice if the resulting executable still
ran in Windows NT. Is that still possible? What does the code look
like?
If we make this change I think the chances of it working on NT are next
to zero.
Actually, I'd be surprised if the current VM ran on NT since it is
explicitly asking for the XP API, but I haven't tested it.
The code is available at:
fossies.org_linux_misc_vim-2D8.0.tar.bz2_vim80_src_iscygpty.c&d=DwIBaQ&c= RWI7EqL8K9lqtga8KxgfzvOYoob76EZWE0yAO85PVMQ&r= kIZIYXBAA3fhM7P5HOuTC5w6mnEApTfXPTq3lR34ZiY&m=oPgRLf_ qAaa4HRKiutXLr1xXOa8SzpEcef72bohSLbU&s=mkWFs166cLTuhJuXteRsf0YR1UetLX CU4lbr9L-ztdY&e=
fossies.org_linux_misc_vim-2D8.0.tar.bz2_vim80_src_iscygpty.h&d=DwIBaQ&c= RWI7EqL8K9lqtga8KxgfzvOYoob76EZWE0yAO85PVMQ&r= kIZIYXBAA3fhM7P5HOuTC5w6mnEApTfXPTq3lR34ZiY&m=oPgRLf_ qAaa4HRKiutXLr1xXOa8SzpEcef72bohSLbU&s=C9f7RvD0S_OxvWZFF8Md_ 6nmuANHrD3WPtoUghrAahE&e=
So if you look at lines 60 through 101 you'll see the standard technique
for getting around the version issue:
60 //#define USE_DYNFILEID
61 #ifdef USE_DYNFILEID
62 typedef BOOL (WINAPI *pfnGetFileInformationByHandleEx)(
63 HANDLE hFile,
64 FILE_INFO_BY_HANDLE_CLASS FileInformationClass,
65 LPVOID lpFileInformation,
66 DWORD dwBufferSize
67 );
68 static pfnGetFileInformationByHandleEx pGetFileInformationByHandleEx
= NULL;
69
70 # ifndef USE_FILEEXTD
71 static BOOL WINAPI stub_GetFileInformationByHandleEx(
72 HANDLE hFile,
73 FILE_INFO_BY_HANDLE_CLASS FileInformationClass,
74 LPVOID lpFileInformation,
75 DWORD dwBufferSize
76 )
77 {
78 return FALSE;
79 }
80 # endif
81
82 static void setup_fileid_api(void)
83 {
84 if (pGetFileInformationByHandleEx != NULL) {
85 return;
86 }
87 pGetFileInformationByHandleEx = (pfnGetFileInformationByHandleE x)
88 GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")),
89 "GetFileInformationByHandleEx");
90 if (pGetFileInformationByHandleEx == NULL) {
91 # ifdef USE_FILEEXTD
92 pGetFileInformationByHandleEx = GetFileInformationByHandleEx;
93 # else
94 pGetFileInformationByHandleEx =
stub_GetFileInformationByHandleEx;
95 # endif
96 }
97 }
98 #else
99 # define pGetFileInformationByHandleEx GetFileInformationByHandleEx
100 # define setup_fileid_api()
101 #endif
If USE_DYNFILEID is defined then the code searches kernel32.dll and uses
the function if found. So the safe way to write this is to follow the
approach given by USE_DYNFILEID (no need to implement setup_fileid_api; all
thats needed is the statements therefore prepended to the use of
pGetFileInformationByHandleEx). If GetFileInformationByHandleEx exists in
kernel32.dll use it, otherwise fall back on our existing code. That way we
should be able to keep the Windows XP build level. People still use it a
lot (especially students in poor countries) and I'd rather wait until we
can jump forward beyond Vista to make the change ;-) ;-) ;-)
Does that make sense? You'll see some of this code in the win32 subsystem
already; gre p GetProcAddress platforms/win32/vm/*
platforms/win32/plugins/*/*
It does make sense. But, it is not possible anymore to compile with Cygwin in this case: some structures like FILE_BASIC_INFO, FILE_INFO_BY_HANDLE_CLASS are not defined if the Windows version is before 0x0600 (see winbase.h:2641).
No problem; one simply steals the Microsoft define from the Vista header and includes it verbatim, e.g. see NOTIFYICONDATA in platforms/win32/vm/sqWin32.h.
And in the Windows 10 version of Cygwin, fileExt.h, which should contains the definitions for the XP version, is just an empty stub.
Then, should we change:
WINVER:=-D_WIN32_WINNT=0x0501 -DWINVER=0x0501
to:
WINVER:=-D_WIN32_WINNT=0x0600 -DWINVER=0x0600
In Makefile.tools, knowing that the dependencies are still compatible?
Or should be add the fileExt.h XP version in the dependencies?
No. We simply define the necessary types verbatim. Look at sqWin32.h for the pattern:
/****************************************************************************/ /* few addtional definitions for those having older include files */ /****************************************************************************/ #if (WINVER < 0x0400) && !defined(_GNU_H_WINDOWS_H) ... defines #endif
In this case we should just use #if WINVER < 0x0600, right?
Indeed!
Waiting for review now: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/254 It is working fine on Windows 10 with the debug version, with Powershell, Cygwin, and standard Launching for the explorer
Vincent
_,,,^..^,,,_ best, Eliot