After one has compiled K-Meleon, (s)he has to make a distribution from it. How does one go about doing that?

No, no, you don't have to make a distribution. BuildKMeleonDistribution should be used if you want to make a complete distribution/package/release, like the ones you can download from this site. If you only want to use the CVS version of K-Meleon, simply build k-meleon.exe (and probably the plugins) and copy it to where you've installed K-Meleon. You can also update the default settings by copying the default directory. There's also the chrome, which is rarely updated, and is not in CVS anyway, so don't worry about that.

Chrome has files that must be edited by us. Chrome is only updated when we find
that files that we use are updated by Mozilla. As rmn says: this happens rarely.
We can not use Mozilla embed chrome building script ( without altering it ).

If You have build one specifically for win95/98/ME - please offer it for download - there are perhaps not many here that use DOS based Windows - but i know there are some, thx.

Well, it says "Creating the chrome package", and that it's outdated.
So I guess you just take K-Meleon 1.0.2, and replace executables/DLLs, right?

My aim is to create a package that can be readily downloaded just like the official ones, but built with VC6 for maximum Win9x compatibility.

By the way, Windows 9x is not DOS-based. It uses DOS for its bootstrapping process, and then uses its own routines for just about everything.

Yes. IMHO update executables/DLLs.

Your version will be good idea for ppl that use 95/98/ME (maybe NT4).

Chrome: I normally maintain our chrome - i think it is still in good shape.

p. s. That info about making embed chrome is very outdated. K-Meleon has come a long way since that info was true. An updated script exists but it is untested.

Why? Dorians recent work reduced the number of original SeaMonkey chrome files drastically - and it is steadilly and fast declining further.

K-Meleon chrome has exceptions now ( many edited files - once only 3 files were edited ). K-meleon has now chrome parts that do not exist with SeaMonkey.

& K-Meleon has an altered chrome structure for easier maintenance after version 0.8.2+. k-meleon now uses the same chrome structure as Mozilla/SeaMonkey.
The new structure is better suited for translations ... Our teams speak French, Dutch, Chinese ... & few are English. Translation (among that translated chrome) is a much wanted item.

BTW. Thx for info about bootstrapping - i did not know that the DOS part is hardly used for anything but to start. And imagined it was a GUI runing under 32 bit DOS.

If you want, I can send you my NIS setups.

Just send me a mail.

A+

BenoitRen wrote:
>
> My aim is to create a package that can be readily downloaded
> just like the official ones, but built with VC6 for maximum
> Win9x compatibility.

Oh, I see. So you do want to create a distribution....

Then it's probably better if you also compile SeaMonkey using VC6, because the one used in the normal K-Meleon package is compiled using VC7.1. I was told that official SeaMonkey is built using VC6, but it does not include two patches used in the one distributed with K-Meleon. These patches fix bugs [bug=314]314[/bug] and [bug=618]618[/bug], and are available in http://boisso.free.fr/kmeleon/ (the first two Mozilla patches).

(I don't know if this is still true, but there is a possibility that K-Meleon doesn't need some of the files you get after building SeaMonkey. I think the easiest way to check is with
diff -q $seamonkeydir $kmeleondir | grep differ
and don't copy the files not listed.)

Then, simply copy all the K-Meleon stuff you compiled (and SeaMonkey files, if you want) over a 1.02 installation. That way you don't need to mess around with the default settings, skins, chrome, etc.

If you want to create an NSIS installer, there's an .nsi file in CVS, but last time I tried, it didn't work out-of-the box.

"Windows 9x is not DOS-based"

Actually, if you want to be technically correct... Win 9x is a DOS-based OS.
Many of the drivers used in 9x are/can be 16 bit.

> Then it's probably better if you also compile SeaMonkey using VC6

Already done.

> These patches fix bugs 314 and 618, and are available in http://boisso.free.fr/kmeleon/ (the first two Mozilla patches).

Thanks, will include them.

> If you want to create an NSIS installer, there's an .nsi file in CVS, but last time I tried, it didn't work out-of-the box.

Hmm, then I guess I'll just create a ZIP.

> Actually, if you want to be technically correct... Win 9x is a DOS-based OS.
Many of the drivers used in 9x are/can be 16 bit.

That doesn't mean it's DOS-based, it means that has a high compatibility with DOS. Which is a good thing for the DOS emulator and pure DOS mode.

at http://people.freenet.de/CoolMcKluus/software/kmeleon/km1/locales/index.html

We will find that: nsi English files are part of the localisation packages(1.0 and 1.02)

http://people.freenet.de/CoolMcKluus/software/kmeleon/km1/locales/K-Meleonloc1.02.zip

& alain maintains new installer no need to use the old one from cvs
( but i do not like installer & prefer sfx.exe :- ).
Maybe someone that has access to cvs should place working new script file there (alain)?


BenoitRen: if it means compatible to DOS this good enough to be called DOS for practicle puposes ;-) such as a start discette - again thx for sharing that info.

No, I haven't right. Dorian seems not want to give me the rights.

No problem to send it to BenoitRen. Just a mail ... and I send it.

A+

Ok - it was just a thought. Some ppl might look in cvs for new version.
Sufficiant when all know that it can be got from You & is at kko's page.

Oh, another thing (I'm pretty sure you already know this, but just want to make sure). I think it's safest to just copy SeaMonkey's .dll files (and they are the only ones that are compiled anyway). Some of those .js files are modified for K-Meleon (at least the ones in default/ are).

When applying that second patch, I get this:

D:\dev\mozilla\content\base\src>patch -p0 < d:\250510.patch
patching file nsContentAreaDragDrop.cpp
patch unexpectedly ends in middle of line
Hunk #2 succeeded at 1388 with fuzz 1.

I think you can safely ignore that. The first warning is probably because the patch file does not end with a newline. The second one most likely is just because the line numbers have changed; usually `patch` is smart enough to still apply it in the correct place.

If you want to be sure, do a diff between the original version and the patched one, and compare with Dorian's patch. Or, you can try and search the code to see whether this modification is made.

I know that "fuzz 1" means it applied correctly but differently. I was worried about the first hunk. I've since checked myself in the file, and the patch seems to have been applied successfully.

I replaced the .exe and .dll files I had copied with the ones I compiled, but under Windows 95 it immediately asks for msvcr71.dll

Then it dawned on me that I should have replaced the Gecko .dll files as well. Still, I would have thought the 7zip file would include the VC7.1 DLL.

This is just great...

I've replaced all the .DLL files. Moved the ZIP to my Windows 95 PC. Now it complains about not finding MFC42D.DLL!

Just to check, I downloaded the official K-Meleon 1.02 and tried that. It runs without a problem (except for the usual caveats).

What's going on?!

You made a debug build
Change the active configuration to release before building kmeleon.

It's normal that the patch is "fuzzy". It's a bit old.

That explains why I saw a console window pop up when starting K-Meleon on WinXP (where it did work), and why it started slower.

Thanks.

Looks like I'm going to have to use this thread for further compile problems.

When I now try to compile a release build, I get this strange error:

Linking...
LINK : warning LNK4049: locally defined symbol "_NS_InitXPCOM3" imported
LINK : warning LNK4049: locally defined symbol "_NS_ShutdownXPCOM" imported
Plugins.obj : error LNK2001: unresolved external symbol "public: void __thiscall CPreferences:etString(char const *,unsigned short const *)" (?SetString@CPreferences@@QAEXPBDPBG@Z)
..\mozilla\mozilla\dist\WIN32_o.OBJ\Embed\k-meleon.exe : fatal error LNK1120: 1 unresolved externals

I think it's an option problem. If you can build it in debug, you should be able to build it in release. You should look at them, especially how to handle wide characters.

Else what you can do is to replace all "wchar_t" by "WCHAR" in preferences.h and in preferences.cpp. Not sure if it will fix the problem though.

I have the same error, checked all the prefs without any result. Has this been fiex ? And how?

When I now try to compile a release build, I get this strange error:

Linking...
LINK : warning LNK4049: locally defined symbol "_NS_InitXPCOM3" imported
LINK : warning LNK4049: locally defined symbol "_NS_ShutdownXPCOM" imported
Plugins.obj : error LNK2001: unresolved external symbol "public: void __thiscall CPreferences:etString(char const *,unsigned short const *)" (?SetString@CPreferences@@QAEXPBDPBG@Z)
..\mozilla\mozilla\dist\WIN32_o.OBJ\Embed\k-meleon.exe : fatal error LNK1120: 1 unresolved externals