Hi all, I''ve been spending a little time delving into the latest Ruby installer and win32utils, several of which are needed by the project I''m working on - Watir. We have requirements for some of the process libs which need the base apis, etc. It appears currently that we need to do one of two things - either require the platform (mswin32) or install the devkit to successfully install and use Watir gems in the current Ruby installer setup. For development that''s fine, but that''s also the current case for the enduser. For this project are you planning on releasing mingw gems or fat binaries, I''m trying to gauge what the impact to our users will be. Like I say, I''ve just started looking at this and would be happy to help with anything that''s needed, so my questions may be a bit naive as I dive into this. This also seems to be cross cutting between this project and then the rubyinstaller in general which should cause a bit of chaos which I''ll also try to help out with. -Charley Lead Developer - Watir On Fri, Dec 18, 2009 at 9:16 PM, Daniel Berger <djberg96 at gmail.com> wrote:> All, > > I''ve put win32-process up on github: > > http://github.com/djberg96/win32-process > > Heesob, I''ve added you as a collaborator. > > Note that the current code on github is actually ahead of the current gem. > I > haven''t quite finished one or two things, namely setrlimit and > set_affinity. > > Regards, > > Dan > > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20091229/0d0172e6/attachment.html>
On 29 Dec 2009, at 18:58, Charley Baker wrote:> Hi all, > > I''ve been spending a little time delving into the latest Ruby installer and win32utils, several of which are needed by the project I''m working on - Watir. We have requirements for some of the process libs which need the base apis, etc. It appears currently that we need to do one of two things - either require the platform (mswin32) or install the devkit to successfully install and use Watir gems in the current Ruby installer setup. For development that''s fine, but that''s also the current case for the enduser. > > For this project are you planning on releasing mingw gems or fat binaries, I''m trying to gauge what the impact to our users will be. Like I say, I''ve just started looking at this and would be happy to help with anything that''s needed, so my questions may be a bit naive as I dive into this.There are some big issues here generally. Any library that uses SEH cannot be compiled with gcc (read: won''t compile under the new ruby installer builds). AFAIK this directly affects win32-api, and iirc, win32-process, possibly win32-service too. You can install the mswin32-60 builds of these, via: gem install --platform=x86-mswin32-60 win32-api Obviously this is somewhat of a hacky solution, but one we can''t really avoid. As there are no plans globally to make gcc build SEH, and the hacky solutions don''t tend to work correctly, I would advise that these projects take the following approach: 1. Build all libs that can be built for mingw, under mingw, using the devkit. 2. Libs that require an MS compiler for SEH, should be built with those, and binary gems should be released for the mingw platform, using these builds (as this is ABI compatible, and produces valid code). 3. Where possible, wrap up the above processes via rake-compiler. I am sure that there are others that might want to weigh in on this, Luis in particular, but this is the only valid option I know of at this time.> > This also seems to be cross cutting between this project and then the rubyinstaller in general which should cause a bit of chaos which I''ll also try to help out with. > > -Charley > Lead Developer - Watir-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20091229/37e88958/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3679 bytes Desc: not available URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20091229/37e88958/attachment-0001.bin>
Does anyone else care to weigh in? Responses inline. Charley Baker Lead Developer, Watir, http://watir.com On Tue, Dec 29, 2009 at 4:09 PM, James Tucker <jftucker at gmail.com> wrote:> > On 29 Dec 2009, at 18:58, Charley Baker wrote: > > Hi all, > > I''ve been spending a little time delving into the latest Ruby installer > and win32utils, several of which are needed by the project I''m working on - > Watir. We have requirements for some of the process libs which need the base > apis, etc. It appears currently that we need to do one of two things - > either require the platform (mswin32) or install the devkit to successfully > install and use Watir gems in the current Ruby installer setup. For > development that''s fine, but that''s also the current case for the enduser. > > For this project are you planning on releasing mingw gems or fat binaries, > I''m trying to gauge what the impact to our users will be. Like I say, I''ve > just started looking at this and would be happy to help with anything that''s > needed, so my questions may be a bit naive as I dive into this. > > > There are some big issues here generally. Any library that uses SEH cannot > be compiled with gcc (read: won''t compile under the new ruby installer > builds). AFAIK this directly affects win32-api, and iirc, win32-process, > possibly win32-service too. >Don''t know what SEH means. I''m sure I''m missing an obvious TLA :P, but I don''t understand that.> > You can install the mswin32-60 builds of these, via: > > gem install --platform=x86-mswin32-60 win32-api > > Obviously this is somewhat of a hacky solution, but one we can''t really > avoid. > > I realize that, and mentioned as much. It''s kind of a crummy step toinvolve less technically savvy users, who simply want to install a gem that works regardless. Is this the ideal plan when the new ruby installer rolls out?> As there are no plans globally to make gcc build SEH, and the hacky > solutions don''t tend to work correctly, I would advise that these projects > take the following approach: > > 1. Build all libs that can be built for mingw, under mingw, using the > devkit. > 2. Libs that require an MS compiler for SEH, should be built with those, > and binary gems should be released for the mingw platform, using these > builds (as this is ABI compatible, and produces valid code). > 3. Where possible, wrap up the above processes via rake-compiler. >Which projects are you referring to when you say "these projects"? I''m just looking at dependencies, and win32utils is a big one. It''s not up to me to recompile all of our dependent libs. Still confused, is there a short, medium and long term answer?> I am sure that there are others that might want to weigh in on this, Luis > in particular, but this is the only valid option I know of at this time. > > > This also seems to be cross cutting between this project and then the > rubyinstaller in general which should cause a bit of chaos which I''ll also > try to help out with. > > -Charley > Lead Developer - Watir > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20091230/6d9ff835/attachment.html>
On Tue, Dec 29, 2009 at 8:09 PM, James Tucker <jftucker at gmail.com> wrote:> [...] > > There are some big issues here generally. Any library that uses SEH cannot > be compiled with gcc (read: won''t compile under the new ruby installer > builds). AFAIK this directly affects win32-api, and iirc, win32-process, > possibly win32-service too.AFAIK, this only applies to C++ code, not C win32utils is moving from pure C to FFI implementation, or at least that was the last time I heard about it. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
On 30 Dec 2009, at 20:01, Charley Baker wrote:> Does anyone else care to weigh in? Responses inline. > > Charley Baker > Lead Developer, Watir, http://watir.com > > > On Tue, Dec 29, 2009 at 4:09 PM, James Tucker <jftucker at gmail.com> wrote: > > On 29 Dec 2009, at 18:58, Charley Baker wrote: > >> Hi all, >> >> I''ve been spending a little time delving into the latest Ruby installer and win32utils, several of which are needed by the project I''m working on - Watir. We have requirements for some of the process libs which need the base apis, etc. It appears currently that we need to do one of two things - either require the platform (mswin32) or install the devkit to successfully install and use Watir gems in the current Ruby installer setup. For development that''s fine, but that''s also the current case for the enduser. >> >> For this project are you planning on releasing mingw gems or fat binaries, I''m trying to gauge what the impact to our users will be. Like I say, I''ve just started looking at this and would be happy to help with anything that''s needed, so my questions may be a bit naive as I dive into this. > > There are some big issues here generally. Any library that uses SEH cannot be compiled with gcc (read: won''t compile under the new ruby installer builds). AFAIK this directly affects win32-api, and iirc, win32-process, possibly win32-service too. > > > Don''t know what SEH means. I''m sure I''m missing an obvious TLA :P, but I don''t understand that.Structured Error Handling: http://msdn.microsoft.com/en-us/library/ms680657(VS.85).aspx This is actually implemented as compiler extensions (contrary to the C/C++ specs), and as such, gcc cannot correctly compile applications or libraries that use it. Some of the Windows APIs require the use of SEH, and as such *must* be compiled with a Microsoft compiler. Typically, the symptom you will see manifest in these cases is an undefined symbol error on compile, for __try. Other gory details can be found here: http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh http://www.programmingunlimited.net/siteexec/content.cgi?page=libseh (this one is new, and might actually be a solution! (Luis - some input here if you can?)) Old threads: http://lists-archives.org/mingw-users/04725-structured-exception-handling.html I''ve not done any more research on this in a long time, as I''ve not had to support any significant ruby stuff on windows for the best part of the last year - so some fresh research would be recommended!> You can install the mswin32-60 builds of these, via: > > gem install --platform=x86-mswin32-60 win32-api > > Obviously this is somewhat of a hacky solution, but one we can''t really avoid. > > I realize that, and mentioned as much. It''s kind of a crummy step to involve less technically savvy users, who simply want to install a gem that works regardless. Is this the ideal plan when the new ruby installer rolls out?Well, unless the new libseh thing above can actually solve the problem, then no, the only way to solve this is for the relevant projects that must use SEH in order to work, release msvc6 compiled binary versions of their gems, with a falsified platform of "mingw".> As there are no plans globally to make gcc build SEH, and the hacky solutions don''t tend to work correctly, I would advise that these projects take the following approach:The above may now be misinformation, please disregard it, and take a look at libseh.> > 1. Build all libs that can be built for mingw, under mingw, using the devkit. > 2. Libs that require an MS compiler for SEH, should be built with those, and binary gems should be released for the mingw platform, using these builds (as this is ABI compatible, and produces valid code). > 3. Where possible, wrap up the above processes via rake-compiler. > > > Which projects are you referring to when you say "these projects"? I''m just looking at dependencies, and win32utils is a big one. It''s not up to me to recompile all of our dependent libs. Still confused, is there a short, medium and long term answer?Any projects which use SEH. I can understand how none of that would have made sense until one looked up SEH.> I am sure that there are others that might want to weigh in on this, Luis in particular, but this is the only valid option I know of at this time. > >> >> This also seems to be cross cutting between this project and then the rubyinstaller in general which should cause a bit of chaos which I''ll also try to help out with.Best thing to do to help out is to try and get these things building under the mingw devkit, and help Luis complete / enhance the devkit too. Inclusion of libseh, pending some successful tests, would be one such important enhancement to get you on your way to smooth sailing for your users. Luis valiantly puts a lot of time into this stuff, and I''d encourage anyone to help out when + where they can. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20091231/2d6e797c/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3679 bytes Desc: not available URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20091231/2d6e797c/attachment-0001.bin>
Hey James, Thanks for the explanation. Comments inline. On Thu, Dec 31, 2009 at 6:46 AM, James Tucker <jftucker at gmail.com> wrote:> > On 30 Dec 2009, at 20:01, Charley Baker wrote: > > Does anyone else care to weigh in? Responses inline. > > Charley Baker > Lead Developer, Watir, http://watir.com > > > On Tue, Dec 29, 2009 at 4:09 PM, James Tucker <jftucker at gmail.com> wrote: > >> >> On 29 Dec 2009, at 18:58, Charley Baker wrote: >> >> Hi all, >> >> I''ve been spending a little time delving into the latest Ruby installer >> and win32utils, several of which are needed by the project I''m working on - >> Watir. We have requirements for some of the process libs which need the base >> apis, etc. It appears currently that we need to do one of two things - >> either require the platform (mswin32) or install the devkit to successfully >> install and use Watir gems in the current Ruby installer setup. For >> development that''s fine, but that''s also the current case for the enduser. >> >> For this project are you planning on releasing mingw gems or fat >> binaries, I''m trying to gauge what the impact to our users will be. Like I >> say, I''ve just started looking at this and would be happy to help with >> anything that''s needed, so my questions may be a bit naive as I dive into >> this. >> >> >> There are some big issues here generally. Any library that uses SEH cannot >> be compiled with gcc (read: won''t compile under the new ruby installer >> builds). AFAIK this directly affects win32-api, and iirc, win32-process, >> possibly win32-service too. >> > > > Don''t know what SEH means. I''m sure I''m missing an obvious TLA :P, but I > don''t understand that. > > > Structured Error Handling: > http://msdn.microsoft.com/en-us/library/ms680657(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ms680657%28VS.85%29.aspx> > > This is actually implemented as compiler extensions (contrary to the C/C++ > specs), and as such, gcc cannot correctly compile applications or libraries > that use it. Some of the Windows APIs require the use of SEH, and as such > *must* be compiled with a Microsoft compiler. > > Typically, the symptom you will see manifest in these cases is an undefined > symbol error on compile, for __try. > > Other gory details can be found here: > > http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh > http://www.programmingunlimited.net/siteexec/content.cgi?page=libseh > (this one is new, and might actually be a solution! (Luis - some input here > if you can?)) > > Old threads: > > > http://lists-archives.org/mingw-users/04725-structured-exception-handling.html > > I''ve not done any more research on this in a long time, as I''ve not had to > support any significant ruby stuff on windows for the best part of the last > year - so some fresh research would be recommended! >Very cool, thanks for the references. It''s been a long time since I did a lot of Windows programming, and though I used C/C++ never delved into SEH. I do now remember seeing at the time though.> > You can install the mswin32-60 builds of these, via: >> >> gem install --platform=x86-mswin32-60 win32-api >> >> Obviously this is somewhat of a hacky solution, but one we can''t really >> avoid. >> >> I realize that, and mentioned as much. It''s kind of a crummy step to > involve less technically savvy users, who simply want to install a gem that > works regardless. Is this the ideal plan when the new ruby installer rolls > out? > > > Well, unless the new libseh thing above can actually solve the problem, > then no, the only way to solve this is for the relevant projects that must > use SEH in order to work, release msvc6 compiled binary versions of their > gems, with a falsified platform of "mingw". >Ok, now that I get it, I haven''t checked out the win32utils source that we''re using, but it sounds like the code is using SEH for some of the api calls? From some of the threads I''ve been reading, since the msvc6 libs and the mingw libs should both be compiled against the same version of the c runtime - msvcrt.dll, then that should theoretically cause problems? Falsifying the platform sounds a bit dodgy, but will make install easier for newbs avoiding the platform flag. Ideally I still want to say ''gem install watir'' will work without any machinations, hedging or confusion, that''s the use case. Anything trickier starts to pile up an already large backlog of user questions and support.> > > As there are no plans globally to make gcc build SEH, and the hacky >> solutions don''t tend to work correctly, I would advise that these projects >> take the following approach: >> > > The above may now be misinformation, please disregard it, and take a look > at libseh. >Warning on the site that''s it potentially alpha grade and there are some differences. However, it does look generally promising if that''s what''s required to compile the libs.> > >> 1. Build all libs that can be built for mingw, under mingw, using the >> devkit. >> 2. Libs that require an MS compiler for SEH, should be built with those, >> and binary gems should be released for the mingw platform, using these >> builds (as this is ABI compatible, and produces valid code). >> 3. Where possible, wrap up the above processes via rake-compiler. >> > > > Which projects are you referring to when you say "these projects"? I''m just > looking at dependencies, and win32utils is a big one. It''s not up to me to > recompile all of our dependent libs. Still confused, is there a short, > medium and long term answer? > > > Any projects which use SEH. I can understand how none of that would have > made sense until one looked up SEH. > > I am sure that there are others that might want to weigh in on this, Luis >> in particular, but this is the only valid option I know of at this time. >> >> >> This also seems to be cross cutting between this project and then the >> rubyinstaller in general which should cause a bit of chaos which I''ll also >> try to help out with. >> >> > Best thing to do to help out is to try and get these things building under > the mingw devkit, and help Luis complete / enhance the devkit too. Inclusion > of libseh, pending some successful tests, would be one such important > enhancement to get you on your way to smooth sailing for your users. Luis > valiantly puts a lot of time into this stuff, and I''d encourage anyone to > help out when + where they can. >Luis is amazing and a non stop force in making Windows a less than 3rd class citizen on Ruby, Daniel for that matter as well. :) Given that Watir started out with Windows and IE as the primary target (still is in many respects with our user base), it''s been an uphill battle. I''m happy to help out in any way possible. It''s been a while since Windows programming was my primary job, but I''m diving into this a bit and hope to help. Cheers, Charley> > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/win32utils-devel/attachments/20091231/8339b267/attachment.html>
On 31 Dec 2009, at 21:07, Charley Baker wrote:> Ok, now that I get it, I haven''t checked out the win32utils source that we''re using, but it sounds like the code is using SEH for some of the api calls? From some of the threads I''ve been reading, since the msvc6 libs and the mingw libs should both be compiled against the same version of the c runtime - msvcrt.dll, then that should theoretically cause problems? Falsifying the platform sounds a bit dodgy, but will make install easier for newbs avoiding the platform flag.They run the same runtime, there shouldn''t be any problems at the ABI level, luckily, this is actually the purpose of mingw, over something like cygwin.> Ideally I still want to say ''gem install watir'' will work without any machinations, hedging or confusion, that''s the use case. Anything trickier starts to pile up an already large backlog of user questions and support.Yup, this is why my suggestion is that we get gem publish scripts into any of the win32 project gems that use SEH to publish vs6 flavours with mingw platform tags. This is the only way, other than somehow factoring out all SEH code, to make the above work smoothly. The only other possible alternative is to have them pre-bundled with the one-click, but then users will still end up referring to docs / this thread to realise they need to upgrade with a --platform=... force.> Luis is amazing and a non stop force in making Windows a less than 3rd class citizen on Ruby, Daniel for that matter as well. :) Given that Watir started out with Windows and IE as the primary target (still is in many respects with our user base), it''s been an uphill battle. I''m happy to help out in any way possible. It''s been a while since Windows programming was my primary job, but I''m diving into this a bit and hope to help.If it''s agreeable to everyone, the aforementioned changes to build and publish scripts would be quite easy to manage, addressing this problem has been on my (long) list of things to do for some time now - if someone else has a need and the time to do it, that''s fantastic.