Re: [PATCH 0/3] FAQ api, programming, timezone, setup patches
On 2020-08-25 05:04, Corinna Vinschen wrote: > Hi Brian, > > On Aug 24 14:10, Brian Inglis wrote: >> winsup/doc/faq-api.xml,faq-programming.xml: change Win32 to Windows > > Didn't we agree on WinAPI? Windows is fine when used in the context of > the OS, but Win32 was mainly used to denote the API. So "Windows API" > or, better, WinAPI, should be used in these places. Sorry, forgot to add API in a few places - Windows API seemed to fit better in most contexts than WinAPI which seemed too buzzword-like in those contexts. PATCH v2 series sent! -- 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.]
[PATCH v2 3/3] winsup/doc/faq-api.xml(faq.api.timezone): explain time zone updates
based on material from t...@iana.org mailing list sources --- winsup/doc/faq-api.xml | 29 + 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/winsup/doc/faq-api.xml b/winsup/doc/faq-api.xml index 829e4d7febd8..365e301555a5 100644 --- a/winsup/doc/faq-api.xml +++ b/winsup/doc/faq-api.xml @@ -385,13 +385,34 @@ Cygwin version number details, check out the -Why isn't timezone set correctly? +Why isn't time zone set correctly? -(Please note: This section has not yet been updated for the latest net release.) - -Did you explicitly call tzset() before checking the value of timezone? +Did you explicitly call tzset() before checking the value of time zone? If not, you must do so. +Time zone settings are updated by changes to the tzdata package included in all +Cygwin installations. +Have you run the Cygwin Setup program recently to update at least the +tzdata +package to include the latest current daylight saving (summer time) rules +for dates of changes, hour offsets from UTC of time zones, and the +geographic regions to which those rules and offsets apply. + +These changes are decided on by politicians, and announced +by government officials, sometimes with short or no notice, so +tzdata +package updates are released at least a few, and sometimes several, +times a year. +As details of changes are not known until they are announced publicly by +officials, often in foreign languages, and those details then have to be +noticed, possibly translated, passed to, and picked up by the official +tzdata +source package maintainers, subsequently released in an update to the +tzdata +source package, and then those changes have to be picked up on and applied +to the Cygwin +tzdata +package, which has to be updated, built, tested, and released publicly. -- 2.28.0
[PATCH v2 0/3] FAQ setup, using, programming, api, timezone, patches
FAQ updates from suggestions made in various posts Brian Inglis (3): winsup/doc/faq-setup.xml,faq-using.xml: update setup FAQ winsup/doc/faq-api.xml,-programming.xml: change Win32 to Windows or Windows API winsup/doc/faq-api.xml(faq.api.timezone): explain time zone updates winsup/doc/faq-api.xml | 39 -- winsup/doc/faq-programming.xml | 20 +-- winsup/doc/faq-setup.xml | 229 +++-- winsup/doc/faq-using.xml | 27 ++-- 4 files changed, 158 insertions(+), 157 deletions(-) -- 2.28.0
[PATCH v2 2/3] winsup/doc/faq-api.xml, -programming.xml: change Win32 to Windows/API
--- winsup/doc/faq-api.xml | 10 +- winsup/doc/faq-programming.xml | 20 ++-- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/winsup/doc/faq-api.xml b/winsup/doc/faq-api.xml index 313f15d37c4d..829e4d7febd8 100644 --- a/winsup/doc/faq-api.xml +++ b/winsup/doc/faq-api.xml @@ -18,7 +18,7 @@ Windows into the C library. Then your apps should (ideally) run on POSIX systems (Unix/Linux) and Windows with no changes at the source level. The C library is in a DLL, which makes basic applications quite small. -And it allows relatively easy upgrades to the Win32/POSIX translation +And it allows relatively easy upgrades to the Windows/POSIX translation layer, providing that DLL changes stay backward-compatible. For a good overview of Cygwin, you may want to read the Cygwin @@ -140,7 +140,7 @@ spawn family of calls if possible. Here's how it works: Parent initializes a space in the Cygwin process table for child. -Parent creates child suspended using Win32 CreateProcess call, giving +Parent creates child suspended using Windows CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child's @@ -326,7 +326,7 @@ name under the API. E.g., the POSIX select system call can wait on a standard file handles and handles to sockets. The select call in Winsock can only wait on sockets. Because of this, the Cygwin dll does a lot of nasty stuff behind -the scenes, trying to persuade various Winsock/Win32 functions to do what +the scenes, trying to persuade various Winsock/Windows functions to do what a Unix select would do. If you are porting an application which already uses Winsock, then @@ -337,11 +337,11 @@ direct calls to Winsock functions. If you use Cygwin, use the POSIX API. -I don't want Unix sockets, how do I use normal Win32 winsock? +I don't want Unix sockets, how do I use normal Windows winsock? You don't. Look for the Mingw-w64 project to port applications using -native Win32/Winsock functions. Cross compilers packages to build Mingw-w64 +native Windows API/Winsock functions. Cross compilers packages to build Mingw-w64 targets are available in the Cygwin distro. diff --git a/winsup/doc/faq-programming.xml b/winsup/doc/faq-programming.xml index 5920ca8c44d5..07d3a61f2fb2 100644 --- a/winsup/doc/faq-programming.xml +++ b/winsup/doc/faq-programming.xml @@ -76,7 +76,7 @@ sizeof(void*) 488 This difference can result in interesting problems, especially when -using Win32 functions, especially when using pointers to Windows +using Windows API functions using pointers to Windows datatypes like LONG, ULONG, DWORD. Given that Windows is LLP64, all of the aforementioned types are 4 byte in size, on 32 as well as on 64 bit Windows, while `long' on 64 bit Cygwin is 8 bytes. @@ -189,10 +189,10 @@ string pointer given to printf is missing the upper 4 bytes. -Don't use C base types together with Win32 functions. +Don't use C base types together with Windows API functions. Keep in mind that DWORD, LONG, ULONG are not the same -as long and unsigned long. Try to use only Win32 datatypes in conjunction -with Win32 API function calls to avoid type problems. See the above +as long and unsigned long. Try to use only Windows datatypes in conjunction +with Windows API function calls to avoid type problems. See the above ReadFile example. Windows functions in printf calls should be treated carefully as well. This code is common for 32 bit code, but probably prints the wrong value on 64 bit: @@ -438,11 +438,11 @@ gcj --main=Hello Hello.java -How do I use Win32 API calls? +How do I use Windows API calls? Cygwin tools require that you explicitly link the import libraries -for whatever Win32 API functions that you are going to use, with the exception +for whatever Windows API functions that you are going to use, with the exception of kernel32, which is linked automatically (because the startup and/or built-in code uses it). @@ -464,7 +464,7 @@ including user32, gdi32 and comdlg32. or at least after all the object files and static libraries that reference them. -There are a few restrictions for calls to the Win32 API. +There are a few restrictions for calls to the Windows API. For details, see the User's Guide section https://cygwin.com/cygwin-ug-net/setup-env.html#setup-env-win32;>Restricted Win32 environment, as well as the User's Guide section @@ -472,7 +472,7 @@ as well as the User's Guide section -How do I compile a Win32 executable that doesn't use Cygwin? +How do I compile a Windows executable that doesn't use Cygwin? The compilers provided by the mingw64-i686-gcc and @@ -528,7 +528,7 @@ lines must start with tabs. This is not specific to Cygwin. -Why can't we redistribute
[PATCH v2 1/3] winsup/doc/faq-setup.xml, faq-using.xml: update setup FAQ
change all kinds of setup references to "the Cygwin Setup program"; emphasize 64 bit and deemphasize 32 bit; update options list; explain why installing everything is now extremely inadvisable, with stats --- winsup/doc/faq-setup.xml | 229 ++- winsup/doc/faq-using.xml | 27 ++--- 2 files changed, 118 insertions(+), 138 deletions(-) diff --git a/winsup/doc/faq-setup.xml b/winsup/doc/faq-setup.xml index b242fbae422c..c04ffe9a56e7 100644 --- a/winsup/doc/faq-setup.xml +++ b/winsup/doc/faq-setup.xml @@ -10,12 +10,16 @@ What is the recommended installation procedure? -There is only one recommended way to install Cygwin, which is to use the GUI -installer setup-*.exe. It is flexible and easy to use. + +There is only one recommended way to install Cygwin, which is to use the +Cygwin Setup program, a GUI installer named +setup-x86_64.exe for 64 bit Windows, or +setup-x86.exe for 32 bit Windows. It is flexible and easy to use. You can pick and choose the packages you wish to install, and update them individually. Full source code is available for all packages and -tools. More information on using Cygwin Setup may be found at -https://cygwin.com/cygwin-ug-net/setup-net.html"/>. +tools. +https://cygwin.com/cygwin-ug-net/setup-net.html;>More information +is available on using the Cygwin Setup program. If you do it any other way, you're on your own! If something doesn't work right for you, and @@ -35,8 +39,8 @@ see https://cygwin.com/packages/"/>. The Cygwin Setup program is designed to be interactive, but there are a few different ways to automate it. If you are deploying to multiple systems, the best way is to run through a full installation once, saving the entire -downloaded package tree. Then, on target systems, run Cygwin Setup as a -"Local Install" pointed at your downloaded package tree. You could do this +downloaded package tree. Then, on target systems, run the Cygwin Setup program as a +"Local Install" pointed at your downloaded package tree. You could do this non-interactively with the command line options -q -L -l x:\cygwin-local\, where your downloaded package tree is in x:\cygwin-local\ (see the next FAQ for @@ -50,32 +54,33 @@ For other options, search the mailing lists with terms such as -Does Setup accept command-line arguments? +Does the Cygwin Setup program accept command-line arguments? -Yes, run setup-x86.exe --help or -setup-x86_64.exe --help for a list. +Yes, run the Cygwin Setup program with option +--help for an up to date list: --allow-unsupported-windowsAllow old, unsupported Windows versions - -a --arch architecture to install (x86_64 or x86) + -a --arch Architecture to install (x86_64 or x86) -C --categories Specify entire categories to install - -o --delete-orphans remove orphaned packages + -o --delete-orphans Remove orphaned packages -A --disable-buggy-antivirus Disable known or suspected buggy anti virus software packages during execution. - -D --download Download from internet - -f --force-currentselect the current version for all packages - -h --help print help - -I --include-source Automatically include source download + -D --download Download packages from internet only + -f --force-currentSelect the current version for all packages + -h --help Print help + -I --include-source Automatically install source for every + package installed -i --ini-basename Use a different basename, e.g. "foo", instead of "setup" -U --keep-untrusted-keys Use untrusted keys and retain all - -L --local-installInstall from local directory + -L --local-installInstall packages from local directory only -l --local-package-dirLocal package directory - -m --mirror-mode Skip availability check when installing from - local directory (requires local directory to - be clean mirror!) + -m --mirror-mode Skip package availability check when + installing from local directory (requires + local directory to be clean mirror!) -B --no-admin Do not check for and enforce running as Administrator -d --no-desktop Disable creation of desktop shortcut @@ -85,23 +90,29 @@ For other options, search the mailing lists with terms such as shortcuts -N --no-startmenu Disable creation of start menu shortcut -X
Re: [PATCH 0/3] FAQ api, programming, timezone, setup patches
Hi Brian, On Aug 24 14:10, Brian Inglis wrote: > winsup/doc/faq-api.xml,faq-programming.xml: change Win32 to Windows Didn't we agree on WinAPI? Windows is fine when used in the context of the OS, but Win32 was mainly used to denote the API. So "Windows API" or, better, WinAPI, should be used in these places. Thanks, Corinna
Re: [PATCH] Cygwin: malloc tune-up
Hi Mark, On Aug 25 00:29, Mark Geisert wrote: > Hi Corinna, > Well, this patch turned out to be half-baked. Locking is working correctly > because USE_LOCKS was set to 1 for malloc.cc's compilation. The torture > test I run validated that. OTOH as you said, MSPACES was set 1 for > malloc.cc but 0 for malloc_wrapper.cc. So this patch yields a malloc > facility like pre-3.2 but using internal locking on data structures instead > of function-level locking. An improvement, but not the whole package that > I'm attempting to deliver because there's still thread contention on the > internal locks. Properly operating mspaces should get rid of that or at > least lower it significantly. > > I appreciate your comments on TLS variables and fork safety. I will > investigate this area further. The mspaces should/will survive a fork but > obviously the threads that created them won't. Memory blocks can be freed > by any thread; there's no need to create threads in the child process just > to manage mspaces. I was not worried about the malloced spaces themselves, but about the TLS pointer of the thread calling fork(). The TLS pointer itself (the one returned by TlsGetValue) is not propagated to the child process. Therefore, this pointer is wrong in the child. If that's not a problem, fine. But if it has to be preserved over fork, then the cygtls area is definitely the way to propagate thread-specific info via fork. Corinna
Re: [PATCH] Cygwin: malloc tune-up
Hi Corinna, Well, this patch turned out to be half-baked. Locking is working correctly because USE_LOCKS was set to 1 for malloc.cc's compilation. The torture test I run validated that. OTOH as you said, MSPACES was set 1 for malloc.cc but 0 for malloc_wrapper.cc. So this patch yields a malloc facility like pre-3.2 but using internal locking on data structures instead of function-level locking. An improvement, but not the whole package that I'm attempting to deliver because there's still thread contention on the internal locks. Properly operating mspaces should get rid of that or at least lower it significantly. I appreciate your comments on TLS variables and fork safety. I will investigate this area further. The mspaces should/will survive a fork but obviously the threads that created them won't. Memory blocks can be freed by any thread; there's no need to create threads in the child process just to manage mspaces. I have more work to do then I'll submit a v2 of the patch. Thanks & Regards, ..mark
