From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: cygwin@cygwin.com
Subject: Re: Using cygwin-dll with msvc-exe
Date: Tue, 30 Jun 2020 08:45:23 -0600 [thread overview]
Message-ID: <f06c42e6-f801-09e3-9fab-3b242eed4672@SystematicSw.ab.ca> (raw)
In-Reply-To: <000801d64eae$3ed3eb00$bc7bc100$@gmail.com>
On 2020-06-30 01:15, Kristian Ivarsson via Cygwin wrote:
> [snip]
>
>> They have incompatible internal startup and runtime environments including
>> stuff like initialization, signal, and exit function handling
>> (cygwin/newlib/gcc vs
>> Windows/APIs/VC) although Cygwin can build Windows-loadable dlls and
>> Windows-runnable exes and call Windows (system) dlls that don't depend on
>> msvcrt.
> What is interesting is that ldd on cygwin1.dll says it depends on
> msvcrt.dll, but that might not be a problem ?
That might not be accurate:
$ cygcheck cygwin1.dll
Found: C:\...\cygwin64\bin\cygwin1.dll
C:\...\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
> It seems like you could somehow fix it with this trick
> https://cygwin.com/faq/faq.html#faq.programming.msvs-mingw (though I don't
> really understand what difference it would make, because something seems to
> be missing in the explanation (or more probably there's something I don't
> understand;-) and it seems to be a bit cumbersome as well if you're having a
> large product with a long lifetime)
That says you could build Cygwin apps using MS VC/VS, but must first build all
libraries you use, including cygwin, as MS VC/VS compatible DLLs using gcc,
impdef, and lib, and call their routines via Windows APIs, as they duplicate
msvcrt routines. Both cygdrop and cygrunsrv do something similar:
$ cygcheck cygdrop
Found: C:\...\cygwin64\bin\cygdrop.exe
C:\...\cygwin64\bin\cygdrop.exe
C:\...\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
$ cygcheck cygrunsrv
Found: C:\...\cygwin64\bin\cygrunsrv.exe
C:\...\cygwin64\bin\cygrunsrv.exe
C:\...\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\USER32.dll
C:\Windows\system32\win32u.dll
C:\Windows\system32\GDI32.dll
Msys/2/Mingw allow Windows apps to be built by them or their Mingw Cygwin
packages, to run natively/standalone under Windows, so they can be used when
building, installing, or maintaining Cygwin, including e.g. cygcheck and setup:
$ cygcheck cygcheck
Found: C:\...\cygwin64\bin\cygcheck.exe
C:\...\cygwin64\bin\cygcheck.exe
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\PSAPI.DLL
C:\Windows\system32\USER32.dll
C:\Windows\system32\win32u.dll
C:\Windows\system32\GDI32.dll
C:\Windows\system32\WININET.dll
$ cygcheck setup-x86_64
Found: C:\...\setup-x86_64.exe
C:\...\setup-x86_64.exe
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\COMCTL32.dll
C:\Windows\system32\GDI32.dll
C:\Windows\system32\win32u.dll
C:\Windows\system32\USER32.dll
C:\Windows\system32\ole32.dll
C:\Windows\system32\combase.dll
C:\Windows\system32\bcryptPrimitives.dll
C:\Windows\system32\PSAPI.DLL
C:\Windows\system32\SHELL32.dll
C:\Windows\system32\SHLWAPI.dll
C:\Windows\system32\WININET.dll
C:\Windows\system32\WS2_32.dll
> In my honest opinion I think this disability to use cygwin-libraries from
> windows-applications kind of limits some of cygwins purpose, but I do still
> think cygwin is a great open source project ;-)
You have a choice under Cygwin of:
- using Cygwin POSIX libraries with the Cygwin Unix emulation interface,
allowing you to build and run most packages that run under Unix, without system
(e.g. BSD, Darwin/MacOSX, or Linux) dependencies, including Cygwin/X to build
and run X Window packages, or else
- using Mingw packages and utilities with the Windows APIs.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
prev parent reply other threads:[~2020-06-30 14:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 9:31 sten.kristian.ivarsson
2020-06-26 17:13 ` Andrey Repin
2020-06-30 7:19 ` Sv: " sten.kristian.ivarsson
2020-06-26 17:32 ` Brian Inglis
2020-06-30 7:15 ` Sv: " sten.kristian.ivarsson
2020-06-30 14:45 ` Brian Inglis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f06c42e6-f801-09e3-9fab-3b242eed4672@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).