Executable Script Runner (was: DevKit stuff)
Luis Lavena
> On Sat, Jan 23, 2010 at 6:15 PM, Luis Lavena <luisl...@gmail.com> wrote:
>> I believe something like the console host I've implemented in
>> mongrel_service will need to be added:
>>
>> http://github.com/fauna/mongrel_service/blob/master/src/ServiceFB/ServiceFB_Utils.bas#L267-320
>
> Actually, turned out you were right. :) Using SetConsoleCtrlHandler
> directly allows me to also ignore Ctrl+Break, which in turn means that
> children can handle Ctrl+Break now and runner wouldn't unexpectedly
> exit under them. :) Just pushed it.
>
Nice!
This can be combined with a Windows-only addition to RubyGems to deal
with loading of bundled DLLs:
http://rubyforge.org/pipermail/rubygems-developers/2008-November/004256.html
The function is going to provide a simpler way for gem authors that
bundle dlls (like nokogiri and others) and use with LoadLibraryEx to
load these dlls without altering the user PATH.
--
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
Alexey Borzenkov
> This can be combined with a Windows-only addition to RubyGems to deal
> with loading of bundled DLLs:
>
> http://rubyforge.org/pipermail/rubygems-developers/2008-November/004256.html
>
> The function is going to provide a simpler way for gem authors that
> bundle dlls (like nokogiri and others) and use with LoadLibraryEx to
> load these dlls without altering the user PATH.
Actually, when I think about it, alternate search path makes much more
sense (so that if we load module.so that depends on dependency.dll
that is placed next to it, then it should be loaded). The only problem
is that it's either application directory or module directory, not
both. It means that libraries loaded with
LOAD_WITH_ALTERED_SEARCH_PATH cannot safely depend on anything in
ruby\bin directory, unless it is already loaded (as in
msvcrt-ruby1x.dll is ok). This sucks. :(
Luis Lavena
I know.
I need to do some more testing, but A full path can be used with
LoadLibraryEx without setting LOAD_WITH_ALTERED_SEARCH_PATH, need more
scenarios, time, love and money ;-)
Alexey Borzenkov
> I need to do some more testing, but A full path can be used with
> LoadLibraryEx without setting LOAD_WITH_ALTERED_SEARCH_PATH, need more
> scenarios, time, love and money ;-)
No, LOAD_WITH_ALTERED_SEARCH_PATH doesn't change the way how dll that
you specified is loaded. What it does is change how dlls that that dll
depends on are searched. For example:
bin\someapp.exe - application
here\is\my\module\module.dll
here\is\my\module\dependency.dll
if module.dll depends on dependency.dll and you try to LoadLibrary it
(even with full path), I think it will fail (because unless
here\is\my\module is in PATH documentation suggests it's never
searched). LOAD_WITH_ALTERED_SEARCH_PATH changes search path to look
in here\is\my\module\ instead of bin\ for dependencies for the
duration of LoadLibraryEx loading modules (before it starts invoking
entry points). At least that's what documentation says, I haven't
tested it myself. See
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx. As
documentation says LOAD_WITH_ALRERED_SEARCH_PATH only works with full
filenames.