X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=3.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_THEBAT,SUBJECT_NEEDS_ENCODING X-Spam-Check-By: sourceware.org Date: Wed, 25 Jan 2012 05:12:15 +0400 From: Andrey Repin Reply-To: Andrey Repin Message-ID: <1065609395.20120125051215@mtu-net.ru> To: Chris Day , cygwin AT cygwin DOT com Subject: Re: Environment Var Problems with Perl - impact on Win32::OLEž In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Greetings, Chris Day! > In attempting to move some perl (5.10.1-3) code from a Windows XP (Cygwin > 1.7.9) environment to a Windows Server 2008 R2 (Cygwin 1.7.9 with perl > 5.10.1-3) I seem to have discovered a problem with Cygwin/Perl not resolving > most Microsoft environment strings. > For example, running the following from a Cygwin bash shell (or seemingly > any Cygwin shell) on any of the XP, Windows 7 and Server 2008 2 machines I > have: > bash$ perl -e "use Win32; print Win32::ExpandEnvironmentStrings('%OS%')" > all give > %OS% Try $OS Although, wait. What "set | grep OS" tells you in the same bash session? > While running this from cmd.exe: C:\cygwin\bin>>perl -e "use Win32; print Win32::ExpandEnvironmentStrings('%OS%')" > gives the correct answer of > Windows_NT > This problem seems to exist for all environment variables I have tried, > strangely apart from %PATH%. I am not sure if this is a Perl or Cygwin > issue. I have tried a newer version of Perl with the same results. > This problem resolving environment variables really shows up when using > attempting to use certain COM libraries on Windows7 or Windows Server (I > guess with Vista also), as in these OS Microsoft has started to use > environment variables in the registry paths of lots of their libraries, > whilst they did not do this with XP. > I think it is for this reason people have been experiencing problems with > ADODO and other COM functions using Win32::OLE. It's not an easy task to try and bribe two worlds together. > For example, the ADODO.Connection registry key on Windows 7 > (HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}) > has library path as %CommonProgramFiles(x86)%\System\ado\msado15.dll What is the registry key type? Is it REG_SZ or REG_EXPAND_SZ ? > while under XP the ADODO.Connection registry key has its library as > C:\Program Files (x86)\Common Files\System\ado\msado15.dll. Seems like the same path to me. (Though this looks like XP64 path, amirite?) > On my Windows 7 machine, I have tried changing the directory path to from > %CommonProgramFiles(x86)% to C:\Program Files (x86)\Common Files in the > aforementioned registry key and now Win32::OLE->new('ADODB.Connection') > works, albeit opening a DB connection would require a whole host of other > similar registry changes (I do not recommend this, I just did it as a test). > I am hoping that someone knows how to fix this or knows a workaround? I don't know how to fix it, but I hope my questions could shine some light on your issue. -- WBR, Andrey Repin (anrdaemon AT freemail DOT ru) 25.01.2012, <05:07> 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