[Vm-dev] Raise minimum supported Windows API from XP to Vista (was: Identify console executable and standard one)

Tue Apr 24 00:39:19 UTC 2018

From: Vm-dev [mailto:vm-dev-bounces at lists.squeakfoundation.org] On Behalf Of Eliot Miranda
Sent: Monday, April 23, 2018 16:24
To: Open Smalltalk Virtual Machine Development Discussion <vm-dev at 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 at lamresearch.com> wrote:

>
>
> Hi Eliot,
>
>
>
> *From:* Vm-dev [mailto:vm-dev-bounces at lists.squeakfoundation.org] *On
> Behalf Of *Eliot Miranda
> *Sent:* Monday, April 23, 2018 13:33
> *To:* Open Smalltalk Virtual Machine Development Discussion <vm-dev at 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 at 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 at 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:
>
> >
>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> 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=
>
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180424/b032c99f/attachment-0001.html>