Closed Bug 459629 Opened 14 years ago Closed 13 years ago

LoadLibraryExW failing in nsGlueLinkingWin.cpp on windows ce


(Toolkit Graveyard :: XULRunner, defect)

Windows CE
Not set


(Not tracked)



(Reporter: blassey, Assigned: blassey)


(Keywords: fixed1.9.1, mobile)


(1 file, 1 obsolete file)

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.
Is that an --enable-libxul build? That error is sorta-expected in --disable-libxul builds.
no, its a standard fennec build on windows ce. Starting it with "xulrunner.exe ../application.ini" works.
Is there an equivalent of Process Explorer for WinCE?
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:
Attached patch avoids broken code path (obsolete) — Splinter Review
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.
Assignee: nobody → bugmail
Attachment #357626 - Flags: review?(mark.finkle)
Attachment #357626 - Flags: review?(mark.finkle) → review+
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

>+  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


Some comments in the CreateProcessW #ifdef block as to why we do this would be beneficial
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
Attachment #357626 - Attachment is obsolete: true
Attachment #358117 - Flags: review?(mark.finkle)
Attachment #358117 - Flags: review?(mark.finkle) → review+
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
Closed: 13 years ago
Resolution: --- → FIXED
Attachment #358117 - Flags: approval1.9.1?
Comment on attachment 358117 [details] [diff] [review]
fixed nits and worked around paths with spaces

Attachment #358117 - Flags: approval1.9.1? → approval1.9.1+
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.