Jump to content

Future versions of Firefox on Windows 98

ivanbuto

By ivanbuto
in Windows 9x/ME

 Share

Recommended Posts

BenoitRen

BenoitRen

Posted
Posted

Here's what I can make out of the patch:

Replaces mPeekMessage calls by PeekMessageW calls.

Replaces mDispatchMessage calls by DispatchMessageW calls.

Pulls out support for Win9x print drivers. For WinNT it's WINSPOOLER, for Win9x it's NULL.

It does this by removing the Windows version check and always using WINSPOOLER.

Replaces mSHGetPathFromIDList calls by SHGetPathFromIDListW calls.

Replaces mSHBrowseForFolder calls by SHBrowseForFolderW calls.

Replaces mGetOpenFileName calls by GetOpenFileNameW calls.

Replaces mGetSaveFileName calls by GetSaveFileNameW calls.

The KeyboardLayout::LoadLayout procedure got modified so that it doesn't compensate anymore for Win9x' inexistant Unicode support. Before, it would use ASCII for Win9x.

Removal of ANSI version of a certain procedure in favor of Unicode.

Something to do with calling APIs for multiple monitors that are only available on Win98 and Win2000.

Implements GetMonitorInfoW in favor of other detection methods.

Removes winmm.dll loading, which seems to be used to play back certain sounds.

Next it removes all the Win9x support calls that were used before from nsToolkit. Here's parts of it the functions defined:

-HMODULE			 nsToolkit::mShell32Module = NULL;
-NS_DefWindowProc	nsToolkit::mDefWindowProc = DefWindowProcA;
-NS_CallWindowProc   nsToolkit::mCallWindowProc = CallWindowProcA;
-NS_SetWindowLong	nsToolkit::mSetWindowLong = SetWindowLongA;
-NS_GetWindowLong	nsToolkit::mGetWindowLong = GetWindowLongA;
-NS_SendMessage	  nsToolkit::mSendMessage = nsSendMessage;
-NS_DispatchMessage  nsToolkit::mDispatchMessage = DispatchMessageA;
-NS_GetMessage	   nsToolkit::mGetMessage = GetMessageA;
-NS_PeekMessage	  nsToolkit::mPeekMessage = PeekMessageA;
-NS_GetOpenFileName  nsToolkit::mGetOpenFileName = nsGetOpenFileName;
-NS_GetSaveFileName  nsToolkit::mGetSaveFileName = nsGetSaveFileName;
-NS_GetClassName	 nsToolkit::mGetClassName = nsGetClassName;
-NS_CreateWindowEx   nsToolkit::mCreateWindowEx = nsCreateWindowEx;
-NS_RegisterClass	nsToolkit::mRegisterClass = nsRegisterClass; 
-NS_UnregisterClass  nsToolkit::mUnregisterClass = nsUnregisterClass;

-	  // For Windows 9x base OS nsFoo is already pointing to A functions
-	  // However on NT base OS we should point them to respective W functions
-	  nsToolkit::mDefWindowProc = DefWindowProcW;
-	  nsToolkit::mCallWindowProc = CallWindowProcW;
-	  nsToolkit::mSetWindowLong = SetWindowLongW;
-	  nsToolkit::mGetWindowLong = GetWindowLongW; 
-	  nsToolkit::mSendMessage = SendMessageW;
-	  nsToolkit::mDispatchMessage = DispatchMessageW;
-	  nsToolkit::mGetMessage = GetMessageW;
-	  nsToolkit::mPeekMessage = PeekMessageW;
-	  nsToolkit::mGetOpenFileName = GetOpenFileNameW;
-	  nsToolkit::mGetSaveFileName = GetSaveFileNameW;
-	  nsToolkit::mGetClassName = GetClassNameW;
-	  nsToolkit::mCreateWindowEx = CreateWindowExW;
-	  nsToolkit::mRegisterClass = RegisterClassW; 
-	  nsToolkit::mUnregisterClass = UnregisterClassW; 
-	  // Explicit call of SHxxxW in Win95 makes moz fails to run (170969)
-	  // we use GetProcAddress() to hide

I guess this is enough food for thought for anyone interested. The patch is huge.

Link to comment
Share on other sites

myelin

myelin

Posted
Posted
I guess this is enough food for thought for anyone interested. The patch is huge.

Thats nice info. I was thinking that those patches were there to add windows98 support, i was going to download FF3 and test it with those patches installed on Windows98SE. Certainly i would have ended in :huh::no::wacko:.

Why would they want to make such a patch anyway? :angry:

Well... Firefox is open-source, so if it doesn't work for you go ahead and change it...

Thats very cruel of them to write those patches, making it completely impossible to run it on windows98 or ME.

1. But browsers other then I.E have a tendency of being more stable. I was browsing a site with I.E 6.1 SP1 and got hit by ntkernel.exe trogen which freezed my system for 2 minutes, increased the size of my swap file from 50MB to 250MB and then tried to connect to internet but Zonealarm caught it... On that same site with firefox there was not even a single slow down or freeze and no trogen activity.

2. The system becomes very low on resourses with I.E usage for long periods of time, it starts to freeze with multitasking.

3. All browsers based on I.E have the same tendencies.

Link to comment
Share on other sites
modicr

modicr

Posted
Posted (edited)

Hello!

Why would they want to make such a patch anyway? :angry:

Well... Firefox is open-source, so if it doesn't work for you go ahead and change it...

msg #36 from http://bugzilla.mozilla.org/show_bug.cgi?id=330276

Here's what needs to be done to restore Win9x support, by whoever volunteers to

do so:

Define a new header file wincompat.h (or something like that). When building

normally it does nothing. When building for Win9x (enabled by a configure

flag), it #defines all the Win2K-only APIs to Win9x-based replacements. E.g.

PeekMessageW gets #defined to Win9x_PeekMessageW, which gets implemented in a

separate file as a wrapper around Win9x's PeekMessage. This patch is a great

place to start.

You should then be able to get Win9x-builds working without interfering with

trunk code. Regular Windows builds won't work on Win9x but that's no great

loss. I'd be happy to review such a patch.

Regards, Roman

Edited by modicr
Link to comment
Share on other sites
LLXX

LLXX

Posted
Posted

Wow... after reading through some of the code and comments of their programmers I feel like wanting to rewrite all of it... it's as if they were coerced by M$ or something to drop support for 9x!

defines all the Win2K-only APIs to Win9x-based replacements. E.g.

PeekMessageW gets #defined to Win9x_PeekMessageW, which gets implemented in a

separate file as a wrapper around Win9x's PeekMessage.

That's a horribly inefficient and roundabout way to do it... Why not just replace PeekMessageW with PeekMessageA and be done with it? Sometimes I really do question the intelligence of these open-source 'programmers'... :wacko:
Link to comment
Share on other sites
Tihiy

Tihiy

Posted
Posted
That's a horribly inefficient and roundabout way to do it... Why not just replace PeekMessageW with PeekMessageA and be done with it? Sometimes I really do question the intelligence of these open-source 'programmers'...

Well, Firefox must be internally Unicode, and thus must use unicode APIs. If they'll use ANSI strings and ANSI apis, there will be much more headaches.

Link to comment
Share on other sites
LLXX

LLXX

Posted
Posted
That's a horribly inefficient and roundabout way to do it... Why not just replace PeekMessageW with PeekMessageA and be done with it? Sometimes I really do question the intelligence of these open-source 'programmers'...

Well, Firefox must be internally Unicode, and thus must use unicode APIs. If they'll use ANSI strings and ANSI apis, there will be much more headaches.

What I meant was to have a compiler directive or something that completely changes Firefox to use the A APIs when compiled with appropriate options.

What's with the popularity of all this 'unicode' anyway... even WinXP can't display multiple languages in the same dialog box using unicode strings in the resources, and it's just a huge waste of space (TWICE).

Link to comment
Share on other sites
  • 2 weeks later...
erpdude8

erpdude8

Posted
Posted (edited)
What I meant was to have a compiler directive or something that completely changes Firefox to use the A APIs when compiled with appropriate options.

What's with the popularity of all this 'unicode' anyway... even WinXP can't display multiple languages in the same dialog box using unicode strings in the resources, and it's just a huge waste of space (TWICE).

yup. no wonder why this "unicode" stuff requires much more resources and more HD space

it looks like seamonkey 1.5 browser will also be based on the gecko 1.9 runtime

that Microsoft Firefox site I mentioned earlier is still working [hehehe] :)

Edited by erpdude8
Link to comment
Share on other sites
  • 4 weeks later...
  • 2 weeks later...
ivanbuto

ivanbuto

Posted
  • Author
Posted
defines all the Win2K-only APIs to Win9x-based replacements. E.g.

PeekMessageW gets #defined to Win9x_PeekMessageW, which gets implemented in a

separate file as a wrapper around Win9x's PeekMessage.

That's a horribly inefficient and roundabout way to do it... Why not just replace PeekMessageW with PeekMessageA and be done with it? Sometimes I really do question the intelligence of these open-source 'programmers'... :wacko:

I think part of the reason they suggest to do it in this way is that it's not just about the Unicode APIs. It's about some APIs used in Cairo which are entirely unimplemented in Windows 9x. It seems that so far there are only few such APIs (check the bugzilla thread for reference).
Link to comment
Share on other sites
ivanbuto

ivanbuto

Posted
  • Author
Posted
Here's what I can make out of the patch:

(...)

Great, BenoitRen, thanks for digging into this!

It seems that as a start, it would be good to follow the proposal of Robert Callahan by doing the following:

1. Writing the file wincompat.h, which would define all the functions that are missing in Win 9x, including the ones that were modified by this patch. (Example given by R. Calahan: "PeekMessageW gets #defined to Win9x_PeekMessageW") This should include all the APIs present on the current 1.9 trunk that do not work on Windows 9x. It seems like this is mostly mechanical work, anyone with some knowledge of C++ programming could do it.

2. Writing the wrapper, by defining all the Win9x_functions. All the functions removed by the patch would simply be "put back" in this wrapper.

This would be a great place to start, and could also attract the attention of Mozilla developers once it's finished.

Additional functions which will need to be created for Win9x are some that exist in Cairo and that use APIs not available in Windows 9x. Thus far I know of the following:

- GetGlyphIndicesA/W

- UpdateLayeredWindow

- AlphaBlend (not clear whether this one is needed)

- SetWorldTransform

I really believe this can be done. Just think about how great it would be to have Firefox 3 ready for Windows 98.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...