RE: [discuss] System Tray Menu

 --- Sam Berlin <[email protected]> a écrit : 
> As Philippe mentioned, the .bmp files (and in fact, the code) under
> gui/native/win are not used.  The code for the dll that has the
> in-use system tray (LimeWire20.dll) is under gui/native/notify/win.
> It's very old stuff, untouched in over 3 years.  
> 
> If you'd like permission to use the .bmps, I believe you'll have to
> ask  Philippe about that. He likely contributed them with the other
> code at gui/native/win.

These bmps are free for use, under the same GPL licence as Limewire's
source code where it was contributed. But these are not restricted to
that licence. This so small that you may reuse them as you want even
with your own licence (I have no financial interest in such small
images that I created in a few minutes); if you want a more explicit
licence (outside of the current GPL in Limewire's sources) just ask
me...

The C source code (as well as the header files to compile them), on the
opposite, is derived from the code in gui/native/notify/win (which is
the current Limewire source, so licenced to the GPL), and so this
derived work is bound to the terms of the GPL licence of LimeWire; I
can't give another licence without first asking permission to
LimeWire.org project authors...

The Resource file (.rc) is also not a derived work, however it contains
some terms coming from the original compiled version of LimeWire20.dll
which is part of LimeWire.

The .DSP/.DSW project files for Visual Studio are not absolutely
necessary to these sources (other compilers may be used), and they are
not derived from LimeWire's sources.

I suppose that there existed similar project files for Visual Studio to
compile the original LimeWire.org's version of Limewire20.dll, but I
have not seen it. Adam Fisk said me that he did not know how to compile
these old sources, because these old project files (which contain the
compilation options which make the source work correctly) have
apparently been lost.

So if someone can say me what does not work in my DSP/DSW project files
when running the generated DLL on Windows 95, I would be pleased to
change it. So consider that I have donated my DSP/DSW project files to
the Limewire.org project, and placed them into the same GPL licence.

For now, not even Limewire.org's official team seems to be able to
compile the old source code found in gui/native/notify/win and run
successfully on Windows 95.

I have no idea why this happens, but I note that apparently the current
compiled version of LimeWire20.dll seems to contain an internal file
name (in its resources) "LimeWire19.dll".

It seems that the DLL exports are bound to this old DLL name, even if
the DLL file has been renamed, and may be this is what Windows 95
expects when resolving imports from Java to this DLL (but Windows
NT/2000/XP do not choke on this resource data, because it resolves
imports directly using the effective filename and not the internal name
stored in the DLL resources).

May be this occurs because of the way Windows 95 resolves the so-called
"imports hints" (a specificy of Windows 95/98, not used or abandonned
on Windows NT/2000/XP).

My current project consistently uses the same name for the embedded
resource data "InternalFileName", and the generated filename (this is
the normal procedure when compiling with Visual Studio projects), so
the "InternalFileName" resource is effectively "LimeWire20.dll" and not
"LimeWire19.dll".

Another possibility is that I should have used a "compatibility flag"
in the project, to mark the linked DLL as compatible with Windows 95
imports resolver... I have not info about such flags to add in the DSP
project to invoke the Microsoft linker...

Final note: I have carefully listed the imports made by my DLL, and it
just happens that they are in fact identical to the imports used in the
current Limewire20.dll:

(1) My code does not link statically to Win32 APIs that are working
only on NT/2000/XP, but it uses instead a call to LoadLibrary() and
GetProcAddress(), plus a call to GetVersion() to check that the Unicode
API is supported on specific versions of Windows, as documented in
MSDN,

(2) else it defaults to using the ANSI API, by converting Java UTF-16
strings to ANSI with a call to WideCharToMultiByte() which IS REALLY
supported on Windows 95 only to convert from UTF-16 to the local ANSI
or supported OEM codepages...

(3) The local Windows ANSI strings are also converted back to Java
UTF-16 using MultiByteToWideChar(), also supported on Windows 95 only
when converting from the local ANSI or supported OEM codepages to
UTF-16.

(4) My code is also compiled in the _ANSI mode, so all unqualified
Win32 API names are resolved as their ANSI version supported on Windows
95.

(5) This technic for ensuring compatibility with Windows 95 is ALSO
USED in the Sun SCSL Java JRE sources. I have not invented this
technic, but I have just created "dual wrappers" around Unicode/ANSI
Win32APIs to make the conversion to ANSI only when necessary (i.e. only
on Windows 95/98/ME) using GetVersion() to determine if I'm on
NT/2000/XP/2003 or on 95/98/ME which only supports the local ANSI
codepages in the GUI, or a few supported OEM codepages for filenames.

-------------
Final notes:

On Windows 95/98/ME, a few Unicode Win32 APIs "seem" to work but they
are in fact wrappers that convert internally their UTF-16 strings to
ANSI. If this conversion to ANSI fails because mapping characters do
not exist in the ANSI codepage, the API will return an error status, or
it will display square boxes, or it will display "?" characters:
it's impossible for example to display a Russian menu item in Russian,
on a non-Russian version of Windows 95/98/ME.

To do that on Windows 95, you can't use the core Win32 API but you need
to use Uniscribe, shipped optionally with Internet Explorer addons but
not installed by default with the system, and a complex custom graphic
rendering code, that needs to perform lots of compatibility checks:
it's exactly the same problem that exists in the Windows 95/98/ME
versions of WordPad, which can't even display Russian text on a French
or English version of Windows, even if it successfully load UTF-8 files

(for example, when you load on Windows 95/98/ME a Russian UTF-8 text
with WordPad or with WinMerge, you'll only see "?" characters, and if
you save it, all unsupported characters will have been replaced! Even
WinDiff won't tell you if there are differences in the actual UTF-8
encoded characters if they both map to a default "?" character, as
these tools do not actually work internally with Unicode WCHARs, but
with ANSI encoded characters in the GUI editor component.)

As a consequence, Windows 95/98/ME can only work with a small subset of
Unicode (i.e. only the subset of characters in the immutable ANSI
codepage or one of the supported and loaded OEM codepage), but they are
not fully compatible with Unicode.

This also means that you can load, display, edit and save Russian or
Bulgarian (Cyrillic) only on a Russian or Bulgarian version of Windows
95/98/ME (whose system ANSI codepage is ANSI Cyrillic codepage 1251),
but on ANY localization of Windows NT/2000/XP/2003 which are true
Unicode-compatible systems! The various localization of Windows
95/98/ME are not interoperable if they are not bound to the same ANSI codepage.


	
	
		
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
_______________________________________________
discuss mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/discuss