[jitsi-dev] Re: [jitsi-issues] [JIRA] Commented: (JITSI-963) Starting Jitsi via pinned taskbar icon makes a second Jitsi icon appear in the taskbar instead of highlighting the existing one


#1

Hello Ingo,

I'm moving the discussion of the issues not related to JITSI-963 to
the dev mailing list.

{quote}
The executable run.exe cannot simply be renamed to Jitsi.exe because it is referenced by the former name in the source code of the Windows setup i.e. resources\install\windows\installer-windows.wxs.
{quote}

Ok, I thought so. The idea was that the list of processes reflects a bit better what is running. Depending on the personal level of paranoia "run" might appear suspicious :slight_smile:

I totally agree with you and I've had it in my TODO list for quite
some time now.

{quote}
The Windows application entry point _tWinMain is not supported by MinGW which is currently used to build Jitsi's run.exe. I already tried it prior to your patch.
{quote}

Hmm... that is weird... I built it with MinGW too to ensure everything is fine. Is the "official" run.exe built with Unicode support enabled? AFAIK the makefile produces an ANSI version, and all the Unicode conversions are then not needed anyway?

Could you please share with us the MinGW version with which it works?

The run.exe produced by the Makefile and, consequently, distributed as
part of Jitsi's Windows setup is not a Unicode build. I guess you're
right that the Unicode conversions will not be necessary once we have
_tWinMain but I'm a bit hesitant to drop the ANSI support given that
it's not that big in terms of lines of code and it's already there.
Anyway, I wouldn't mind discussing that later.

Regards,
Lyubomir


#2

Hey

{quote}
The executable run.exe cannot simply be renamed to Jitsi.exe [...]

I totally agree with you and I've had it in my TODO list for quite
some time now.

No problem, and sorry again for mixing it into other stuff.

{quote}
The Windows application entry point _tWinMain is not supported by MinGW

which is currently used to build Jitsi's run.exe. I already tried it prior
to your patch.

{quote}

Hmm... that is weird... I built it with MinGW too to ensure everything

is fine. Is the "official" run.exe built with Unicode support enabled?
AFAIK the makefile produces an ANSI version, and all the Unicode
conversions are then not needed anyway?

Could you please share with us the MinGW version with which it works?

gcc -v outputs:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/x86/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-
specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)

The run.exe produced by the Makefile and, consequently, distributed as
part of Jitsi's Windows setup is not a Unicode build. I guess you're
right that the Unicode conversions will not be necessary once we have
_tWinMain but I'm a bit hesitant to drop the ANSI support given that
it's not that big in terms of lines of code and it's already there.
Anyway, I wouldn't mind discussing that later.

I didn't mean to remove it. After all, the code is even simpler in ANSI as the JNI interface for creating the VM is ANSI only. I was just curious why the build/gcc should fail when Unicode is not enabled? Is it simply because the macro tWinMain is not yet present in some tchar.h versions of MinGW?

Well, while I can code in C or C++, I'm a beginner when it comes to gcc/MinGW and makefiles, or basically everything outside of Visual Studio...

Regards,
Ingo


#3

The _tWinMain macro is defined but its expansion in the case of
Unicode i.e. wWinMain is not recognized as an entry point by the
compiler.

···

2011/10/20 Bauersachs Ingo <ingo.bauersachs@fhnw.ch>:

Is it simply because the macro tWinMain is not yet present in some tchar.h versions of MinGW?


#4

Is it simply because the macro tWinMain is not yet present in some
tchar.h versions of MinGW?

The _tWinMain macro is defined but its expansion in the case of
Unicode i.e. wWinMain is not recognized as an entry point by the
compiler.

Ups, my fault, I didn't compile with unicode enabled on MingW.
What about this:

int CALLBACK
#ifdef __GNUC__
WinMain(HINSTANCE inst, HINSTANCE prevInst, LPSTR cmdLineAnsi, int cmdShow)
#else
_tWinMain(HINSTANCE inst, HINSTANCE prevInst, LPTSTR cmdLine, int cmdShow)
#endif
{

...
#ifdef __GNUC__
#ifdef UNICODE
  LPTSTR cmdLine = GetCommandLineW();
#else
  LPTSTR cmdLine = cmdLineAnsi;
#endif
#endif
...

Regards,
Ingo


#5

Well... The command line provided by the WinMain entry point in the
form of a function argument excludes the program name while
GetCommandLineW() returns the command line with the program name
included. So I'm not sure the assignments to cmdLine above are totally
OK.

···

2011/10/20 Bauersachs Ingo <ingo.bauersachs@fhnw.ch>:

What about this:

int CALLBACK
#ifdef __GNUC__
WinMain(HINSTANCE inst, HINSTANCE prevInst, LPSTR cmdLineAnsi, int cmdShow)
#else
_tWinMain(HINSTANCE inst, HINSTANCE prevInst, LPTSTR cmdLine, int cmdShow)
#endif
{

...
#ifdef __GNUC__
#ifdef UNICODE
LPTSTR cmdLine = GetCommandLineW();
#else
LPTSTR cmdLine = cmdLineAnsi;
#endif
#endif
...


#6

Well... The command line provided by the WinMain entry point in the
form of a function argument excludes the program name while
GetCommandLineW() returns the command line with the program name
included. So I'm not sure the assignments to cmdLine above are totally
OK.

Right... well... now it gets ugly...

int count;
LPWSTR* args = CommandLineToArgvW(GetCommandLineW(), &count);
LPWSTR cmdLine = malloc((wcslen(GetCommandLineW()) + 1) * sizeof(wchar_t));
wcscpy(cmdLine, args[1]);
for(int i = 2; i < count; i++)
{
    wcscat(cmdLine, L" ");
    wcscat(cmdLine, args[i]);
}

I guess we better stick with ANSI until MingW gets it right... :slight_smile:

Regards,
Ingo