[#6864] ruby 1.8.4 rc breaks alias_method/rails in bad ways — "Ara.T.Howard" <ara.t.howard@...>

20 messages 2005/12/09
[#6870] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — =?ISO-8859-15?Q?Florian_Gro=DF?= <florgro@...> 2005/12/12

Ara.T.Howard wrote:

[#6872] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, [ISO-8859-15] Florian Growrote:

[#6873] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — James Edward Gray II <james@...> 2005/12/12

On Dec 12, 2005, at 1:19 PM, ara.t.howard@noaa.gov wrote:

[#6874] Re: ruby 1.8.4 rc breaks alias_method/rails in bad ways — ara.t.howard@... 2005/12/12

On Tue, 13 Dec 2005, James Edward Gray II wrote:

[#6891] Time.utc! and Time.localtime! — Daniel Hobe <hobe@...>

Writing a script yesterday I found out, much to my surprise, that the

16 messages 2005/12/14

[#6918] change to yaml in 1.8.4 — ara.t.howard@...

14 messages 2005/12/16

[#6934] 1.8.x, YAML, and release management — Ryan Davis <ryand-ruby@...>

I'm concerned that 1.8.3's acceptance of non-backwards-compatible

28 messages 2005/12/18

[#6996] Problems building 1.8.4 with VS8 C++ Express Edition (cl 14.00) — Austin Ziegler <halostatue@...>

Visual Studio C++ 2005 Express Edition (VS 8.0)

20 messages 2005/12/27

Re: [PATCH] Dir.tmpdir RDoc

From: Austin Ziegler <halostatue@...>
Date: 2005-12-16 14:46:26 UTC
List: ruby-core #6917
On 15/12/05, Zach Dennis <zdennis@mktec.com> wrote:
> nobuyoshi nakada wrote:
>> At Thu, 15 Dec 2005 12:01:22 +0900,
>> Daniel Berger wrote in [ruby-core:06896]:
>>> Also, GetSystemWindowsDirectory() is deprecated on Windows in favor
>>> of ShGetFolderPath().  From the MSDN docs:
>>>
>>> "Applications should store code in the Program Files folder and
>>> persistent data in the Application Data folder in the user's
>>> profile."
>> TEMP direcotry is defaulted to "%USERPROFILE%/Local Settings/Temp",
>> but how can you tell USERPROFILE with that API?
[...]
> The SHGetSpecialFolderPathA should really be "SHGetSpecialFolderPath"
> because windows is supposed to determine whether or not to call
> SHGetSpecialFolderPathA or SHGetSpecialFolderPathU (for
> ansii/unicode).

It's actually SHGetSpecialFolderPathW, and the distinction will be made
depending on whether UNICODE is defined. Defining UNICODE is, to be
honest, suitable only for non-portable Windows programs. If it's to be
made to work on any other platform, you need to use the W-methods
directly and convert to a portable encoding. This is the plan that I
have for fixing a lot of the Windows filesystem access stuff when Matz
has M17N strings in place.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca


In This Thread

Prev Next