Re: NSHomeDirectory() problems on windows

[S.J.Chun]

But the problem is that in Windows XP, %HOMEPATH% also contains spaces, for my 
case, %HOMEPATH% is
\Documents and Settings\NeXT, so %USERPROFILE% or %HOMEDRIVE% %HOMEPATH% are 
equal and I
think this is valid result(why two should have different value?). I think we 
have two kind of choices, one is using
operating systems native home directory mechanism or create our own mechanism 
which should be platform 
independent.

PS)
My opion is using OS's native mechanism. Why GNUstep should not work on space 
contained directory or path?
Also, I can just create directory or path which contains spaces. So, supporting 
is more appropriate choice than
giving up.

  ----- Original Message -----
  From: thisguyisi <address@hidden>
  To: Richard Frith-Macdonald <address@hidden>
  Cc: address@hidden,Roland Schwingel <address@hidden>,address@hidden
  Sent: Wed, 23 Jul 2003 00:06:55 -0700
  Subject: Re: NSHomeDirectory() problems on windows

  I don't see the point of using %USERPROFILE% for windows systems, since 
  that is an internal Windows mechanism. Personally I think that a Home 
  directory system like you seen in UNIX/ GNU/Linux would have been a 
  better mechanism for Microsoft to have implemented.
  
  I spent a couple of weeks playing with a Windows 98SE installation, and 
  a Windows 2000 Professional installation, trying to figure out how to 
  hack the registry to implement the LSFH.v.1.3 (LinuxSTEP Filesystem 
  Hierarchy) for the profiles, and it was a nightmare. Gave up after two 
  weeks. Managed partial successes during a login after changed settings, 
  only to have Windows "resurrect" "default settings" that I was unable to 
  change. Unable to make changes to "default" user profile in either and 
  successfully get them to apply when a new user was created.
  
  I'm of the mind that, being GNUstep is intended as a cross-platform 
  environment, that environment should follow universal GNUstep 
  configuration mechanisms regardless of the Host OS. Additionally, as 
  OPENSTEP NT Enterprise used the $HOMEDRIVE/$HOMEPATH mechanism, that 
  mechanism should be maintained; obviously it was NeXT's choice, and was 
  functional.
  
  Why add funky spices for a specific platform in the stew of something 
  destined for cross-platform consistency and functionality? Let Host OS 
  internal mechanisms remain seperate. The profile implemetations from 
  Win95/98/Me and WinNT/Win2K and WinXP are all a bit different from each 
  other. It's not like Microsoft makes Windows internals to any kind of 
  published spec. Is it worth the effort to keep chasing their changes to 
  the profile mechanism from one version of Windows to the next?
  
  Sorry to blabber on, more like 50 cents than 2, but I thought I should 
  mention it after the headache I went through trying to get Windows to do 
  anything other than its default behaviour.
  
  -thisguyisi
  
  Richard Frith-Macdonald wrote:
  
  >
  > On Monday, July 21, 2003, at 02:20 PM, Roland Schwingel wrote:
  >
  >> Hi...
  >>
  >> A while ago in NSUser.m the way changed how the users homedirectory 
  >> is depicted. Before this change the implementation was much like the 
  >> Openstep for Windows one. Constructing it out of  $HOMEPATH and 
  >> $HOMEDRIVE. Now it is changed to first query $USERPROFILE (which so 
  >> violates the OpenStep specification). And if not found fall back to 
  >> old (in my eyes correct implementation).
  >>
  >> By the way there is maybe a bug in the current implementation for 
  >> asking $USERPROFILE. After retrieving the environmentvariable it is 
  >> checked to not contain spaces. Well at least in german versions of 
  >> Windows 2000 and Windows XP there are spaces by default. $USERPROFILE 
  >> in german versions of windows always contains "Dokumente und 
  >> Einstellungen". So it would be never used here, but elsewehere....
  >
  >
  > That's because the makefile package *must* agree with the base library 
  > about the users home directory, and spaces in paths used by make can 
  > easily break the package ... we can't accept a directory path 
  > containing spaces for the home directory.
  >
  > I think the default setup in english has spaces in there too ... so 
  > I'm not sure that there is much point using $USERPROFILE at all... it 
  > probably doesn't work for the vast majority of users.
  >
  >> I personally hate the way windows userprofiles work. We use 
  >> NSHomeDirectory() here as basepath for our resources, which should 
  >> never ever reside in the userprofile at least because of their size. 
  >> So we really rely on this to not point to $USERPROFILE.
  >>
  >> So what to do? I think this wasn't changed out of pure fun... Even I 
  >> would like to have it back again to be compliant to the openstep for 
  >> windows version, I suggest to make it eventually switchable. For 
  >> example using a new environment variable (eg. 
  >> GNUSTEP_WIN32_HOMEDIRSTYLE). If it is missing (or set to "profile") 
  >> the current behaviour is used. If set to eg. "openstep" it is no 
  >> longer queried for $USERPROFILE instead the HOMEPATH/HOMEDRIVE 
  >> variant will be used directly...
  >
  >
  > I think this was changed because a windows user said it should work 
  > that way (since it's microsofts official method for finding the home 
  > directory), and nobody on the discussion list said otherwise.  I'd 
  > quite happily either remove the usage of USERPROFILE altogether, (as I 
  > don't know if it's ever usable in practice).
  > What do other windows users think?
  >
  >
  >
  >
  > _______________________________________________
  > Discuss-gnustep mailing list
  > address@hidden
  > http://mail.gnu.org/mailman/listinfo/discuss-gnustep
  >
  
  
  
  _______________________________________________
  Discuss-gnustep mailing list
  address@hidden
  http://mail.gnu.org/mailman/listinfo/discuss-gnustep