Re: perl-Win32-API package problem
SJ Luo writes: > I have a small Perl program that utilize module > Win32::API::Callback. Sorry that it took so long, but the problem should be fixed with the new release of that package. Please confirm that it works for your application when you get the chance to test, thank you. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-Win32-API package problem
Hi Achim, > > By checking the gcc compile option, I found there is a gcc option > > "-fno-stack-protector" provided when I compile this module by myself, > > while the option is removed when I compile with cygport. If I try > > manually compiling without this option, the same problem occurs. > > I don't know enough of how the stack protector actually is implemented > to understand why it would work without the protector and stop working > with. > > I'll see if it's possible to remove the option from within cygport, if > yo I'll have to think about any ramifications that might have. Thanks for the responding. I just learned that stack protector is trying to prevent against buffer overflow/stack-corruption based attacks. It might not be a big issue. A crack-aware program shall simply avoid this module. And yes I believe it is complex that how stack protector have influence on this Perl module. But I think this option is just necessary. The Makefile.PL explicitly applies -fno-stack-protector option on non-MSVC compilers with 64bit target: https://metacpan.org/source/BULKDD/Win32-API-0.84/Makefile.PL#L149 SJ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-Win32-API package problem
SJ Luo writes: > The two lines of commands "mv ; cp xxx" are to dereference the > symbolic links of testing-needed dll files because > Win32::API::LoadLibrary() seems not be able to resolve Cygwin symbolic > link. You'd need to use native symlinks for that to work, yes. > By checking the gcc compile option, I found there is a gcc option > "-fno-stack-protector" provided when I compile this module by myself, > while the option is removed when I compile with cygport. If I try > manually compiling without this option, the same problem occurs. I don't know enough of how the stack protector actually is implemented to understand why it would work without the protector and stop working with. > The host system is Windows7. Cygwin dll is 64bit version 2.10.0-1. > wish it can be solved soon in next package release. I'll see if it's possible to remove the option from within cygport, if yo I'll have to think about any ramifications that might have. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
perl-Win32-API package problem
Hi, I have a small Perl program that utilize module Win32::API::Callback. This module works properly if I downloaded this module from CPAN and compile by myself. There occurs a problem if I get it from binary package perl-Win32-API downloaded by Cygwin setup program. I then tried to figure this problem out by downloading source module and compile by myself. I found a simple flow to duplicate the fail with the following sequence. - Cut here - % cd /usr/src/perl-Win32-API-0.84-1.src % cygport perl-Win32-API.cygport prep compile : % cd perl-Win32-API-0.84-1.x86_64/build/ % mv API_test64.dll API_test64.dll.lnk; cp API_test64.dll.lnk API_test64.dll % mv rtc64.dll rtc64.dll.lnk; cp rtc64.dll.lnk rtc64.dll % cd Callback % make test : (Failed test 'callback function works' at t/02_Callback.t line 58.) : % touch Callback.c % make % make test : (All tests passed) : - Cut here - The two lines of commands "mv ; cp xxx" are to dereference the symbolic links of testing-needed dll files because Win32::API::LoadLibrary() seems not be able to resolve Cygwin symbolic link. Two "make test" commands are shown above. The first test fails at 02_Callback.t line 75. After fail, a force recompile of the Callback.dll module is done by touch and make. Doing "make test" again, this time all test items passed. By checking the gcc compile option, I found there is a gcc option "-fno-stack-protector" provided when I compile this module by myself, while the option is removed when I compile with cygport. If I try manually compiling without this option, the same problem occurs. The host system is Windows7. Cygwin dll is 64bit version 2.10.0-1. wish it can be solved soon in next package release. Thanks, SJ https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"; target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"; alt="" width="46" height="29" style="width: 46px; height: 29px;" /> 不含病毒。https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail"; target="_blank" style="color: #4453ea;">www.avast.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Sep 21, 2015, at 7:11 PM, Michael Enright wrote: > > The blindness was blindness to the fact that new users were getting a > different version than existing users in some way other than fixing > vulns. Why should you believe that in the first place? There is only one Cygwin, so why would you expect that it or its standard packages have had no features in the last N years? You’d expect to see at least two different Cygwins, a stable one and a bleeding-edge one, if that were happening. > one assumes that constant incorporation of upstreams, constantly > switching away from unmaintained upstreams to maintained-but-different > upstreams etc is what the Cygwin user base wants. Yes, Cygwin is basically a bleeding-edge type of “OS” distribution.[*] It ships whatever is current, as long as there are maintainers willing and able to keep its packages up to date. This is the case because almost all of the packages in Cygwin are maintained by people who do not get paid by a Cygwin organization to do so. These maintainers are either scratching their own itches or just plain volunteering. Therefore, you get whatever is good for each package’s maintainer, which may or may not match with what is good for you. [*] Never mind that Cygwin and its package set runs on top of an existing OS. That’s a side issue, as far as this discussion goes. > Do Cygwin'ers ever debate or think about an LTS track for Cygwin? If it comes up, it does so so rarely that I can’t remember the last time it did. LTS generally implies a business model,[**] and as far as I know, the current Cygwin business model only pays for one person’s time: http://www.redhat.com/services/custom/cygwin/ She’s plenty busy already without adding LTS distro maintenance on top of that. I expect if the Cygwin support and license buy-out businesses were making enough money for Red Hat that an LTS version of it would already exist. I suspect this is what is behind the weak push to get all packages cygport-ified and set up an automated build server. But, this is still in the planning stages, AFAIK, and thus may never become a reality. [**] Canonical is unprofitable, but has Shuttleworth’s millions backing its LTS releases. Red Hat is very profitable, which indirectly sustains the RHEL clones,[***] but that’s no model for a Cygwin LTS, since you need RHEL to clone from in the fist place. [***] And all the stuff built on top of RHEL clones indirectly sustains Red Hat, so it all works out. But other than the license buy-out, I don’t see how people building stuff on top of Cygwin helps Red Hat. > Is that why there's a "time machine?” There is a time machine because Peter Castro has kindly decided to provide one. It is not an official product of the Cygwin project. (The URL should have been enough of a clue as to this fact.) The time machine could go away at any time. We are grateful to have it for as long as it exists. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Tue, Sep 22, 2015 at 10:54 AM, Yaakov Selkowitz wrote: > > Installing with Cygwin Setup. > > > This is the only supported installation method. > On Tue, Sep 22, 2015 at 10:59 AM, David Stacey wrote: > We're drifting off topic, but never mind... Thanks Yaakov, David, Achim, Vince and whoever else may be moved to chime in. I don't wish to take over the list with this subject. The answers so far have given me much to think about, and are complete enough that I don't need to ask follow-up questions at this time. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
Michael Enright writes: > I am interested to hear if anyone has managed a group of Cygwin users > and the configuration they use, and how they went about it. I do and the only sane way is to have a local mirror with exactly the packages and versions that you are going to install and your own setup.ini. I integrate Cygwin upstream, Cygwin Ports plus literally hundreds of locally built packages via some scripting. In principle it's possible to provide multiple versions (e.g. for staged rollouts) by having separate setup.ini files, but there's no automation for keeping the mirror in sync at the moment. I also compile setup.exe myself (although at the moment I have no patches on top of upstream). There's a wrapper script around setup that will install the correct variant of Cygwin initially and keep it updated later. > More out there, I'm interested in thoughts about making it possible to > tell a group such as a customer base (a group of autonomous, > free-will-possessing individual organizations) how to setup Cygwin so > a non-Cygwin component can be added on top and work even though it > might not still work with a regular default fresh Cygwin. You could replace the Cygwin key in setup.exe with your own, remove the ability to install without the signature check and sign your setup.ini; that should take care of any inadvertent use of the "wrong" Cygwin. I've not done that yet, but eventually will so the installations can not be manipulated without some real effort, even inadvertently. If the users still get themselves into trouble, then it's their problem, not yours. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On 22/09/15 18:16, Michael Enright wrote: New workers needed new Windows boxes with Cygwin on them. What is the process for putting Cygwin on a new Windows box? It isn't "rsync Cygwin from IT". Cygwin's default (or only) distribution method has a role to play in this. Does anyone ever setup Cygwin on a new Windows install other than by downloading setup_x86.exe or setup_x86-64.exe and working from there? Is any such alternative given equal priority on cygwin.com ? I am interested to hear if anyone has managed a group of Cygwin users and the configuration they use, and how they went about it. We're drifting off topic, but never mind... It sounds like you're deploying Cygwin in a corporate environment. Most corporate development environments require a degree of stability, and most Open Source programmes update faster than your average corporate software department can cope with. So *you* have to take responsibility for managing your own development environment. In terms of Cygwin, that means downloading Cygwin setup and the packages you need, then testing, updating and patching until you have a Cygwin installation that meets your needs. How you deploy that to your engineers depends on your infrastructure: - Update a master VM image that your developers use; - Remote deploy the new Cygwin installation at the appropriate PCs; - Upload the Cygwin packages to a local web server and point Cygwin Setup at that (on each PC); - Store the Cygwin packages in whatever binary repository your company uses; - Get low-tech: Burn a DVD and pass it round the office(!) Use this installation and keep your development environment stable until such a time when you're ready to update. Then repeat the process. Oh, and remember to archive your old development environment in some way, as sooner of later you're going to need to maintain an old build and you'll want to go back to how things were a couple of years ago. Every company is going to have a different balance between stability and frequency of updates, and it would be impossible for Cygwin to come up with a model that works for everyone. Hope this helps, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Tue, 2015-09-22 at 10:16 -0700, Michael Enright wrote: > No one was updating. New workers needed new Windows boxes with Cygwin > on them. What is the process for putting Cygwin on a new Windows box? Installing with Cygwin Setup. > Cygwin's default (or only) distribution method has a role to play in > this. Does anyone ever setup Cygwin on a new Windows install other > than by downloading setup_x86.exe or setup_x86-64.exe and working from > there? Is any such alternative given equal priority on cygwin.com ? This is the only supported installation method. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Mon, Sep 21, 2015 at 9:16 PM, Vince Rice wrote: > > The blindness was, as I’ve already pointed out, caused by blindly > updating software No one was "updating"! I have diagnosed what I did "wrong" before and I am satisfied with my conclusion. I don't yet know of a way to keep changes from affecting me, but I know some things I can do to be prepared for the changes that might happen, so I'm doing those things. No one was updating. New workers needed new Windows boxes with Cygwin on them. What is the process for putting Cygwin on a new Windows box? It isn't "rsync Cygwin from IT". Cygwin's default (or only) distribution method has a role to play in this. Does anyone ever setup Cygwin on a new Windows install other than by downloading setup_x86.exe or setup_x86-64.exe and working from there? Is any such alternative given equal priority on cygwin.com ? I am interested to hear if anyone has managed a group of Cygwin users and the configuration they use, and how they went about it. More out there, I'm interested in thoughts about making it possible to tell a group such as a customer base (a group of autonomous, free-will-possessing individual organizations) how to setup Cygwin so a non-Cygwin component can be added on top and work even though it might not still work with a regular default fresh Cygwin. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Sep 21, 2015, at 8:11 PM, Michael Enright wrote: > > On Mon, Sep 21, 2015 at 5:50 PM, Vince Rice wrote: > >> blindly > > The blindness was blindness to the fact that new users were getting a > different version than existing users in some way other than fixing > vulns. > … The blindness was, as I’ve already pointed out, caused by blindly updating software without knowing the reason for the update. Had you/they been doing so, you/they would have known there was a “different” version. Again, it was _announced_ as being “different”. Software changes. It changes whether you, or I, like it or not. It changes for lots of reasons, some of them you/I might agree with, some of them you/I might not agree with. Nevertheless, it changes. Telling us it changed, and why, is good practice for software providers. That was done here. Reading why it changed, and knowing how that will affect us, is good practice for software users. That apparently wasn’t done here. The fault does not lie with the software provider. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Mon, Sep 21, 2015 at 5:50 PM, Vince Rice wrote:
>blindly
The blindness was blindness to the fact that new users were getting a
different version than existing users in some way other than fixing
vulns. Since Cygwin isn't the sort of product that needs to make up
sham reasons to upgrade as Microsoft Word does ("Look! A Ribbon!"),
one assumes that constant incorporation of upstreams, constantly
switching away from unmaintained upstreams to maintained-but-different
upstreams etc is what the Cygwin user base wants. Or at least most of
it.
Do Cygwin'ers ever debate or think about an LTS track for Cygwin? Is
that why there's a "time machine?"
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
> On Sep 21, 2015, at 7:04 PM, Michael Enright wrote: > > On Mon, Sep 21, 2015 at 1:31 PM, Marco Atzeri wrote: >> >> the change in nc had nothing to do with cygwin >> change between 1.5 and 1.7 >> >> https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html >> > > Implying a tie between the nc version to the release of 1.7.0-0 was > wrong on my part. I am not wrong in this change to 'nc' did happen. > Because I was not tracking all things Cygwin all the time I didn't > know about it at first, and the people who had problems with it in my > world were those who had deployed new workstations with Cygwin 1.7 > while those who could just keep using Cygwin 1.5 did not have > problems. The point is that Cygwin doesn't stay the same all the time > in the ways that all users may care about. It did happen, and as Marco pointed out, it was _announced_ that it happened. If someone is using Cygwin, not following the mailing list (at the very least the announce list), and updating the software blindly, then there's not much else to be done. They're almost guaranteed to run into problems. This is no different than any other software on the planet — blindly updating Linux versions without knowing what’s in the update, or blindly updating Word without knowing what’s in the update, and so on, leads to the same thing — problems can, and will, happen. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Mon, Sep 21, 2015 at 1:31 PM, Marco Atzeri wrote: > > the change in nc had nothing to do with cygwin > change between 1.5 and 1.7 > > https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html > Implying a tie between the nc version to the release of 1.7.0-0 was wrong on my part. I am not wrong in this change to 'nc' did happen. Because I was not tracking all things Cygwin all the time I didn't know about it at first, and the people who had problems with it in my world were those who had deployed new workstations with Cygwin 1.7 while those who could just keep using Cygwin 1.5 did not have problems. The point is that Cygwin doesn't stay the same all the time in the ways that all users may care about. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On 21/09/2015 22:02, jacob.a.lamber...@l-3com.com wrote: Hello anrdae...@yandex.ru! 1. https://cygwin.com/acronyms/#TOFU pretty please. Upgrading would be a pain, Who said that?... 1. Here we go. 2. While I doubt it would be technically difficult, it would be easier to keep the same version as far as good ol' corporate policy goes. Sincerely, Jake Lamberson than download all the source software from the Cygwin Time Machine http://www.fruitbat.org/Cygwin/ Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On 21/09/2015 21:55, Michael Enright wrote: On Mon, Sep 21, 2015 at 12:25 PM, Andrey Repin wrote: Upgrading would be a pain, Who said that?... PMFJI, Between Cyg 1.5 and 1.7 the command-line interface changed on the "nc" utility and, from the point of view of someone who at the time did not read this list, it was a silent, breaking change. So I would not be surprised if OP had a situation where recompiling an old version was best. the change in nc had nothing to do with cygwin change between 1.5 and 1.7 https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Question about old win32 api
Hello anrdae...@yandex.ru! > 1. https://cygwin.com/acronyms/#TOFU pretty please. > > > Upgrading would be a pain, > > Who said that?... 1. Here we go. 2. While I doubt it would be technically difficult, it would be easier to keep the same version as far as good ol' corporate policy goes. Sincerely, Jake Lamberson -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Mon, Sep 21, 2015 at 12:25 PM, Andrey Repin wrote: > Greetings, jacob.a.lamber...@l-3com.com! > > 1. https://cygwin.com/acronyms/#TOFU pretty please. > >> Upgrading would be a pain, > > Who said that?... > > PMFJI, Between Cyg 1.5 and 1.7 the command-line interface changed on the "nc" utility and, from the point of view of someone who at the time did not read this list, it was a silent, breaking change. So I would not be surprised if OP had a situation where recompiling an old version was best. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
Greetings, jacob.a.lamber...@l-3com.com! 1. https://cygwin.com/acronyms/#TOFU pretty please. > Upgrading would be a pain, Who said that?... -- With best regards, Andrey Repin Monday, September 21, 2015 22:24:28 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Question about old win32 api
Yaakov, Upgrading would be a pain, but I have to re-create the binaries I'm using from source. -Jake -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Yaakov Selkowitz Sent: Monday, September 21, 2015 11:53 AM To: cygwin@cygwin.com Subject: Re: Question about old win32 api On Mon, 2015-09-21 at 16:10 +, jacob.a.lamber...@l-3com.com wrote: > I'm attempting to compile cygwin 1.7.18. I've made some progress, but > have run into what appears to be an incompatibility between minGW's > Win32 api and this version of cygwin. Better yet, why are you trying to build such an old version? -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about old win32 api
On Mon, 2015-09-21 at 16:10 +, jacob.a.lamber...@l-3com.com wrote: > I'm attempting to compile cygwin 1.7.18. I've made some progress, but have > run into what appears to be an incompatibility between minGW's Win32 api > and this version of cygwin. Better yet, why are you trying to build such an old version? -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Question about old win32 api
Hi all, I'm attempting to compile cygwin 1.7.18. I've made some progress, but have run into what appears to be an incompatibility between minGW's Win32 api and this version of cygwin. The same problem is identified here: https://sourceware.org/ml/cygwin/2013-10/msg00348.html. I have run into the same THREAD_INFORMATION_CLASS double declaration as the link, among other things. So far as I can tell, I need to get some older minGW Win32api packages to compile this. Could someone point me to these? I haven't been able to find anything besides the most recent version. Thanks, Jake -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Want to build Win32 API code and Posix API code in Cygwin
Hi Andrey, Thanks for your patient answer. Actually the code is historic legacy, and I want to have a quick try on Windows and reduce the efforts as much as possible. Code part B mainly contains some device operations, like serial port, ethernet config(not only socket), USB detection, etc, code part A mainy contain process management and FS operation, etc. I get "no tchar.h", "definition of gethostname conflicts" like error when I build them together on Cygwin using GCC. What is your advice under such situation? "Push all platform-dependent code into a separate library" is another method I'm trying for long-term resolution, but is there any approach I can have a quick try w/o stbility and performance consideration? Thanks a lot and appreciated for your reply! 2014-02-24 17:55 GMT+08:00 Andrey Repin : > Greetings, Qw Liu! > >> I have legacy code (part A) written in Posix API that I want to >> port to Windows, and there is also some other necessary code (part B) >> written in Win32 API, but seems that I cannot use GCC on Cygwin to >> build them (A and B) together to get the executable program, since I >> met issue like "header missing" for Win32 API . >> Is there any other method to resolve such problem? I considerred >> to build part B as dll first and build with part A on Cygwin. Is that >> okay? > > My Crystal Ball is in service - overheated again... > WHAT header you are missing, exactly? > And before you answer that, you do aware, that mixing POSIX and Windows native > API calls is generally considered not a very good idea, right? > Depends on the kind of mix (stirred, not shaken?), you may be on a very sharp > edge of things. > Without looking at your code, one possible solution is to push all > platform-dependent code into a separate library, and load it at runtime. > > > -- > WBR, > Andrey Repin (anrdae...@yandex.ru) 24.02.2014, <13:49> > > Sorry for my terrible english... > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Want to build Win32 API code and Posix API code in Cygwin
Greetings, Qw Liu! > I have legacy code (part A) written in Posix API that I want to > port to Windows, and there is also some other necessary code (part B) > written in Win32 API, but seems that I cannot use GCC on Cygwin to > build them (A and B) together to get the executable program, since I > met issue like "header missing" for Win32 API . > Is there any other method to resolve such problem? I considerred > to build part B as dll first and build with part A on Cygwin. Is that > okay? My Crystal Ball is in service - overheated again... WHAT header you are missing, exactly? And before you answer that, you do aware, that mixing POSIX and Windows native API calls is generally considered not a very good idea, right? Depends on the kind of mix (stirred, not shaken?), you may be on a very sharp edge of things. Without looking at your code, one possible solution is to push all platform-dependent code into a separate library, and load it at runtime. -- WBR, Andrey Repin (anrdae...@yandex.ru) 24.02.2014, <13:49> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Want to build Win32 API code and Posix API code in Cygwin
Hi All, I have legacy code (part A) written in Posix API that I want to port to Windows, and there is also some other necessary code (part B) written in Win32 API, but seems that I cannot use GCC on Cygwin to build them (A and B) together to get the executable program, since I met issue like "header missing" for Win32 API . Is there any other method to resolve such problem? I considerred to build part B as dll first and build with part A on Cygwin. Is that okay? Thanks a lot for your guidance! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Signal occasionally causes thread inside win32 api to be suspended?
On Mon, Dec 09, 2013 at 08:59:26PM +, Jon TURNEY wrote: >On 09/12/2013 20:47, Christopher Faylor wrote: >> On Sun, Dec 08, 2013 at 05:36:16PM +, Jon TURNEY wrote: >>> I don't really understand the intricacies of cygwin signal delivery, >>> but I see that it can suspend the target thread to determine if it's in >>> a safe place to deliver the signal (outside a win32 API call). I think >>> that sometimes the thread is not correctly resumed. >>> >>> This appears to be the cause of been a long-standing problem with the >>> X.org X server on cygwin, which we work around by disabling >>> smart-scheduling (no great loss), but I've only just recently >>> understood enough about the problem to produce a STC. >>> >>> If you run the attached for a while, it stops. According to Process >>> Hacker, the main thread is in the suspended state, inside ntdll.dll. >>> e.g.: >> >> I think I have worked around the problem: calling GetModuleName for the >> address associated with ntdll.dll while the thread is suspended can cause >> the program (thread?) to hang. > >Ah, makes sense. It's probably deadlocked on the global loader lock, if you >happen to suspend the thread while it is held. Probably something like that. I used to have tests in the code to avoid things like that for Windows 9x. Who would have guessed that you could still get into this state with modern versions of Windows*? cgf *This is a rhetorical question. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Signal occasionally causes thread inside win32 api to be suspended?
On 09/12/2013 20:47, Christopher Faylor wrote: > On Sun, Dec 08, 2013 at 05:36:16PM +, Jon TURNEY wrote: >> I don't really understand the intricacies of cygwin signal delivery, >> but I see that it can suspend the target thread to determine if it's in >> a safe place to deliver the signal (outside a win32 API call). I think >> that sometimes the thread is not correctly resumed. >> >> This appears to be the cause of been a long-standing problem with the >> X.org X server on cygwin, which we work around by disabling >> smart-scheduling (no great loss), but I've only just recently >> understood enough about the problem to produce a STC. >> >> If you run the attached for a while, it stops. According to Process >> Hacker, the main thread is in the suspended state, inside ntdll.dll. >> e.g.: > > I think I have worked around the problem: calling GetModuleName for the > address associated with ntdll.dll while the thread is suspended can cause > the program (thread?) to hang. Ah, makes sense. It's probably deadlocked on the global loader lock, if you happen to suspend the thread while it is held. > This should be rectified in today's snapshot. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Signal occasionally causes thread inside win32 api to be suspended?
On Sun, Dec 08, 2013 at 05:36:16PM +, Jon TURNEY wrote: >I don't really understand the intricacies of cygwin signal delivery, >but I see that it can suspend the target thread to determine if it's in >a safe place to deliver the signal (outside a win32 API call). I think >that sometimes the thread is not correctly resumed. > >This appears to be the cause of been a long-standing problem with the >X.org X server on cygwin, which we work around by disabling >smart-scheduling (no great loss), but I've only just recently >understood enough about the problem to produce a STC. > >If you run the attached for a while, it stops. According to Process >Hacker, the main thread is in the suspended state, inside ntdll.dll. >e.g.: I think I have worked around the problem: calling GetModuleName for the address associated with ntdll.dll while the thread is suspended can cause the program (thread?) to hang. This should be rectified in today's snapshot. Thanks, as always, for the test case. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Signal occasionally causes thread inside win32 api to be suspended?
I don't really understand the intricacies of cygwin signal delivery, but I see
that it can suspend the target thread to determine if it's in a safe place to
deliver the signal (outside a win32 API call). I think that sometimes the
thread is not correctly resumed.
This appears to be the cause of been a long-standing problem with the X.org X
server on cygwin, which we work around by disabling smart-scheduling (no great
loss), but I've only just recently understood enough about the problem to
produce a STC.
If you run the attached for a while, it stops. According to Process Hacker,
the main thread is in the suspended state, inside ntdll.dll. e.g.:
$ uname -a
CYGWIN_NT-5.1 byron 1.7.26(0.271/5/3) 2013-11-29 11:25 i686 Cygwin
$ ./signal-in-kernel32
hMod is 0x7c80
iteration 1
[...]
iteration 139325
# stops!
#include
#include
#include
#include
#include
long SmartScheduleInterval = 20; /* ms */
long SmartScheduleTime = 0;
static void
SmartScheduleTimer(int sig)
{
SmartScheduleTime += SmartScheduleInterval;
}
void
SmartScheduleStartTimer(void)
{
struct itimerval timer;
timer.it_interval.tv_sec = 0;
timer.it_interval.tv_usec = SmartScheduleInterval * 1000;
timer.it_value.tv_sec = 0;
timer.it_value.tv_usec = SmartScheduleInterval * 1000;
setitimer(ITIMER_REAL, &timer, 0);
}
int main()
{
/* Set up the timer signal function */
struct sigaction act;
act.sa_handler = SmartScheduleTimer;
sigemptyset(&act.sa_mask);
sigaddset(&act.sa_mask, SIGALRM);
if (sigaction(SIGALRM, &act, 0) < 0) {
perror("sigaction failed");
return -1;
}
HMODULE hMod = LoadLibraryEx("kernel32.dll", NULL, 0);
assert(hMod);
printf("hMod is %p\n", hMod);
/* start timer */
SmartScheduleStartTimer();
/* Loop forever, spending most of our time inside ntdll */
int i = 0;
while (1) {
void *gpa = GetProcAddress(hMod, "GetProcAddress");
assert(gpa);
i++;
printf("iteration %d\n", i);
}
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: direct interface to win32 api for char output
On Thu, Apr 04, 2013 at 12:06:06AM +0900, wynfi...@gmail.com wrote: >This will be done in assembly language and I'd prefer not to have to >resort to directly using windows or bios interrupts. > >I would like build a very tiny program and I want to skip linking the c >library to this little program. Doing so would bloat it up to about >225times larger than it would be otherwise. > >All I need to know is the name of which win32 api (include file + >object files) handles output character and the name of the win32 api >(include file + object files) that handles print character to the >terminal. Very simple. This isn't a Cygwin question. Please use a general Windows forum for this type of question. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
direct interface to win32 api for char output
This will be done in assembly language and I'd prefer not to have to resort to directly using windows or bios interrupts. I would like build a very tiny program and I want to skip linking the c library to this little program. Doing so would bloat it up to about 225times larger than it would be otherwise. All I need to know is the name of which win32 api (include file + object files) handles output character and the name of the win32 api (include file + object files) that handles print character to the terminal. Very simple. Thanks -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: compilation fails with Win32 API call
> On 2011-09-20 PM 6:12, Andrew Schulman wrote: > > I'm trying to compile a program that calls the win32 function > > SetThreadExecutionState, in kernel32.dll [1]. The link step fails: > > please define WINVER so that you can get definition what you want > (gcc -E -DWINVER=0x500 - < #include > EOF > )|grep SetThreadExecution Thanks jojelino, and JonY too. -DWINVER=0x500 did the trick. Andrew. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: compilation fails with Win32 API call
On 2011-09-20 PM 6:12, Andrew Schulman wrote: I'm trying to compile a program that calls the win32 function SetThreadExecutionState, in kernel32.dll [1]. The link step fails: $ gcc -c nosleep.c $ gcc -o nosleep nosleep.o -lkernel32 nosleep.o:nosleep.c:(.text+0x1f): undefined reference to `_SetThreadExecutionState' nosleep.o:nosleep.c:(.text+0x5c): undefined reference to `_SetThreadExecutionState' collect2: ld returned 1 exit status According to the FAQ [2], I shouldn't even have to include -lkernel32. Can someone please tell me what I'm doing wrong? Thanks, Andrew. [1] http://msdn.microsoft.com/en-us/library/aa373208(VS.85).aspx here you are. http://msdn.microsoft.com/en-us/library/aa383745.aspx [2] http://www.cygwin.com/faq/faq.programming.html#faq.programming.win32-api please define WINVER so that you can get definition what you want (gcc -E -DWINVER=0x500 - < EOF )|grep SetThreadExecution now you can see SetThreadExecutionState is defined -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: compilation fails with Win32 API call
On 9/20/2011 17:12, Andrew Schulman wrote: > I'm trying to compile a program that calls the win32 function > SetThreadExecutionState, in kernel32.dll [1]. The link step fails: > > $ gcc -c nosleep.c > $ gcc -o nosleep nosleep.o -lkernel32 > nosleep.o:nosleep.c:(.text+0x1f): undefined reference to > `_SetThreadExecutionState' > nosleep.o:nosleep.c:(.text+0x5c): undefined reference to > `_SetThreadExecutionState' > collect2: ld returned 1 exit status > > According to the FAQ [2], I shouldn't even have to include -lkernel32. > > Can someone please tell me what I'm doing wrong? > > Thanks, > Andrew. > > [1] http://msdn.microsoft.com/en-us/library/aa373208(VS.85).aspx > [2] > http://www.cygwin.com/faq/faq.programming.html#faq.programming.win32-api > > Hi, There are a few possible causes. 1) You didn't include windows.h 2) You included it but didn't bump _WIN32_WINNT or equivalent. 3) The declaration is missing from winbase.h signature.asc Description: OpenPGP digital signature
compilation fails with Win32 API call
I'm trying to compile a program that calls the win32 function SetThreadExecutionState, in kernel32.dll [1]. The link step fails: $ gcc -c nosleep.c $ gcc -o nosleep nosleep.o -lkernel32 nosleep.o:nosleep.c:(.text+0x1f): undefined reference to `_SetThreadExecutionState' nosleep.o:nosleep.c:(.text+0x5c): undefined reference to `_SetThreadExecutionState' collect2: ld returned 1 exit status According to the FAQ [2], I shouldn't even have to include -lkernel32. Can someone please tell me what I'm doing wrong? Thanks, Andrew. [1] http://msdn.microsoft.com/en-us/library/aa373208(VS.85).aspx [2] http://www.cygwin.com/faq/faq.programming.html#faq.programming.win32-api -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: 1.5.25 : Win32 API function RegisterShellWindowHook not supported
On Sun, Dec 14, 2008 at 09:22:05AM -0700, Tim Stewart wrote:
>Environment:
>
> cygcheck -s shows that I'm running the 1.5.25 version of cygwin1.dll.
>
> I just updated my system a few days ago.
>
> I'm trying to compile some C++ code using g++.
>
>Documentation for the missing API function:
>
> http://msdn.microsoft.com/en-us/library/ms644989.aspx
>
>The Problem:
>
> The above documentation states that the function should be located
>in winuser.h but it's not. Its related function
>DeregisterShellWindowHook is in winuser.h.
>
> Even if I add a hand-coded prototype for this function, I get a
>linker error stating that the RegisterShellWindowProc function was
>unresolved. That's because it's not included in libuser32.a.
>
>Workaround:
>
> I am using GetProcAddress to access the function. For example:
>
> ::GetProcAddress(::GetModuleHandle("USER32.DLL"),
>"RegisterShellHookWindow");
You probably want to report this to the MinGW folks at http://mingw.org/
The focus of this project is to provide POSIX functionality. Windows
functions are really only an afterthought and are not guaranteed to be
fully supported.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Fwd: 1.5.25 : Win32 API function RegisterShellWindowHook not supported
Environment:
cygcheck -s shows that I'm running the 1.5.25 version of cygwin1.dll.
I just updated my system a few days ago.
I'm trying to compile some C++ code using g++.
Documentation for the missing API function:
http://msdn.microsoft.com/en-us/library/ms644989.aspx
The Problem:
The above documentation states that the function should be located
in winuser.h but it's not. Its related function
DeregisterShellWindowHook is in winuser.h.
Even if I add a hand-coded prototype for this function, I get a
linker error stating that the RegisterShellWindowProc function was
unresolved. That's because it's not included in libuser32.a.
Workaround:
I am using GetProcAddress to access the function. For example:
::GetProcAddress(::GetModuleHandle("USER32.DLL"),
"RegisterShellHookWindow");
Thank you!
Tim Stewart
E-mail: mailto:tim.j.stew...@gmail.com
Cell Phone: 303.912.2312
LinkedIn: http://www.linkedin.com/in/timothystewart
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Win32::API for Cygwin Perl?
Michael Kairys schrieb: It works! (But I guess you knew that :) Thanks very much. In the meantime I also added the remaining blocking patch for the latest release 0.49 to the tracker. Win32-API-0.50 can then be installed via CPAN (hopefully). http://rt.cpan.org/Public/Bug/Display.html?id=31702 -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://helsinki.at/ http://spacemovie.mur.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API for Cygwin Perl?
It works! (But I guess you knew that :) Thanks very much. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API for Cygwin Perl?
2008/2/22, Michael Kairys <[EMAIL PROTECTED]>: > Thanks for your reply, Reini. I tried installing your version and it ended > up in vendor_perl/5.10, whereas everything else is in 5.8. I don't know hwat > to do with/about that. Sorry: perl-Win32-API-0.42-2 is for perl-5.10 perl-Win32-API-0.42-1 is for perl-5.8.8 -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API for Cygwin Perl?
Thanks for your reply, Reini. I tried installing your version and it ended up in vendor_perl/5.10, whereas everything else is in 5.8. I don't know hwat to do with/about that. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API for Cygwin Perl?
2008/2/21, Michael Kairys <[EMAIL PROTECTED]>: > I can't figure out, after searching here and elsewhere, if there is a > Win32::API module for Cygwin Perl. I am trying to port some ActiveState > scripts that use it. I have an unofficial one. http://rurban.xarch.at/cygc/perl-Win32-API/perl-Win32-API-0.42-2.tar.bz2 This works. The new maintainer claims that he fixed all remaining gcc fixes lately also. Not really. http://search.cpan.org/dist/Win32-API/ 0.46 was the latest which used to work on cygwin. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Win32::API for Cygwin Perl?
I can't figure out, after searching here and elsewhere, if there is a Win32::API module for Cygwin Perl. I am trying to port some ActiveState scripts that use it. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
Kaveh Goudarzi wrote: > I downloaded the src for cygwin and compiled my code > as below (cygwin is where I did the cvs pull). > > gcc -o envs-test.exe env-test.c -I cygwin/src/winsup/cygwin/include/sys > > I call cygwin_internal ( CW_SYNC_WINENV ) prior to > the call to GetEnvironmentStrings ... the strange thing is the > value that comes back ... looking at the code > (cygwin/src/winsup/cygwin/external.cc) > I expected zero but I get another value (4294967295 ... uninitialized return?) You need to be careful with the versions here. You shouldn't try to use current headers with an old DLL. In this case CW_SYNC_WINENV was not a feature in the released vesion 1.5.19, but was added to CVS after its release. If you just take a standard Cygwin install and try to compile a program that calls cygwin_internal (CW_SYNC_WINENV) you should get a compile error. This is your signal that you need to use a snapshot -- both headers and DLL. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
Hi Guys, Thanks for your input. So it looks like my version of cygwin1.dll does not have the functionality I was trying to use namely the CW_SYNC_WINENV (doing an nm on cygwin1.dll I don't see sync_winenv ()). So unless there is going to be an imminent release I would be grateful if you could answer a few more questions :-) I will try to make them smarter (but can't promise I will succeed) :-) 1. Is there a simple way for me to gain access to the environ variable directly in my injected code? e.g. I see that __cygwin_environ is being passed to build_env in the sync_winenv () function and __cygwin_environ seems to be a global in cygwin1.dll ... can I somehow (knowing that the app I have injected is a cygwin app using Brians dll lookup code) gain access to this variable (if it's the right one)? 2. When I checked out the signature for cygwin_internal I saw that it's unsigned long so where does the int return value come from? is it from a call to a function like GetLastError? (Sorry I'm new to cygwin). extern "C" unsigned long cygwin_internal (cygwin_getinfo_types t, ...) Thanks again for your help ... and for cygwin :-) regards, Kaveh. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
On Tue, May 02, 2006 at 11:57:21AM -0400, Christopher Faylor wrote: >That's usually a good idea but I just noticed that cygwin-internal >doesn't set errno. There is no reason why it would have to, really, >since the interface is entirely local to cygwin and we can decide to do >what we want. However, I have changed it now so that it returns ENOSYS >when it is returning -1. To translate the above: I have changed the cygwin_internal function so that when the function is given an argument that it doesn't understand it will set errno to ENOSYS and return -1. This is likely to happen when a program is built with a newer version of cygwin but is trying to retrieve information from an older DLL. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
On Tue, May 02, 2006 at 03:32:44PM +0100, Dave Korn wrote: >On 02 May 2006 15:18, Kaveh Goudarzi wrote: >>I call cygwin_internal ( CW_SYNC_WINENV ) prior to the call to >>GetEnvironmentStrings ... the strange thing is the value that comes >>back ... looking at the code (cygwin/src/winsup/cygwin/external.cc) I >>expected zero but I get another value (4294967295 ... uninitialized >>return?) > >Return values are ints, not unsigneds. That one is -1. Which means >'error'! > >>Any ideas? > >Check errno for more information? That's usually a good idea but I just noticed that cygwin-internal doesn't set errno. There is no reason why it would have to, really, since the interface is entirely local to cygwin and we can decide to do what we want. However, I have changed it now so that it returns ENOSYS when it is returning -1. That won't help this particular case especially since I suspect that the problem is that the OP is not using a snapshot. >>Also I noticed that the address of environ seems always to be at >>0x460090 ... is it safe to assume this to always be the case? > >No, absolutely not. What he said. It's hard to believe that question would even be seriously asked. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
On 02 May 2006 15:18, Kaveh Goudarzi wrote: > I call cygwin_internal ( CW_SYNC_WINENV ) prior to > the call to GetEnvironmentStrings ... the strange thing is the > value that comes back ... looking at the code > (cygwin/src/winsup/cygwin/external.cc) I expected zero but I get another > value (4294967295 ... uninitialized return?) Return values are ints, not unsigneds. That one is -1. Which means 'error'! > Any ideas? Check errno for more information? > Also I noticed that the address of environ seems always to be > at 0x460090 ... is it safe to assume this to always be the case? No, absolutely not. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
Kaveh Goudarzi wrote:
> 1. is it possible to somehow force cygwin to always sync
> the env with windows prior to spawning a child process (any
> child process)?
Well, you could always patch the DLL to not perform this optimization.
I'm not sure if it's possible to do this in any other way.
> 2. How does cygwin work out if it's spawning a cygwin or
> non-cygwin binary? (is it based on refs to cygwin1.dll?)
> (is it the loader that does this?)
I think it looks at the PE headers of the file for a record referring to
cygwin1.dll in the import section. Or, if the path is mounted cygexec
this check is skipped and all binaries are assumed to be Cygwin
binaries, so you might be able to invert the sense of this somehow.
Also, there was some recent discussion about whether this optimization
was worth the headaches (in the context of programs that included
WinMain() failing when calling GetEnvironmentString()) and I think the
result was that the optimization was dropped... so I don't know what the
current state of this in CVS is. I think cgf or Corinna (if she wasn't
away on vacation right now) would have to clarify here.
> 3. Brian mentioned a call to cygwin_internal(CW_SYNC_WINENV)
> In my scenario (see below) I'd have to work out if the target
> process was a cygwin proc or not before I tried to invoke this
> method ... is there a painless way of working out if a process
> is cygwin or not e.g. one that would give me a response whether
> the process I'm querying is a cygwin or a native win app?
#include
#include
int main()
{
HMODULE hm = GetModuleHandle ("cygwin1.dll");
if (hm && GetProcAddress (hm, "cygwin_internal"))
puts ("I appear to be a cygwin binary.");
else
puts ("Nope, no Cygwin here.");
}
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
On Sun, Apr 30, 2006 at 03:32:55AM +, Eric Blake wrote: >On Sun, Apr 30, 2006 at 04:12:52AM +0100, Kaveh Goudarzi wrote: >>I'm working on an app which attempts to get the environment of running >>cygwin apps. It does this by running the GetEnvironmentStrings() win32 >>api call in the context of the running cygwin app (code injection). > >That is somewhat risky, as recent threads have discussed how windows >update does a code injection that interferes with cygwin and deadlocks >the processor into 100% utilization. Actually, it is unlikely that this is as simple as "code injection causes problems". I was playing with this technique a while ago with cygwin programs and I never saw the rumored 100% CPU utilization. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
Hi Eric/Brian, Thanks for your responses. I hope you don't mind answering a few more questions :-) 1. is it possible to somehow force cygwin to always sync the env with windows prior to spawning a child process (any child process)? 2. How does cygwin work out if it's spawning a cygwin or non-cygwin binary? (is it based on refs to cygwin1.dll?) (is it the loader that does this?) 3. Brian mentioned a call to cygwin_internal(CW_SYNC_WINENV) In my scenario (see below) I'd have to work out if the target process was a cygwin proc or not before I tried to invoke this method ... is there a painless way of working out if a process is cygwin or not e.g. one that would give me a response whether the process I'm querying is a cygwin or a native win app? Why I need the env: - I'm working on a tool which aims to automatically intercept code builds (e.g. make, nmake etc.) and produce alternative versions of the compiled code with some enhancements. The aim is to do this transparently so all a developer need do is run my spy program, then do a make clean, make and we would catch all the build commands, grab the command line, working dir and environment passed to gcc for example and use that info in the enhanced "compiler" to produce the alternative build. The target builds however are not necessarily all cygwin based - e.g. could be MS builds done via nmake or even an IDE. Thanks again for your help! Kaveh. PS. Eric - I figure that since this is generic cygwin behaviour there isn't any point in attaching the result of cygcheck now... let me know if it adds anything and I'll attach it in the next e-mail. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
Kaveh Goudarzi wrote: > I'm working on an app which attempts to get > the environment of running cygwin apps. It does this > by running the GetEnvironmentStrings() win32 api call > in the context of the running cygwin app (code injection). > However the result that comes back as a truncated version of > the environment - only 4 values PATH, SYSTEMDRIVE, SYSTEMROOT, > WINDIR. This is the expected behavior. Cygwin maintains its own environment separate from the Windows environment. This is (presumably) to reduce the overhead of having to convert paths back and forth every time a value is accessed. The only variables kept in the Windows environment are those that are essential to various win32 API calls, which as you have seen are things like SYSTEMROOT. Also, when Cygwin knows that it will be spawning a non-Cygwin binary, it will sync the Windows environment so that it is filled out. This is not a problem for the vast majority of Cygwin apps because the way to access the environment in a POSIX-like way is with getenv() and putenv(), and these work as expected on the Cygwin environment. Calling the win32 API directly to manipulate the environment breaks the encapsulation layer in that the proper way for a POSIX program to do this is with getenv/putenv, and Cygwin targets the POSIX API. So, the ideal way to handle this is to use getenv() instead. As an alternative you could call cygwin_internal (CW_SYNC_WINENV) before calling any win32 APIs, which should fill out the Windows environment. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
> > I'm working on an app which attempts to get > the environment of running cygwin apps. It does this > by running the GetEnvironmentStrings() win32 api call > in the context of the running cygwin app (code injection). That is somewhat risky, as recent threads have discussed how windows update does a code injection that interferes with cygwin and deadlocks the processor into 100% utilization. > However the result that comes back as a truncated version of > the environment - only 4 values PATH, SYSTEMDRIVE, SYSTEMROOT, > WINDIR. Correct. That's all the more cygwin processes use of the Windows environment. Going through Windows is slow and limited, so cygwin uses its own environment, converting to Windows only at the last minute when spawning a non-cygwin process. > > I saw the article below which seems relevant but I > was confused because my understanding of it would mean that > the call using win32 api should fail when run under both cmd.exe > and bash.exe which is not the case. > > http://cygwin.com/ml/cygwin/2006-01/msg00938.html A cygwin process invoked directly from cmd.com (currently) does not go out of its way to clear the environment, but child processes of cygwin do not waste time propagating everything via the Windows environment. > > I would be most grateful if someone could tell me > why this might be happening and what possible alternative > paths I could follow. If you wanted to be more like Linux, you could implement something in the /proc virtual file system that enumerated the environment of a particular process; by asking cygwin what cygwin thinks the environment, and without thread injection, you would get a better answer than by asking Windows about the cygwin environment; plus, you will be isolated from any further implementation changes cygwin makes with its under-the-hood handling of the environ. Why do you need to know the environment of a running cygwin process, anyways? Perhaps explaining your need would allow us to come up with an alternative approach. > > PS. I've attached the output of "cygcheck -s -v -r > cygcheck.out" Actually, you attached a one line file with contents "cygcheck -s -v -r". -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Truncated Environment Variables? - using Cygwin + GetEnvironmentStrings() WIN32 API
Hi,
I'm working on an app which attempts to get
the environment of running cygwin apps. It does this
by running the GetEnvironmentStrings() win32 api call
in the context of the running cygwin app (code injection).
However the result that comes back as a truncated version of
the environment - only 4 values PATH, SYSTEMDRIVE, SYSTEMROOT,
WINDIR.
You can reproduce this by compiling envs.c attached.
(gcc -o envs-gcc.exe envs-gcc.c). If you run the resulting exe
in cmd.exe (win xp) you get the full env in both cases but
if you run it under bash then the windows version is truncated.
I saw the article below which seems relevant but I
was confused because my understanding of it would mean that
the call using win32 api should fail when run under both cmd.exe
and bash.exe which is not the case.
http://cygwin.com/ml/cygwin/2006-01/msg00938.html
I would be most grateful if someone could tell me
why this might be happening and what possible alternative
paths I could follow.
thanks in advance + kind regards,
Kaveh.
PS. I've attached the output of "cygcheck -s -v -r > cygcheck.out"
and am running Windows XP Professional SP2
cygcheck -s -v -r
#include
#include
#include
int main ( int argc, char * argv[] , char *envp[] )
{
int i = 0 ;
int j = 0 ;
char * envw = NULL ;
printf ("== GCC Environment ==\n") ;
i = 0 ;
while ( envp[i] != NULL )
{
printf ("%s\n", envp[i++] ) ;
}
// printf ("&argv=0x%x 0x%x, &environ=0x%x\n", argv, argv, environ ) ;
printf ("\n\n== Windows GetEnvironmentStrings
Environment ==\n") ;
envw = GetEnvironmentStrings();
while ( strlen (envw) > 0 )
{
j++ ;
printf ("%s\n",envw);
envw += strlen(envw) + 1;
}
printf ("\n\nWindows Env Strings: %d, Cygwin Env Strings Count: %d\n\n", j,
i) ;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: win32::api on cygwin
Jason Pearce schrieb: Sorry if you posted this to the list and I didn't reply. I have had very little time to keep up with the Cygwin list lately. I have uploaded Reini's version of Win32::API to a http server. http://www.btinternet.com/~jasebob.pearce/cygwin/Win32-API-0.42.tar.gz There is also the cygwin packages I use to distribute this with setup inside my company. http://www.btinternet.com/~jasebob.pearce/cygwin/release/perl/perl-Win32-API/ Thanks a lot! I lost it locally also. Sopher, Dan wrote: Hi there, I came across your posts regarding Win32::API on Cygwin. Unfortunately, Reini's link for the patch is broken. Could you send me the patched Win32::API? I've run into the same problems you had. Thank you. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ (broken) http://phpwiki.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: win32::api on cygwin
Dan, Sorry if you posted this to the list and I didn't reply. I have had very little time to keep up with the Cygwin list lately. I have uploaded Reini's version of Win32::API to a http server. http://www.btinternet.com/~jasebob.pearce/cygwin/Win32-API-0.42.tar.gz There is also the cygwin packages I use to distribute this with setup inside my company. http://www.btinternet.com/~jasebob.pearce/cygwin/release/perl/perl-Win32-API/ enjoy. Sopher, Dan wrote: Hi there, I came across your posts regarding Win32::API on Cygwin. Unfortunately, Reini's link for the patch is broken. Could you send me the patched Win32::API? I've run into the same problems you had. Thank you. Regards, Dan Sopher -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Launching a cygwin binary from an application using CreateProcess Win32 API.
Venaktesh Goapal wrote > Hi, > > I tried what is mentioned in the subject above but > have not been successful. > > CreateProcess(...) returns the error 1305. > > From Winerror.h > > #define ERROR_UNKNOWN_REVISION 1305L > > Has someone tried this, or know the reason for the > error. > > Thanks, > Venkatesh. I think Christopher is right.Use ShellExecute() WinExec or (if you use C) _spawn... and _execThey get less parameters and do the same work foe simple processes. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Launching a cygwin binary from an application using CreateProcess Win32 API.
On Tue, Jun 07, 2005 at 12:27:54PM -0700, Venkatesh Gopal wrote: >Hi, > >I tried what is mentioned in the subject above but >have not been successful. > >CreateProcess(...) returns the error 1305. > >From Winerror.h > >#define ERROR_UNKNOWN_REVISION 1305L > >Has someone tried this, or know the reason for the >error. Anyone can try this very easily by just double clicking on the Cygwin icon or typing (e.g.) c:\cygwin\bin\ls.exe . These would illustrate cygwin binaries being started by CreateProcess. You undoubtedly did not fill out some field or argument correctly when invoking CreateProcess. It's difficult to know exactly what might be wrong since you didn't provide any details. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Launching a cygwin binary from an application using CreateProcess Win32 API.
Hi, I tried what is mentioned in the subject above but have not been successful. CreateProcess(...) returns the error 1305. >From Winerror.h #define ERROR_UNKNOWN_REVISION 1305L Has someone tried this, or know the reason for the error. Thanks, Venkatesh. __ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API perl module
Jason Pearce wrote: I just compiled what Reini posted, it compiled out of the box for me. http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.41-cygwin.patch => http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.42.tar.gz I actually just used the .tar.gz, and didn't even bother runing the patch. Ok, thanks. I'll try to include this alongside with libwin32 with the next perl relase which will be version 5.8.6. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API perl module
I just compiled what Reini posted, it compiled out of the box for me. http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.41-cygwin.patch => http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.42.tar.gz I actually just used the .tar.gz, and didn't even bother runing the patch. Jason Gerrit P. Haase wrote: Jason Pearce wrote: For what its worth, here is the binary install I am using. Its working nicely via setup.exe. I just pasted this at the bottom of my setup.exe Would you also send me a patchfile with all changes you finally used to build the module, please? Gerrit -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API perl module
Jason Pearce wrote: For what its worth, here is the binary install I am using. Its working nicely via setup.exe. I just pasted this at the bottom of my setup.exe Would you also send me a patchfile with all changes you finally used to build the module, please? Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API perl module
For what its worth, here is the binary install I am using. Its working nicely via setup.exe. I just pasted this at the bottom of my setup.exe @ perl-Win32API sdesc: ":API perl module compile for perl 5.8.2" ldesc: "Win32::API perl module compile for perl 5.8.2" category: misc requires: perl version: 0.42-1 install: release/perl/perl-Win32API/perl-Win32API-0.42-1.tar.bz2 41047 3042c5bc313a37c4b1da641369211965 I've atached the .tar.bz directly to this message - its not that big, hope its OK. But note it will probably only work for perl v5.8.2. Reini Urban wrote: Jason Pearce schrieb: This worked a treat Reini, thanks very much for your help. I need this on several machines at work, so I will package it up in a tar.bz2 for use with setup.exe. Once tested I'll post it back here. Well packaging is easy, but IMHO not before enabling W32 Callbacks. Otherwise I would have proposed it by myself. But if people want it without callbacks I could propose it. BTW: I'd rather prefer pmoore's FFI or the C-DynaLib-0.55, which work like a charm with w32 and cdecl callbacks and don't use such a horrible and MSVC-only aldo-style hack. Or any other libffi or ffcall based FFI solution, which can be used for Win32::API callbacks. perl-Win32API-0.42-1.tar.bz2 Description: BZip2 compressed data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API perl module
Jason Pearce schrieb: This worked a treat Reini, thanks very much for your help. I need this on several machines at work, so I will package it up in a tar.bz2 for use with setup.exe. Once tested I'll post it back here. Well packaging is easy, but IMHO not before enabling W32 Callbacks. Otherwise I would have proposed it by myself. But if people want it without callbacks I could propose it. BTW: I'd rather prefer pmoore's FFI or the C-DynaLib-0.55, which work like a charm with w32 and cdecl callbacks and don't use such a horrible and MSVC-only aldo-style hack. Or any other libffi or ffcall based FFI solution, which can be used for Win32::API callbacks. Reini Urban wrote: Jason Pearce schrieb: I have been trying to compile up Win32::API perl module under Cygwin's perl. The latest version off CPAN doesn't build (see below). >>> http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.41-cygwin.patch => http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.42.tar.gz just the new-style win32 callbacks do not work that way with gcc. old style it worked, but backporting seemed to much effort for me. I have found some refernces to patches people have applied to get it working in the past. In particular Win32:API version 0.20. http://anfaenger.de/cygwin/libwin32/Win32-API-0.20cygwin/ But I was unable to get that working either, maybe because the Cygwin.dll and/or Perl (v5.8.2) has moved on since that patch was done? I was wondering if anyone has got it working for themselves? If not, I'd really appreciate someone taking a look. I am happy to do some of my own dirty work, but I have little knowledge of the Cygwin.dll so I really struggle to know where to look. I gather Win32::API is relying on a hook that the Cygwin.dll is not providing? All I really need this for is to call a procedure in a DLL, that does some port IO for me. At the moment my work around is to use Active State perl, for which Win32::API does build, but it would be better to only have one version of Perl around. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API perl module
This worked a treat Reini, thanks very much for your help. I need this on several machines at work, so I will package it up in a tar.bz2 for use with setup.exe. Once tested I'll post it back here. Regards, Jason Reini Urban wrote: Jason Pearce schrieb: I have been trying to compile up Win32::API perl module under Cygwin's perl. The latest version off CPAN doesn't build (see below). http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.41-cygwin.patch => http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.42.tar.gz just the new-style win32 callbacks do not work that way with gcc. old style it worked, but backporting seemed to much effort for me. I have found some refernces to patches people have applied to get it working in the past. In particular Win32:API version 0.20. http://anfaenger.de/cygwin/libwin32/Win32-API-0.20cygwin/ But I was unable to get that working either, maybe because the Cygwin.dll and/or Perl (v5.8.2) has moved on since that patch was done? I was wondering if anyone has got it working for themselves? If not, I'd really appreciate someone taking a look. I am happy to do some of my own dirty work, but I have little knowledge of the Cygwin.dll so I really struggle to know where to look. I gather Win32::API is relying on a hook that the Cygwin.dll is not providing? All I really need this for is to call a procedure in a DLL, that does some port IO for me. At the moment my work around is to use Active State perl, for which Win32::API does build, but it would be better to only have one version of Perl around. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win32::API perl module
Jason Pearce schrieb: I have been trying to compile up Win32::API perl module under Cygwin's perl. The latest version off CPAN doesn't build (see below). http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.41-cygwin.patch => http://xarch.tu-graz.ac.at/home/rurban/software/perl/Win32-API-0.42.tar.gz just the new-style win32 callbacks do not work that way with gcc. old style it worked, but backporting seemed to much effort for me. I have found some refernces to patches people have applied to get it working in the past. In particular Win32:API version 0.20. http://anfaenger.de/cygwin/libwin32/Win32-API-0.20cygwin/ But I was unable to get that working either, maybe because the Cygwin.dll and/or Perl (v5.8.2) has moved on since that patch was done? I was wondering if anyone has got it working for themselves? If not, I'd really appreciate someone taking a look. I am happy to do some of my own dirty work, but I have little knowledge of the Cygwin.dll so I really struggle to know where to look. I gather Win32::API is relying on a hook that the Cygwin.dll is not providing? All I really need this for is to call a procedure in a DLL, that does some port IO for me. At the moment my work around is to use Active State perl, for which Win32::API does build, but it would be better to only have one version of Perl around. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Win32::API perl module
I have been trying to compile up Win32::API perl module under Cygwin's perl. The latest version off CPAN doesn't build (see below). I have found some refernces to patches people have applied to get it working in the past. In particular Win32:API version 0.20. http://anfaenger.de/cygwin/libwin32/Win32-API-0.20cygwin/ But I was unable to get that working either, maybe because the Cygwin.dll and/or Perl (v5.8.2) has moved on since that patch was done? I was wondering if anyone has got it working for themselves? If not, I'd really appreciate someone taking a look. I am happy to do some of my own dirty work, but I have little knowledge of the Cygwin.dll so I really struggle to know where to look. I gather Win32::API is relying on a hook that the Cygwin.dll is not providing? All I really need this for is to call a procedure in a DLL, that does some port IO for me. At the moment my work around is to use Active State perl, for which Win32::API does build, but it would be better to only have one version of Perl around. Regards, Jason [/tmp/Win32-API-0.40]$ perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for Win32::API::Callback Writing Makefile for Win32::API [/tmp/Win32-API-0.40]$ make cp Type.pm blib/lib/Win32/API/Type.pm cp Callback.pm blib/lib/Win32/API/Callback.pm cp Struct.pm blib/lib/Win32/API/Struct.pm cp API.pm blib/lib/Win32/API.pm make[1]: Entering directory `/tmp/Win32-API-0.40/Callback' /usr/bin/perl.exe /usr/lib/perl5/5.8.2/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.2/ExtUtils/typemap Callback.xs > Callback.xsc && mv Callback.xsc Callback.c gcc -c -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -DUSEIMPORTLIB -O2 -DVERSION=\"0.40\" -DXS_VERSION=\"0.40\" "-I/usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE" Callback.c Callback.xs: In function `XS_Win32__API__Callback_PushSelf': Callback.xs:893: warning: cast to pointer from integer of different size Callback.xs: In function `XS_Win32__API__Callback_DESTROY': Callback.xs:905: warning: cast to pointer from integer of different size Running Mkbootstrap for Win32::API::Callback () chmod 644 Callback.bs rm -f ../blib/arch/auto/Win32/API/Callback/Callback.dll LD_RUN_PATH="" ld2 -s -L/usr/local/lib Callback.o -o ../blib/arch/auto/Win32/API/Callback/Callback.dll /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/libperl.dll.a gcc -shared -o Callback.dll -Wl,--out-implib=libCallback.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \ -s -L/usr/local/lib Callback.o /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/libperl.dll.a Creating library file: libCallback.dll.a Callback.o(.text+0x87b):Callback.c: undefined reference to `_itoa' Callback.o(.text+0xf87):Callback.c: undefined reference to `_itoa' collect2: ld returned 1 exit status perlld: *** system() failed to execute gcc -shared -o Callback.dll -Wl,--out-implib=libCallback.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 \ -s -L/usr/local/lib Callback.o /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int/CORE/libperl.dll.a make[1]: *** [../blib/arch/auto/Win32/API/Callback/Callback.dll] Error 1 make[1]: Leaving directory `/tmp/Win32-API-0.40/Callback' make: *** [subdirs] Error 2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
Stephen wrote: > --- "Gerrit P. Haase" <[EMAIL PROTECTED]> wrote: >> Attached the diff what I scribbled together (most probably totally >> wrong, but it compiles now and most of the samples are working). >> Please tell me how your versin of Callback is working, mine is kaputt. > Thanks so much for your help. My end goal is to get ControlX10-CM17-0.07 > working on cygwin, and this is a big help. >> Remember to build also libwin32 for perl-5.8.5 (besides ODBC & OLE >> which isn't currently working for me), edit Makefile.PL to skip these >> two directories, not only because it is used for some of the samples, > I tried to compile libwin32-0.191 and I am getting: Undefined subroutine > &Win32::IsWinNT for the Process Directory. > I found a patch from an earlier cygwin post: > http://www.cygwin.com/ml/cygwin/2003-01/msg00594.html > I assume this will fix it. Is there any way we can get a new version with > this patch posted on cpan ? Use the version from the cygwin mirrors as reference. Package name is perl-libwin32. Gerrit -- =^..^= http://nyckelpiga.de/donate.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
Dave wrote:> Stephen More schrieb: >> I found a patch from an earlier cygwin post: > http://www.cygwin.com/ml/cygwin/2003-01/msg00594.html >> I assume this will fix it. Is there any way we can get a new version >> with this patch posted on cpan ? > I was able to get libwin32-0.191 to build with the latest Cygwin + gcc + > perl 5.8.5, using the patch cited above plus a couple of fixes of my > own, which I've attached. The resulting build did not pass all the > tests, but it works well enough to get me back in business wrt using > Win32::OLE in various perl scripts.> I hope this helps. There is a version of libwin32 available via the cygwin mirrors, including the patch and a build script, I suggest to use this as reference. I'll try to integrate your patch. What about my ODBC problem? Nobody else seeing this? Gerrit -- =^..^= http://nyckelpiga.de/donate.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
Stephen More schrieb:
> I found a patch from an earlier cygwin post:
http://www.cygwin.com/ml/cygwin/2003-01/msg00594.html
> I assume this will fix it. Is there any way we can get a new version
> with this patch posted on cpan ?
I was able to get libwin32-0.191 to build with the latest Cygwin + gcc +
perl 5.8.5, using the patch cited above plus a couple of fixes of my
own, which I've attached. The resulting build did not pass all the
tests, but it works well enough to get me back in business wrt using
Win32::OLE in various perl scripts.
I hope this helps.
--
Dave Yearke, [EMAIL PROTECTED]
"Things should be as simple as possible,
but no simpler." -- Albert Einstein
*** libwin32-0.191/Job/Job.xs.orig Sat Aug 14 22:48:19 2004
--- libwin32-0.191/Job/Job.xs Sat Aug 14 22:53:52 2004
***
*** 76,89
}
#undef TerminateJobObject
! BOOL TerminateJobObject(HANDLE hJob, UINT uExitCode)
{
if (kernel32_dll == NULL) { kernel32_init(); }
return (BOOL)(*kernel32_TerminateJobObject)(hJob, uExitCode);
}
#undef AssignProcessToJobObject
! BOOL AssignProcessToJobObject(HANDLE hJob, HANDLE hProcess)
{
if (kernel32_dll == NULL) { kernel32_init(); }
return (BOOL)(*kernel32_AssignProcessToJobObject)(hJob, hProcess);
--- 76,89
}
#undef TerminateJobObject
! BOOL WINAPI TerminateJobObject(HANDLE hJob, UINT uExitCode)
{
if (kernel32_dll == NULL) { kernel32_init(); }
return (BOOL)(*kernel32_TerminateJobObject)(hJob, uExitCode);
}
#undef AssignProcessToJobObject
! BOOL WINAPI AssignProcessToJobObject(HANDLE hJob, HANDLE hProcess)
{
if (kernel32_dll == NULL) { kernel32_init(); }
return (BOOL)(*kernel32_AssignProcessToJobObject)(hJob, hProcess);
*** libwin32-0.191/OLE/OLE.xs.orig Sat Aug 14 22:48:19 2004
--- libwin32-0.191/OLE/OLE.xs Sat Aug 14 22:58:24 2004
***
*** 51,56
--- 51,57
# include
# include
# include
+ # include
# define _wcscmpi _wcsicmp
int _wcsicmp(const wchar_t*, const wchar_t*); /* likewise */
long _wtol (const wchar_t*); /* from mingw stdlib.h */
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
Stephen More schrieb: I found a patch from an earlier cygwin post: http://www.cygwin.com/ml/cygwin/2003-01/msg00594.html I assume this will fix it. Is there any way we can get a new version with this patch posted on cpan ? Don't expect that. Aldo didn't accept any gcc and MakeMaker patches in the last years for his projects. Not for Win32::API and not for Win32::GUI, though they exist. Several people tried that before. He can only do MSVC ActiveState builds. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
Stephen More schrieb: I am trying to get Win32-API to compile under cygwin. http://search.cpan.org/~acalpini/Win32-API-0.41/API.pm So far I have changed itoa to use sprintf. Now I am trying to convert the inline assembly written in intel syntax to AT&T syntax so gcc can compile it. Can anyone help me with this assembly conversion ? I have a private version at http://xarch.tu-graz.ac.at/home/rurban/software/perl/ Win32-API-0.41-cygwin.patch and Win32-API-0.42.tar.gz The callbacks don't work yet with the 0.4x branch with gcc. With the 0.2x methods it worked okay. See http://www.risacher.org/Win32-API/ -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
Stephen More schrieb: I am trying to get Win32-API to compile under cygwin. http://search.cpan.org/~acalpini/Win32-API-0.41/API.pm So far I have changed itoa to use sprintf. Now I am trying to convert the inline assembly written in intel syntax to AT&T syntax so gcc can compile it. Can anyone help me with this assembly conversion ? BTW: The C::DynaLib version works fine and is much better than Aldo's version. Only the dynamic libc.so test fails, but this can be ignored. (patch already on rt.cpan.org) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
--- "Gerrit P. Haase" <[EMAIL PROTECTED]> wrote: > Attached the diff what I scribbled together (most probably totally > wrong, but it compiles now and most of the samples are working). > Please tell me how your versin of Callback is working, mine is kaputt. Thanks so much for your help. My end goal is to get ControlX10-CM17-0.07 working on cygwin, and this is a big help. > Remember to build also libwin32 for perl-5.8.5 (besides ODBC & OLE > which isn't currently working for me), edit Makefile.PL to skip these > two directories, not only because it is used for some of the samples, I tried to compile libwin32-0.191 and I am getting: Undefined subroutine &Win32::IsWinNT for the Process Directory. I found a patch from an earlier cygwin post: http://www.cygwin.com/ml/cygwin/2003-01/msg00594.html I assume this will fix it. Is there any way we can get a new version with this patch posted on cpan ? -Thanks Steve More __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
Hello Stephen, > I am trying to get Win32-API to compile under cygwin. > http://search.cpan.org/~acalpini/Win32-API-0.41/API.pm > So far I have changed itoa to use sprintf. > Now I am trying to convert the inline assembly written in intel syntax to > AT&T syntax so gcc can compile it. > Can anyone help me with this assembly conversion ? I started here: http://www.delorie.com/djgpp/doc/brennan/brennan_att_inline_djgpp.html And then found this very useful: http://www.hackemate.com.ar/textos/papers/Gcc%20Inline%20Assembly%20-%20How%20to%20-%20eng/inline-1.html Attached the diff what I scribbled together (most probably totally wrong, but it compiles now and most of the samples are working). Please tell me how your versin of Callback is working, mine is kaputt. After `perl Makefile.PL` modify the Makefile to include the local TYPEMAP file instead of the global like this in the # --- MakeMaker tool_xsubpp section: [...] XSUBPPARGS = -typemap ./TYPEMAP Note: `make test` isn't working with this package. About the patches: The itoa hack was taken from the libwin32 package available at the mirrors, however the Callback sample scripts are not working, so it seems that Callback is broken, the other examples are working (more or less, got strange results with hideconsole.pl). Remember to build also libwin32 for perl-5.8.5 (besides ODBC & OLE which isn't currently working for me), edit Makefile.PL to skip these two directories, not only because it is used for some of the samples, I think it is useful anyway. Gerrit -- =^..^= TYPEMAP.patch Description: Binary data API.xs.patch Description: Binary data API.h.patch Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Help to compile an activestate perl module under cygwin ( Win32-API & assembly )
I am trying to get Win32-API to compile under cygwin. http://search.cpan.org/~acalpini/Win32-API-0.41/API.pm So far I have changed itoa to use sprintf. Now I am trying to convert the inline assembly written in intel syntax to AT&T syntax so gcc can compile it. Can anyone help me with this assembly conversion ? -Thanks Steve More __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems using WIN32 api
Laurent, [...] > - are the /usr/lib/w32api/libXXX.a real static libs (with code) >or only interface to the system DLLs? [...] Most of them are "interface to the system DLLs" (or import libs as a previous post states). For a complete answer, one would "nm | grep __imp" on each of them to see which is such an interface. On my 1.3.x cygwin here, for your libuser32.a case, I have "$ nm /lib/w32api/libuser32.a | grep __imp | wc -l 582 " [...] > - is someone interested in a glib/gtk+ cygwin package >(not a native Win32 one)? [...] It seems not to be a general interest on this, as the posts related are quite rare Here, no longer than yesterday, I was in the state to cry out on this list on the same topic, i.e. while building the same gtk+-2 I faced the problem of (devel) libtool not being able to link (only) libuuid in the shared gdk. Actually, before starting typing the message, I just recalled that there was a single "undefined" error when tried to link without it, so I turned on the patching-by-excluding/quick'n'dirty solution, which worked. SLao -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems using WIN32 api
On Thu, Nov 13, 2003 at 11:40:37AM -0600, Brian Ford wrote:
>I'll take a shot at a few of these I know.
>
>On Thu, 13 Nov 2003, zze-BDE balg011 VAUCHER Laurent DvSI/SIReS/GRE wrote:
>
>> I'm trying to understand how to build an application using
>> both Cygwin and (some) WIN32 APIs and I stumbled into a
>> problem using exactly whet the FAQ says (even if it says
>> it is not up to date).
>>
>> Example program : main.c
>> --
>> #include
>> int main(int arc, char *argv[])
>> {
>> BOOL sm;
>> /* The following function is in USER32.DLL */
>> SystemParametersInfo(SPI_GETFONTSMOOTHING, 0, &sm, 0);
>> return 0;
>> }
>>
>> I tried compiling like the FAQ says I should :
>> > gcc -o main main.c -luser32
>>
>WFM. Try gcc --verbose -o main main.c -luser32 and see what it is finding
>for -luser32.
>
>> All I get is "undefined reference to [EMAIL PROTECTED]"
>> Since it seems that the 'interface' libs live in /usr/lib/w32api,
>> I tried to add -L/usr/lib/w32api, but the result is the same.
>>
>They should be searched automatically.
As should libuser32.a. There is no reason to include it on the command line.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Problems using WIN32 api
I'll take a shot at a few of these I know.
On Thu, 13 Nov 2003, zze-BDE balg011 VAUCHER Laurent DvSI/SIReS/GRE wrote:
> I'm trying to understand how to build an application using
> both Cygwin and (some) WIN32 APIs and I stumbled into a
> problem using exactly whet the FAQ says (even if it says
> it is not up to date).
>
> Example program : main.c
> --
> #include
> int main(int arc, char *argv[])
> {
> BOOL sm;
> /* The following function is in USER32.DLL */
> SystemParametersInfo(SPI_GETFONTSMOOTHING, 0, &sm, 0);
> return 0;
> }
>
> I tried compiling like the FAQ says I should :
> > gcc -o main main.c -luser32
>
WFM. Try gcc --verbose -o main main.c -luser32 and see what it is finding
for -luser32.
> All I get is "undefined reference to [EMAIL PROTECTED]"
> Since it seems that the 'interface' libs live in /usr/lib/w32api,
> I tried to add -L/usr/lib/w32api, but the result is the same.
>
They should be searched automatically.
> In last resort, I did this awful thing :
> > gcc -o main main.c /usr/lib/w32api/libuser32.a
>
> which works !! But I'm still not satisfied with it, because
> it does not work on another libtool based project (pango),
> saying that I'm trying to include a static lib when building
> a dynamic one. So libtool refuses to pass things like
> /usr/lib/w32api/libuser32.a down to gcc and I need to
> repair the gcc command line manually.
>
> And I've got some more questions :
> - are the /usr/lib/w32api/libXXX.a real static libs (with code)
>or only interface to the system DLLs?
>
Import libs.
> - what's the difference with libXXX.dll.a?
>
Not sure.
> - why is -luser32 or -lgdi32 not honored?
>
They should be.
> - would it be difficult to create .la files for those
>Win32 api, so that libtool would be nice with them?
>
Probably not, but this is more a topic for [EMAIL PROTECTED] since
they maintain w32api.
> - is someone interested in a glib/gtk+ cygwin package
>(not a native Win32 one)?
>
Don't know.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Problems using WIN32 api
I'm trying to understand how to build an application using
both Cygwin and (some) WIN32 APIs and I stumbled into a
problem using exactly whet the FAQ says (even if it says
it is not up to date).
Example program : main.c
--
#include
int main(int arc, char *argv[])
{
BOOL sm;
/* The following function is in USER32.DLL */
SystemParametersInfo(SPI_GETFONTSMOOTHING, 0, &sm, 0);
return 0;
}
I tried compiling like the FAQ says I should :
> gcc -o main main.c -luser32
All I get is "undefined reference to [EMAIL PROTECTED]"
Since it seems that the 'interface' libs live in /usr/lib/w32api,
I tried to add -L/usr/lib/w32api, but the result is the same.
In last resort, I did this awful thing :
> gcc -o main main.c /usr/lib/w32api/libuser32.a
which works !! But I'm still not satisfied with it, because
it does not work on another libtool based project (pango),
saying that I'm trying to include a static lib when building
a dynamic one. So libtool refuses to pass things like
/usr/lib/w32api/libuser32.a down to gcc and I need to
repair the gcc command line manually.
And I've got some more questions :
- are the /usr/lib/w32api/libXXX.a real static libs (with code)
or only interface to the system DLLs?
- what's the difference with libXXX.dll.a?
- why is -luser32 or -lgdi32 not honored?
- would it be difficult to create .la files for those
Win32 api, so that libtool would be nice with them?
- is someone interested in a glib/gtk+ cygwin package
(not a native Win32 one)?
Laurent Vaucher.
cygcheck.out
Description: cygcheck.out
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Win32::API perl module
I have ported the Win32::API perl module to Cygwin (or more properly,
to GCC, since it was mainly the Intel-style _asm{} code that didn't
work). So far, I have not tested it extensively, and am still trying
to track down the original author of the module to get his blessing.
Meanwhile, if people would like to test this module, my changed
version can be downloaded from
http://risacher.yi.org/Win32-API-0.21.tar.gz , or
http://risacher.hn.org/Win32-API-0.21.tar.gz (if yi.org is being
flaky, which it seems to be at the moment.).
I didn't know any DLL calls that used single-precision floating point
arguments or return values, so that part of the code is untested. If
someone can please test this out, I would appreciate it. It would
also be good if someone could test it under MSVC++ and the non-cygwin
version of perl to make sure I haven't messed that code up at all.
Also note that for me, I had to patch
/usr/lib/perl5/5.6.1/cygwin/CORE/perl.h to make this work. The (tiny)
patch for this file is include in my tarball. I suspect that this may
not be necessary for more recent versions of Cygwin.
Thanks.
- Dan Risacher
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: win32 api
Microsoft's MSDN is available online at msdn.microsoft.com. Probably someone should setup a specific project to work on free documentation for w32api which can be distributed with w32api like the glibc info pages and man pages are distributed with glibc. ReactOS is doing such documentation, but as they have a kernel to work on too, it's quite a task :}. Rob === - Original Message - From: "Jean le Roux" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 11, 2002 9:20 PM Subject: win32 api > Hi all > > Does anyone know where I can find some references to API calls such > as those exported with /usr/include/w32api/winreg.h ? I'm rather > curious as to what the parameters are intended for... not all of them > are obvious. > > Thanx > > -- > Jean le Roux > Binary Entropy Catalyst > > Fairy Tale, n.: > A horror story to prepare children for the newspapers. > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
win32 api
Hi all Does anyone know where I can find some references to API calls such as those exported with /usr/include/w32api/winreg.h ? I'm rather curious as to what the parameters are intended for... not all of them are obvious. Thanx -- Jean le Roux Binary Entropy Catalyst Fairy Tale, n.: A horror story to prepare children for the newspapers. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
