Closed Bug 54198 Opened 24 years ago Closed 15 years ago

Mozilla folder created under c:\win95\

Categories

(Core :: XPCOM, defect, P3)

x86
Windows 95
defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: junruh, Unassigned)

Details

Attachments

(1 file)

1.) Install the 092608 build on Win95.
What is expected: A mozilla folder under c:\win95\Application Data
What I see: A Mozilla folder under c:\win95.
Is there a Application data folder on your machine..?
The machine probably is not passaword protected..Today, we have window directory
as a fall back for users whose Application Data folder can't be found.
Assignee: racham → ccarlen
Setting milestone. This isn't exactly a profile mgr bug but XPCOM. Will look
into it though.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
-> xpcom
Assignee: ccarlen → dougt
Status: ASSIGNED → NEW
Component: Browser-General → XPCOM
QA Contact: doron → scc
Target Milestone: mozilla1.0.1 → Future
It seems that Mozilla relies on the SHGetSpecialFolderPathA function in
shell32.dll to get the path to the Application Data folder. 
On Win95, there is (usually) no such function there, so it falls back to the
Windows directory.

On the machines I have tested, the AppData path could be retrieved by calling
SHGetFolderPathA in ShFolder.dll (in fact, it is included for backward
compatibility reasons in all later Windows versions).

Perhaps Moz should try to get AppData by calling this function as well, before
falling back to the Windows dir.
That won't help me because I don't have IE5 either ;-)
Yes, unfortunately shfolder is in ie5...

But, I have Win95 and Win98 machines here, with a bunch of IE-using students,
and I'm doing my best to convince them that Mozilla is better ;-) 
This bug makes it impossible for them to carry around the personal settings
automatically. So, this problem is mainly of concern to those using Mozilla in a
(M$) network (with Win95 machines here and there).

BTW, I've just tried this with a freshly installed Win95 OSR2 (without ie5): 
.) Copied SHFolder.dll from another Win95 to this machine
.) Added AppData with the correct path to
[HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders]
This was enough to get it working.
It's another question that most likely we can't just copy that dll around :-/
So what you're saying, is that if you install IE5 on W95, then the shell32.dll
call will still fail, although the shfolder.dll call will work?
Exactly. I installed IE5.5 SP2, but it did not replace shell32.dll.
It is still version 4.00.xxx, and SHGetSpecialFolderPath is only available from
version 4.71, according to the msdn library.
For starters, the safer bet is to use SHGetFolderPathA from shfolder.dll. As
Microsoft says: "To help ensure your application can run on Windows 9x, Windows
NT 4 as well as Windows 2000, always link to the SHGetFolderPath implementation
in SHFOLDER.DLL." 

Then, shfolder.dll could be distributed with Mozilla. I'm not sure about the
terms but Microsoft encourages its redistribution. 

But if all else fails, wouldn't c:\win95\Application Data be an acceptable
assumption?
(In reply to comment #10)
>But if all else fails, wouldn't c:\win95\Application Data be an acceptable
>assumption?
I don't think we should hard-code the US AppData string... but if neither
SHGetFolderPathA nor SHGetSpecialFolderPathA we could always read
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData
(In reply to comment #10) 
> But if all else fails, wouldn't c:\win95\Application Data be an acceptable
> assumption?

only on english windows systems.
Ok, maybe it's just me then, but I find 
programs that get installed under 
c:\program files even on a Finnish 
system less irritating than those 
installing themselves right under c:\. 


Anyway, trying the registry is a 
good idea.
So I see several things here:
i.) we could replace the shell32 call with the shfolder call, or just add is as
well. This solution looks more compatible (should work on all systems with at
least ie5). But, it will affect all other CSIDL_* queries, not just
CSIDL_APPDATA, if we put it in SpecialSystemDirectory.cpp, where it seems to
belong (if I'm right).
ii.) if it fails in case of the AppData folder, we could try to read the registry.
iii.) finally, we can change the %WINDIR%\Mozilla fallback to something more
appropriate, which is difficult on non-english systems. 

Although there is certainly no AppData folder on that machine yet, I see several
problems with the last one:
.) if we create one, we should add it to the registry, and I personally don't
like programs that modify it at "random" places
.) if we don't modify the registry, a subsequent IE5 install surely will, and it
may create a different folder, so we will gain nothing. But, it will work on
many systems (All Hungarian Windows uses Application Data as well ;-)

I think i) and ii) could be fixed easily. iii) is harder.
iv.) if possible, distribute shfolder.dll and install it first if it's missing. 
This may be a possible fix for i). 

Untested - I don't have MSVC.
Assignee: dougt → nobody
QA Contact: scc → xpcom
Wontfix, all currently supported Windows versions have a proper shell32.dll.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: