459629 - LoadLibraryExW failing in nsGlueLinkingWin.cpp on windows ce

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

after applying the wince-patches patch queue

first, we were calling wcspbrk instead of ns_strpbrk, so the path is being reduced to \Xul.dll.  Even after fixing that, LoadLibraryExW fails with the error "The specified module could not be found."  The paths being passed in are correct and the files (xul.dll and xpcom.dll) exist.

Comment 1

[Benjamin Smedberg]

Is that an --enable-libxul build? That error is sorta-expected in --disable-libxul builds.

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

no, its a standard fennec build on windows ce. Starting it with "xulrunner.exe ../application.ini" works.

Comment 3

[Benjamin Smedberg]

Is there an equivalent of Process Explorer for WinCE?

Comment 4

[John Wolfe (:wolfe)]

Yes - if your device is tethered to a desktop, then there are tools for accessing that device's state remotely.

Visual Studio 9 has a "Visual Studio Remote Tools" directory inside it's Start Menu's directory "Visual Studio 2008".  Inside the "Visual Studio Remote Tools" directory is a "Remote Process Viewer" - which will let you explore processes on your attached device.  

Visual Studio 8 has a similar directory under its Start Menu's "Visual Studio 2005" directory. 

You will have to select the appropriate device from the listing of all devices -- but that is usually "Windows Mobile 6 Professional Device" or "Windows Mobile 6 Standard Device".

There are a couple of on-device pieces of software, but I have not tried them out for a while, so I can not vouch for their suitability.  Here is one such example, CeleTask:
http://www.efficasoft.com/celetask/index_ppc.html

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: avoids broken code path

The central problem is that LoadLibraryExW doesn't recognize the LOAD_WITH_ALTERED_SEARCH_PATH flag.  As a result, you can only load libraries that are in the system path or the directory you launched from.  This patch instead launches xulrunner.exe with CreateProcessW.  Since it is in the same directory as xpcom.dll, it doesn't need to load with an altered search path.

I changed how we find the greDir for wince because we haven't loaded xpcom yet so NS_ConvertUTF8toUTF16 was failing.  Also, grePath points to xpcom.dll, so FILE_ATTRIBUTE_DIRECTORY is the wrong thing to check for.

Finally, the implementation of _wfullpath wasn't honoring absolute paths, this patch fixes that also.

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 357626 [details] [diff] [review]
avoids broken code path

>diff --git a/build/wince/shunt/map.cpp b/build/wince/shunt/map.cpp
>--- a/build/wince/shunt/map.cpp
>+++ b/build/wince/shunt/map.cpp
>@@ -341,21 +341,23 @@ MOZCE_SHUNT_API unsigned short *_wfullpa
>   if (NULL == _wgetcwd( cwd, MAX_PATH))
>     return NULL;
> 
>   unsigned long len = wcslen(cwd);
>   if(!(cwd[len-1] == TCHAR('/') || cwd[len-1] == TCHAR('\\'))&& len< maxLength){
>     cwd[len] = TCHAR('\\');
>     cwd[++len] = TCHAR('\0');
>   }
>   if(len+wcslen(relPath) < maxLength){
> #if (_WIN32_WCE > 300)
>-    if ( 0 < CeGetCanonicalPathName(wcscat(cwd,relPath), absPath, maxLength, 0) )
>+    if ( 0 < CeGetCanonicalPathName(relPath[0] == L'\\'? relPath : 
>+                                                         wcscat(cwd,relPath), 
>+                                    absPath, maxLength, 0))
>       return absPath;
> #else
>     #error Need CeGetCanonicalPathName to build.
>     // NO ACTUAL CeGetCanonicalPathName function in earlier versions of WinCE
> #endif
>   }
>   return NULL;
> }
> 
> MOZCE_SHUNT_API int _unlink(const char *filename)
>diff --git a/xulrunner/stub/nsXULStub.cpp b/xulrunner/stub/nsXULStub.cpp
>--- a/xulrunner/stub/nsXULStub.cpp
>+++ b/xulrunner/stub/nsXULStub.cpp
>@@ -254,23 +254,24 @@ main(int argc, char **argv)
> 
>   *(++lastSlash) = '\0';
> 
>   // On Linux/Win, look for XULRunner in appdir/xulrunner
> 
>   snprintf(greDir, sizeof(greDir),
>            "%sxulrunner" XPCOM_FILE_PATH_SEPARATOR XPCOM_DLL,
>            iniPath);
> 
> #ifdef WINCE
>-  DWORD fileAttrs = GetFileAttributesW(NS_ConvertUTF8toUTF16(greDir).get());
>-  greFound = fileAttrs != INVALID_FILE_ATTRIBUTES && 
>-             fileAttrs | FILE_ATTRIBUTE_DIRECTORY;
>+  wchar_t wideGreDir[MAX_PATH];
>+  MultiByteToWideChar(CP_ACP,0,greDir,-1,wideGreDir, MAX_PATH);

add some a space between the args


>+#else
...
>+  wchar_t xrPath[MAX_PATH];
>+  MultiByteToWideChar(CP_ACP, 0, greDir, -1, xrPath, MAX_PATH);

can't you use wideGreDir from the above block?

>+  CreateProcessW(xrPath, wideIniPath, NULL, NULL, FALSE, 0, NULL, NULL, 
>+		 &si, &pi); 
>+  WaitForSingleObject( pi.hProcess, INFINITE );

remove spaces inside the parens

>+  // Close process and thread handles.
>+  CloseHandle( pi.hProcess );
>+  CloseHandle( pi.hThread );

remove spaces in the parens

> 
>+  
>+

why the extra blank lines? remove all blanks

>+#endif


Some comments in the CreateProcessW #ifdef block as to why we do this would be beneficial

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: fixed nits and worked around paths with spaces

Mark, I just wanted you to have another look with the changes I've made.  Turns out paths with spaces were problematic. 

Also, I can't use wideGreDir because greDir might get reset by  GRE_GetGREPathWithProperties

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 358117 [details] [diff] [review]
fixed nits and worked around paths with spaces

>+  wchar_t wideIniPath[MAX_PATH+2];
>+  swprintf(wideIniPath, L"\"%S\"", iniPath);
>+  
> 
>+  CreateProcessW(xrPath, wideIniPath, NULL, NULL, FALSE, 0, NULL, NULL, 
>+                 &si, &pi); 

remove the extra blank line

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

http://hg.mozilla.org/mozilla-central/rev/8672c246d00e

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 358117 [details] [diff] [review]
fixed nits and worked around paths with spaces

a191=beltzner

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/fe74b0b46bab