- Wine-Devel - list.winehq.org

Re: winedbg crashes
by Jon Griffiths July 2, 2004

July 2, 2004

Hi Eric, <cc'd to wine-devel so anyone with a similar problem can google for the fix> > no, it's normal you get this. In fact, we should simply abort the > loading. > Does this work better ? I can't test it unfortunately, but it looks like the right thing to do. I asked on bugs(a)binutils and was told to upgrade to binutils 2.15 to fix the bad stab generation. Sure enough, this fixes the issue (which means I can't duplicate this behaviour any more). It also fixed a bunch of other random crashes in my app; There were obviously some needed fixes for huge (40 MB in this case) .so generation. So perhaps printing a message to upgrade binutils to >=2.15 when the stabs are found to be corrupted would be appropriate? I'm not sure how prevalent this version is in the wild (my mdk 10 community uses 2.13). I'm investigating now to see if debugging works as expected (so far, so good) Thanks, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

1 0

IE6 installation error. would you please give me a suggession
by Shiva Ram Krishna July 2, 2004

July 2, 2004

Dear Sir/Madam, I downloaded the latest cvs of wine and compiled it. All went well but it seems that the regsvr32.exe.so file wasn't created properly. If check the dependency of expand.exe.so, winver.exe.so, winepath.exe.so, I can see all the proper files that it needs but if I do it on regsvr32.exe.so, it says "regsvr32.exe.so: Not a dynamic executable". I have that his problem for the last 3-4 months. I used a text editor and it seems that the header is the regsvr32.exe.so looks like an msdos .exe file (ex, first 2 characters have "MZ") but expand,winver, and winepath start with "^^". The reason I have notified it is when I run ie 5/6, It stops at the point saying "/usr/local/bin/wine: cannot open builtin library for 'C:\windows\system\regsvr32.exe': /usr/local/lib/wine/regsvr32.exe.so: invalid ELF header". would you please suggest me what I have to do ________________________________________________________________________ Yahoo! India Careers: Over 50,000 jobs online Go to: http://yahoo.naukri.com/

1 0

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.
by Peter Dennis Bartok July 2, 2004

July 2, 2004

>You are asking for stable interfaces and those can only come once there >is a Wine 1.0. Its not here and dont get me wrong I think the Wine TODO >list is way to long and things should be close to frozen by now but >thats not the case. All you are doing is pointing out that its not >stable which is well known. I wish it was stable now but its not and >until the TODO is done its not going to be. Paul's message was very specific, asking about a versioning interface (which I would have loved to have, too, instead of trying to guess in code what version of Wine I might be dealing with). If very reasonable API requests are being refused while it is still under heavy development why would those be granted once 1.0 is reached? And, thus, how is working down the TODO going to help his request? With SWF we luckily have a choice whether or not use use Wine, we tried with and it didn't quite work out, so now we're gonna try without. Paul isn't as lucky, his code is dependent on the Win32 API. I would have thought that Alexandre is exited that his code is being put to new, cool uses even he never imagined... With that I should probably stop participating in this thread, since it's really not contributing to SWF development :-) Regards, Peter

1 0

Re: [Mono-winforms-list] Fw: [Mono-list] System.Windows.Forms plans.
by Steven Edwards July 2, 2004

July 2, 2004

Hello Peter, I am not trying to be rude but... --- Peter Dennis Bartok <peter(a)novonyx.com> wrote: > >Rather than spending a whole lot of time rewritting things wouldnt > it > >be better to help the Wine project get stable and move to the 1.0 > goal? > >There is a roadmap and TODO on Winehq of things that are needed for > >1.0. > No, it wouldn't. Even if Wine already was 1.0 we still would not have > the > portability we're trying to get (ie. run on Solaris Sparc, Mac OS, > etc) and Well Winelib does run on PPC and the port to Sparc is mostly done. 99% of Wine even compiles on Alpha here for me. See http://www.winehq.com/site/status_porting > debugging would still be almost impossible (Wine does funky stuff > with > register for thread storage, special stuff would be required to setup > Mono-created threads before they'd be able to call Wine functions, > etc). > Also, there doesn't seem to be much interest from the Wine community > to do > anything that helps using Wine with SWF/Mono. We've had to resort to > some > quite complicated mechanisms to even be able to use Wine as a shared, > runtime attached library, after Alexandre rejected a patch that only > touched > six lines of existing Wine code and added a new library to Wine, to > allow > straightforward use of Wine as a library. Having to take instead the > complicated route it now means that many people are having problems > getting > SWF to run at all, with due to strict path dependencies. I was there when Miguel came online to ask why the patch was not merged and I also seem to recall Alexandre proposed a fix the would work and seemed to make Miguel happy. See: http://www.winehq.org/hypermail/wine-devel/2004/03/0150.html > Another problem was that we had to spend way too much time tracking > what > changed from one Wine version to the next. For example from April to > May, > the wine_get_unix_file_name() function arguments were changed (I'm > not even > asking why it was changed instead of introducing a new function with > different arguments and leaving the old one for those people who > might use > it). Since I can't require always the latest Wine version, I have to > come up > with code figuring out what Wine version might be running, and write > code to > make version dependent Wine calls. I'd rather spend that time > improving SWF. Once again how can you fuss about unstable interfaces on a project that does not have a stable release? You could work with Winehq to create those stable interfaces. Besides how can you blame the Wine project for tracking changes when the first patch Mono submitted was this? http://primates.ximian.com/~duncan/mono-wine/sources/mono-wine.patch A whole bunch of #ifdefs and other kludges that violates Winehq coding standards. > Notice how people complain on this mailing that they're having > problems > getting even basic stuff going? The SWF code works, it's the > interaction > with Wine that's mostly causing the problems. Again, as I said, it > will > become much easier for the regular user once the Wine dependency is > removed > and the controls are all in managed code. Alright well I am not claiming to know very much about the project. Like I said I only lurk here because I care about how its going to run on ReactOS. I guess my final though on the matter is that if Vertigo Software could make a mananged Quake2, how hard can it be for you to make a managed Wine? Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

collation tables
by Vitaly Lipatov July 1, 2004

July 1, 2004

In test dlls/kernel/tests/locale.c I see comment /* this requires collation table patch to make it MS compatible */ I get trouble with one program it needed collation table to be identical to MS table. Does anyone knows what is the better way to fix this tables, in which place? Can I fix libs/unicode/cpmap.pl for it? Any suggestions? -- Lav Vitaly Lipatov Saint-Petersburg GNU! ALT Linux Team! LaTeX! LyX!

2 1

Re: fix bug in GetCPInfo
by Uwe Bonnes July 1, 2004

July 1, 2004

>>>>> "Vitaly" == Vitaly Lipatov <lav(a)altlinux.ru> writes: Vitaly> Bug: When call GetCPInfo with CP_ACP for example, in returned Vitaly> structure field CodePage filled with CP_ACP constant, not real Vitaly> codepage of current ACP. The attached patch fix this bug. I Vitaly> have compared behavior of this functions with Win2003. This implies, that you have written a test. Please provide the test for our test suite. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

psapi.dll tests
by Ferenc Wagner July 1, 2004

July 1, 2004

Hi, please somebody enlighten me! How does this test work once psapi_test.exe is linked with -lpsapi? How can a program start at all without one of its hard dependencies? START_TEST(module) { dll = LoadLibrary("psapi.dll"); if (!dll) { trace("LoadLibraryA(psapi.dll) failed: skipping tests with target module\n"); return; } The above seems to be a common idiom which I don't understand as opposed to using GetProcAddress and invoking functions through pointers. What am I missing here? -- Feri.

2 2

Bad Icon display with native comctl32
by Uwe Bonnes July 1, 2004

July 1, 2004

Hallo, running with native comctl32, some programs show a bad icon display in treeviews. E.g. Xilinx ISE shows this behaviour. A JPG of the treeview with Icons is appended. A debug log with +relay,+bitmap,+x11drv is about 400 MByte. Any hints how to tackle that problem? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Cleaning up W->A calls
by James Hawkins July 1, 2004

July 1, 2004

I recently decided to help with the development of Wine, and seeing as how I am new to the process, I have chosen menial tasks to take on. This way I can learn more about Wine while contributing. I am currently working on the janitorial task of getting rid of W->A calls and I have a few questions about how I should implement these changes. I'll start the question with an example: dlls/advapi32/crypt.c line 255, 482 BOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType, DWORD dwFlags) { ... complete implementation } BOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR pszContainer, LPCWSTR pszProvider, DWORD dwProvType, DWORD dwFlags) { PSTR pProvider = NULL, pContainer = NULL; BOOL ret = FALSE; TRACE("(%p, %s, %s, %ld, %08lx)\n", phProv, debugstr_w(pszContainer), debugstr_w(pszProvider), dwProvType, dwFlags); if ( !CRYPT_UnicodeToANSI(pszContainer, &pContainer, -1) ) CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); if ( !CRYPT_UnicodeToANSI(pszProvider, &pProvider, -1) ) { CRYPT_Free(pContainer); CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); } ret = CryptAcquireContextA(phProv, pContainer, pProvider, dwProvType, dwFlags); if (pContainer) CRYPT_Free(pContainer); if (pProvider) CRYPT_Free(pProvider); return ret; } Initially CryptAcquireContextW converts all of its arguments to ansi then calls CryptAcquireContextA (which is intuitively not what we're wanting and thus the cleanup.) The question is, what exactly is the best way to clean this up? It seems to me that there are two main options as to what can be done: A) convert the W->A calls in the wide-char functions to A->W calls in the asci functions and implement the wide-char functions instead, or B) implement both asci and wide-char functions separately ie asci functions only call asci functions etc. If we are to choose plan A, I have seen several different methods of converting asci to wide-char, and I am wondering which method is best. for example: dlls/advapi32/crypt.c lines 133-141 wcount = MultiByteToWideChar(CP_ACP, 0, str, -1, NULL, 0); wcount = wcount < wstrsize/sizeof(WCHAR) ? wcount : wstrsize/sizeof(WCHAR); if (wstrsize == -1) *wstr = CRYPT_Alloc(wcount * sizeof(WCHAR)); if (*wstr) { MultiByteToWideChar(CP_ACP, 0, str, -1, *wstr, wcount); return TRUE; } and, dlls/advapi32/registry.c lines 1626-1636 LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, LPSECURITY_ATTRIBUTES sa ) { UNICODE_STRING *fileW = &NtCurrentTeb()->StaticUnicodeString; NTSTATUS status; STRING fileA; RtlInitAnsiString(&fileA, file); if ((status = RtlAnsiStringToUnicodeString(fileW, &fileA, FALSE))) return RtlNtStatusToDosError( status ); return RegSaveKeyW(hkey, fileW->Buffer, sa); } Which method is better/more efficient? I would have to argue that implementing both the asci functions and wide-char functions separately would be the most efficient way to solve the W->A problem. Throughout all the wine libs, many conversion calls are being made from W->A and A->W, when most of these calls could be left out. I think performance would improve without all of the conversion calls. Granted the size of the code would increase, but speed would also increase. There are a couple snags when it comes to implementing asci and wide-char functions independently, but that can be discussed later. If I'm totally off the mark, let me know, and if there are other jobs I could be doing, let me know as well because I would like to contribute, but I'm not exactly sure what to do yet. Thankyou for your time. James Hawkins truiken(a)comcast.net

4 4

Re: dlls/shell32 W->A cleanup of systray.c
by Marcelo Duarte June 30, 2004

June 30, 2004

Danny Hawkins wrote: >Hi, > >Converted all wide-char->ansi calls to ansi->wide-char in systray.c > > > The TTM_UPDATETIPTEXTA should be converted to TTM_UPDATETIPTEXTW and TTM_ADDTOOLA -> TTM_ADDTOOLW >@@ -272,13 +272,13 @@ > ti.rect.bottom = ICON_SIZE+2*ICON_BORDER; > > if(modify) >- SendMessageA(ptrayItem->hWndToolTip, TTM_UPDATETIPTEXTA, 0, (LPARAM)&ti); >+ SendMessageW(ptrayItem->hWndToolTip, TTM_UPDATETIPTEXTA, 0, (LPARAM)&ti); > else >- SendMessageA(ptrayItem->hWndToolTip, TTM_ADDTOOLA, 0, (LPARAM)&ti); >+ SendMessageW(ptrayItem->hWndToolTip, TTM_ADDTOOLA, 0, (LPARAM)&ti); > } > > Here, you should'nt cast (WCHAR *)"". Please define: static const WCHAR emptyW[] = {0}; Or modify the function to accept NULL. >@@ -297,15 +297,15 @@ > (*ptrayItem)->notifyIcon.hWnd = pnid->hWnd; /* only needed for callback message */ > SYSTRAY_ItemSetIcon (*ptrayItem, (pnid->uFlags&NIF_ICON) ?pnid->hIcon :0); > SYSTRAY_ItemSetMessage(*ptrayItem, (pnid->uFlags&NIF_MESSAGE)?pnid->uCallbackMessage:0); >- SYSTRAY_ItemSetTip (*ptrayItem, (pnid->uFlags&NIF_TIP) ?pnid->szTip :"", FALSE); >+ SYSTRAY_ItemSetTip (*ptrayItem, (pnid->uFlags&NIF_TIP) ?pnid->szTip :(WCHAR *)"", FALSE); > > The old code should be eliminated, not commented: >+/*{ > BOOL flag=FALSE; > TRACE("enter %p %d %ld\n", pnid->hWnd, pnid->uID, dwMessage); > switch(dwMessage) { >@@ -377,13 +390,30 @@ > } > TRACE("leave %p %d %ld=%d\n", pnid->hWnd, pnid->uID, dwMessage, flag); > return flag; >-} >+}*/ > > > >+/*{ > BOOL ret; > > PNOTIFYICONDATAA p = HeapAlloc(GetProcessHeap(),0,sizeof(NOTIFYICONDATAA)); >@@ -395,4 +425,4 @@ > > HeapFree(GetProcessHeap(),0,p); > return ret; >-} >+}*/ > >

1 0