On 3/16/2017 5:37 PM, David Grayson wrote:
> It's important to understand that MSYS2 supports running two different
> types of programs.
>
> 1) Native Windows programs that are compiled with a MinGW compiler,
> use msvcrt.dll as their libc, and do not have access to all features
> of POSIX.
>
> 2) Programs the use the msys-2.0.dll POSIX emulation layer.
>
> Most people want to be compiling native Windows programs because they
> want to distribute their programs to end users outside of MSYS2. It
> looks like you've already figured out what toolchain to install to
> compile a native Windows program and I would not recommend switching
> with the information you have provided.
>
> MinTTY does not actually make a Windows Console, so native Windows
> windows programs don't recognize that they are talking to a TTY when
> they use MinGW's isatty function (which basically just calls
> Microsoft's version of that function). This is why programs like
> "irb" can be pretty hard to use in MSYS2.
>
> Mihael Konev has been submitting patches to the mingw-w64 in an
> attempt to get isatty to work the way that you would expect, and
> return true in MinTTY. Here is the latest version of his patch on the
> mingw-w64 mailing list:
>
> https://sourceforge.net/p/mingw-w64/mailman/message/35589741/
>
> It's not clear if the mingw-w64 project will accept this patch. If
> you want a version of isatty that works properly for you today, you
> might consider just using the code from that patch in your program,
> without modifying mingw-w64.
>
> --David Grayson
>
Thank you for the explanation. I've been trying to find the answer for a
couple of days.
I tried the isatty you referenced, had to change from cygwin- to
const wchar_t expect_dev[] = L"\\Device\\NamedPipe\\msys-";
That does work on mintty, however it now fails for cmd|tcc.
Throwing in a few printfs, I see that
status = pNtQueryObject((HANDLE)h_fd, ObjectNameInformation,
ntfn, ntfn_size, &ntfn_size);
is returning in ntfn->Name.Buffer:
\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image
File Execution Options
I really know next to nothing about the windows API, so this would be a
show stopper for me.
You mentioned that you would not recommend switching toolchains which
implies there is one that would link against the msys-2.0.dll. Could you
briefly (I don't want to take up your time one this) elaborate on that.
As far as my use, yes, my purpose is to be able to compile native
windows programs without having to distribute either the cygwin dll or
the msys dll. It has been working fine -- I've only now run into the
isatty issue.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Msys2-users mailing list
Msys2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/msys2-users
