[Scummvm-devel] Default paths in Windows port

[Norbert Lange]

Am 19.07.2009, 15:52 Uhr, schrieb Travis Howell <kirben at optusnet.com.au>:

> Please create a new email, rather than replying to a existing email, if  
> posting on a completely different and unrelated issue next time.
>
Well I thought it would be somewhat related.

> Norbert Lange wrote:
>> I would like to see if atleast some of the path issues that apparently   
>> occur in Windows (http://forums.scummvm.org/viewtopic.php?t=7628) would  
>> be  fixed. Should default to the same directory the config-file gets  
>> generated.
> There is no set default location for where saved games are stored, under  
> Windows. The Application Data area is only meant for configuration
> files, and My Documents area is only meant for user created data.
 From the MSDN Docs:
CSIDL_APPDATA (FOLDERID_RoamingAppData)
Version 4.71. The file system directory that serves as a common repository  
for application-specific data. A typical path is C:\Documents and  
Settings\username\Application Data.
Which serves the purpose for storing anything app and user-related.

> My suggestion would be to prompt for the default save path, when ScummVM  
> is first started, on ScummVM ports without default save path.

Currently it appears to be the directory ScummVM was started from which is  
most certainly not a good solution

> Norbert Lange wrote:
>> And related to that the code to determine the place for the config file  
>> is  a bit messy aswell. There are functions that work with practically  
>> any  32-bit Windows out there (excluding only Win95/WinNT without IE4+).
>
> We support ScummVM as far back as Windows 95 (without Internet Explorer)  
> and Windows NT4, which is why the code for the default config file  
> location is more complicated.
>
> Norbert Lange wrote:
>> Downside ofcourse would be that old config-files have to be moved on  
>> some  Windows Versions (I guess only Win9x), and some really dead  
>> Versions  wouldnt run with complaining about a missing "shell32.dll" -  
>> and this  could be fixed by installing IE4 or newer.
>> Optionally we could do a fallback by checking for shell32.dll but I  
>> dont  think its worth it
>
> No, breaking support for the oldest supported Windows versions isn't a  
> good idea, unless there is an extremely good reason.

Well it would be no prob to check for shell32.dll and use  
"<windir>\Application Data" if not available - this is the folder thats  
typically used on Win9x so if the user installs IE4 later it would  
continue working. It would still be alot cleaner than the current solution.

Cheers, Norbert