From djberg96 at gmail.com  Thu Nov  4 10:52:59 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Thu, 4 Nov 2010 08:52:59 -0600
Subject: [Win32utils-devel] Fwd: win32/process - small bug?
In-Reply-To: <AANLkTimMVffB69sNGsGFVPwsy9Mf+T5aiz+vEcQBugHw@mail.gmail.com>
References: <AANLkTimMVffB69sNGsGFVPwsy9Mf+T5aiz+vEcQBugHw@mail.gmail.com>
Message-ID: <AANLkTim3kjP_U=0ZohWLZbaJobN2SPm9sGs1QBVZYoCy@mail.gmail.com>

It might be a bit before I can get to this, so I thought I'd pass it on.

Also, while I was stuck in the airport in Minneapolis, I decided that
the getrlimit method should be refactored to remove the process from
the job (if it wasn't already in one) after it's finished, if
possible.

Dan


---------- Forwarded message ----------
From: Ben Nagy <ben.nagy.web at gmail.com>
Date: Wed, Nov 3, 2010 at 11:53 PM
Subject: win32/process - small bug?
To: Daniel Berger <djberg96 at gmail.com>


Hi,

Very short note...

I don't know how to do git pull requests and blah blah blah. I just
fixed what I think is a bug in the win32/process code. You don't close
the thread handle when you kill with signal 1. In my case I had a
process monitor app that continued to think the PID was still alive,
because the system continued to grant handles to the dead PID.

Maybe the behaviour is intentional, I don't know. Anyway, hth.

Cheers,

ben

From djberg96 at gmail.com  Sun Nov  7 08:24:33 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 7 Nov 2010 06:24:33 -0700
Subject: [Win32utils-devel] win32/process - small bug?
In-Reply-To: <AANLkTim3kjP_U=0ZohWLZbaJobN2SPm9sGs1QBVZYoCy@mail.gmail.com>
References: <AANLkTimMVffB69sNGsGFVPwsy9Mf+T5aiz+vEcQBugHw@mail.gmail.com>
	<AANLkTim3kjP_U=0ZohWLZbaJobN2SPm9sGs1QBVZYoCy@mail.gmail.com>
Message-ID: <AANLkTim+BR9VTme2g1GdV_TN6O8aWcdPgLY1tLrRsB+1@mail.gmail.com>

--- a/lib/win32/process.rb
+++ b/lib/win32/process.rb
@@ -559,14 +559,12 @@ module Process
           else
             if handle != 0
               thread_id = [0].pack('L')
-              dll       = 'kernel32'
-              eproc     = 'ExitProcess'
-
+              begin
               thread = CreateRemoteThread(
                 handle,
                 0,
                 0,
-                GetProcAddress(GetModuleHandle(dll), eproc),
+                  GetProcAddress(GetModuleHandle('kernel32'), 'ExitProcess'),
                 0,
                 0,
                 thread_id
@@ -579,9 +577,12 @@ module Process
               else
                 raise Error, get_last_error
               end
+              ensure
+                CloseHandle(thread) if thread
+              end
             else
               raise Error, get_last_error
-          end
+          end # case

           @child_pids.delete(pid)
         end

On Thu, Nov 4, 2010 at 8:52 AM, Daniel Berger <djberg96 at gmail.com> wrote:
> It might be a bit before I can get to this, so I thought I'd pass it on.
>
> Also, while I was stuck in the airport in Minneapolis, I decided that
> the getrlimit method should be refactored to remove the process from
> the job (if it wasn't already in one) after it's finished, if
> possible.
>
> Dan
>
>
> ---------- Forwarded message ----------
> From: Ben Nagy <ben.nagy.web at gmail.com>
> Date: Wed, Nov 3, 2010 at 11:53 PM
> Subject: win32/process - small bug?
> To: Daniel Berger <djberg96 at gmail.com>
>
>
> Hi,
>
> Very short note...
>
> I don't know how to do git pull requests and blah blah blah. I just
> fixed what I think is a bug in the win32/process code. You don't close
> the thread handle when you kill with signal 1. In my case I had a
> process monitor app that continued to think the PID was still alive,
> because the system continued to grant handles to the dead PID.
>
> Maybe the behaviour is intentional, I don't know. Anyway, hth.
>
> Cheers,
>
> ben
>

From djberg96 at gmail.com  Sun Nov  7 10:03:37 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 07 Nov 2010 08:03:37 -0700
Subject: [Win32utils-devel] Process.setsid for Windows
Message-ID: <4CD6BFC9.5050408@gmail.com>

Hi,

Just thinking about the possibility of a Process.setsid for Windows.

Would a Process.setsid analogue for Windows be a matter of calling 
CreateProcess() with CREATE_NEW_PROCESS_GROUP + DETACHED_PROCESS ? And 
raise an error instead if the current process is the process group leader?

Regards,

Dan

From djberg96 at gmail.com  Tue Nov  9 22:32:37 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Tue, 09 Nov 2010 20:32:37 -0700
Subject: [Win32utils-devel] Fwd: Win32Utils and CStruct
Message-ID: <4CDA1255.7040007@gmail.com>

Nice!

-------- Original Message --------
Subject: 	Win32Utils and CStruct
Date: 	Wed, 10 Nov 2010 10:22:20 +0800 (CST)
From: 	skandhas <skandhas at 163.com>
To: 	djberg96 at gmail.com



Dear Daniel J. Berger
I always use Win32 Utils.The Win32 Utils project is powerful and convenient!
And I also writed a gem 'CStruct'. It can be used together with
Win32Utils. CStruct is a simulation of the C language's struct.Its main
purpose is to manipulate binary-data conveniently.
CStruct Project: http://cstruct.rubyforge.org/.
Examples: http://cstruct.rubyforge.org/examples.html

Awaiting your early reply.

Best regards.
skandhas



From djberg96 at gmail.com  Sun Nov 14 10:51:37 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Sun, 14 Nov 2010 08:51:37 -0700
Subject: [Win32utils-devel] Getting a home directory on windows
Message-ID: <000601cb8413$d3e11620$7ba34260$@com>

What do you think?

require 'win32ole'
require 'etc'

def get_windows_home_directory
  user = Etc.getlogin

  # Try the domain account first
  adsi = WIN32OLE.connect("WinNT://#{host}/#{user},user")
  home = adsi.homedirectory
  
  # If the homedirectory was blank, try the local account
  unless home.size?
    wmi = WIN32OLE.connect("winmgmts://")
    sql = "select * from win32_useraccount where name = '#{name}'"
    sid = nil

    wmi.execquery(sql).each{ |u| sid = u.sid }

    # If the sid couldn't be found for some reason then fall back to using
ENV.
    # Otherwise use the registry value.
    if sid.nil?
      home = ENV['USERPROFILE'] || ENV['HOME']
    else
      require 'win32/registry'
      key = "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList\\"
+ sid

      # If this fails it probably means the registry value could not be
found
      # and we again fall back to using ENV.
      begin
        Win32::Registry::HKEY_LOCAL_MACHINE.open(key) do |reg|
          home = reg['ProfileImagePath']
        end
      rescue Win32::Registry::Error
        home = ENV['USERPROFILE'] || ENV['HOME']
      end
    end
  end

  home
end