wine-devel

wine-devel@winehq.org

8 participants
84486 discussions

DIB engine
by Francois Gouget 31 Mar '02

31 Mar '02

The DIB engine was discussed quite a lot at WineConf. I am now trying to summarize these discussions to update bug 421 - Implement a DIB engine. http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=421 Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers? This was discussed quite a bit at WineConf. Ideas that were floated around are: 1. Have X export the required API --------------------------------- XFree86 4 has all the needed code, for all bit depths and layouts we care about. We could try to have the X guys export this in the form of an API ala Xft. Wine could then link with this library to implement the DIB engine (or dlopen that library). * Is the needed API already available? * If not, are the XFree86 guys willing to export it? * Almost everyone is using XFree86, but what about people who don't (embedded devices, Wine on Solaris...). We need a fallback. * We won't have to maintain that code which is a good thing, although it is not supposed to change much once written. * Will we be able to do all that we need with that API? Probably yes since it can be expected to match the X API quite closely and we are abel to use the X API. 2. Copy the relevant X code into Wine ------------------------------------- Since X has all the code and that code is under the X11 license we could copy it all into Wine. * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. 3. Copy the relevant code from MicroWindows/NanoGUI to Wine ----------------------------------------------------------- MicroWindows/NanoGUI also has code that could help us bootstrap our DIB engine. We probably don't want Wine to depend on these projects but we could copy their code into Wine. * Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. 4. Copy the relevant code from GGI to Wine ------------------------------------------ GGI also has similar code. Again we probably don't want to introduce a dependency on GGI so the same questions apply: * Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

4 4

problem creating/finding files
by Insyde 30 Mar '02

30 Mar '02

Hi, I'm getting this error running a system under WINE: 0806faa8:Call kernel32.CreateFileA(405b63ec "C:\\WIN\\IY032097.DAT",80000000,00000003,00000000,00000003,08000001,0000000 0) ret=6002912b 0806faa8:trace:file:CreateFileA C:\WIN\IY032097.DAT GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING 0806faa8:trace:dosfs:DOSFS_GetFullName C:\WIN\IY032097.DAT (last=1) 0806faa8:trace:string:lstrcpynA (0x405b5a4c, "/mnt/c", 1024) 0806faa8:trace:dosfs:DOSFS_FindUnixName /mnt/c,WIN\IY032097.DAT 0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00010bfc): returning 403a9e6c 0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00000018): returning 403a7d10 0806faa8:trace:dosfs:DOSFS_FindUnixName (/mnt/c,WIN\IY032097.DAT) -> win (WIN) 0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a7d10): returning TRUE 0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a9e6c): returning TRUE 0806faa8:trace:dosfs:DOSFS_FindUnixName /mnt/c/win,IY032097.DAT 0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00010bfc): returning 403a9e6c 0806faa8:trace:heap:RtlAllocateHeap (40360000,00000002,00000018): returning 403a7d10 0806faa8:warn:dosfs:DOSFS_FindUnixName 'IY032097.DAT' not found in '/mnt/c/win' 0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a7d10): returning TRUE 0806faa8:trace:heap:RtlFreeHeap (40360000,00000002,403a9e6c): returning TRUE 0806faa8:warn:file:CreateFileA Unable to get full filename from 'C:\WIN\IY032097.DAT' (GLE 2) ......... 08079370:RET MFRTS32.1199: _mFfindp() retval = 409c5e90 ret=0042b3b7 08079370:CALL MFRTS32.1425: mF_fh_set_fe_stat(00000000) ret=0042b3c8 08079370:RET MFRTS32.1425: mF_fh_set_fe_stat() retval = 00000000 ret=0042b3c8 08079370:RET MFRTS32.1202: _mFg2star_fast() retval = 00000000 ret=0042889a 08079370:RET MFRTS32.1400: ixfile() retval = 00000000 ret=60025e45 08079370:RET MFRTS32.145: EXTFH() retval = 00000000 ret=0044095a 08079370:Call user32.MessageBoxA(00000000,004472de "External Path string <UPCW56-DEV-DATA-DIR> not found. File IYF029. "...,004471c8 "IYP139 ",00002010) ret=00404c01 08079370:warn:dialog:MessageBoxA Messagebox 08079370:trace:resource:RES_FindResource2 (4067a000, 00000005, 40718554"MSGBOX", 0000, A, PE) 08079370:trace:heap:RtlAllocateHeap (40360000,00000002,00000018): returning 403af734 08079370:trace:heap:RtlFreeHeap (40360000,00000002,403af734): returning TRUE 08079370:trace:resource:RES_LoadResource (4067a000, 407234f8, PE) ......... Seems like the file isn't being created. (Uwe Bonnes helped me with this). But we disagree what part of WINE (or outside WINE) is wrong. The first part of the log shows a CreateFileA that is unable to create a file. This API works fine when the file is in the same dir as the application (had tested it). The second part of the log shows the last screen I get after start the program (MessageBox API). MFRTS32 is a .dll the program calls. We thougth of there too. But this program works under Windows. Everything is in the path. Both wine.conf and Linux. I could reproduce the error in Win2k this way: Created a set of programs (L1, L2 and L3) that will run one after one with conditions. If the field in L1 is fulfilled then we jump directly to L3. Else We fulfill the field in L2 and then jump to L3. In details: L1 would creates a file with a name if the filed is fulfilled an L3 NEEDS to know that name. If we had to run L2 then the file will be with another name and L3 will get data from that file. But the file ins't created in neither of the cases. So a screen shows up: "External path string <G-PATH> not found. File FILE-LINUX." That message is the same I get under WINE: "External path string <UPCW56-DEV-DATA-DIR> not found. File IYF029." Refers to a file (IYF029), that exists (located in the ./data dir) but was not filled with data it need to work, or incorretly filled. Both G-PATH and UPCW56-DEV-DATA-DIR are variables of a file that has a number of them inside. As here we use APIs I'll list 2 of them that are used within the function and their definiton, took from MSDN: CreateProcess CreateProcess( LPCWSTR lpszImageName, LPCWSTR lpszCmdLine, LPSECURITY_ATTRIBUTES lpsaProcess, LPSECURITY_ATTRIBUTES lpsaThread, BOOL fInheritHandles, DWORD fdwCreate, LPVOID lpvEnvironment, LPWSTR lpszCurDir, LPSTARTUPINFOW lpsiStartInfo, LPPROCESS_INFORMATION lppiProcInfo); ........ StartupInfo.dwFillAttribute dwFillAttribute Ignored unless dwFlags specifies STARTF_USEFILLATTRIBUTE. Specifies the initial text and background colors if a new console window is created in a console application. These values are ignored in GUI applications. This value can be any combination of the following values: FOREGROUND_BLUE, FOREGROUND_GREEN, FOREGROUND_RED, FOREGROUND_INTENSITY, BACKGROUND_BLUE, BACKGROUND_GREEN, BACKGROUND_RED, and BACKGROUND_INTENSITY. For example, the following combination of values produces red text on a white background: FOREGROUND_RED| BACKGROUND_RED| BACKGROUND_GREEN| BACKGROUND_BLUE OBS.: We do NOT use this to send this kind of attributes. We DO send more data as we saw that it handles well. We also DO use this in gui applications. typedef struct _STARTUPINFO { DWORD cb; LPTSTR lpReserved; LPTSTR lpDesktop; LPTSTR lpTitle; DWORD dwX; DWORD dwY; DWORD dwXSize; DWORD dwYSize; DWORD dwXCountChars; DWORD dwYCountChars; DWORD dwFillAttribute; DWORD dwFlags; WORD wShowWindow; WORD cbReserved2; LPBYTE lpReserved2; HANDLE hStdInput; HANDLE hStdOutput; HANDLE hStdError; } STARTUPINFO, *LPSTARTUPINFO; ............... CreateFile HANDLE CreateFile( LPCTSTR lpFileName, // file name DWORD dwDesiredAccess, // access mode DWORD dwShareMode, // share mode LPSECURITY_ATTRIBUTES lpSecurityAttributes, // SD DWORD dwCreationDisposition, // how to create DWORD dwFlagsAndAttributes, // file attributes HANDLE hTemplateFile // handle to template file ); .................. Any thoughs? Thanks, Ricardo.

2 1

Improving the regression testing infrastructure
by Geoffrey Hausheer 30 Mar '02

30 Mar '02

I know regression testing isn't as interesting as doing real development, and so I appologize with once again spamming the list with regression questions... As I've been writing tests (only for the last week or so), I realized that as we get a lot more tests, it will be very difficult to keep track of what is being tested, and what is not. I'd like to propose a list of which functions for each DLL are being tested, which file tests it, as well as any comments on the current tests. Currently, there is no great way to do this. I may use several functions in a directed test which I am not actually testing (for instance I've found it necessary to retrieve the page-size using GetSystemInfo, but my tests have nothing to do with this function, and so writing a directed test for it is a task for another day). Thus just grepping for which functions are used in a test is not sufficient. Also, I have found that some functions, or even specific task functions are very difficult to test, and so I've been leaving these out so that perhaps people ore skilled than myself could take a crack at them late (A good example is testing inheritance with CreateThread. It is a task that is beyond my capabilities at the moment, at least until I can find a good way to test CreateProcess...this would be much easier if Windows had something equivalent to 'fork'). In any case, I've tried to be thorough about commenting what I do and don't test, but it would be a lot more convenient if this information was more easily parsed than trying to find my comments intersperesed through the tests. So does anyone thing that creating a easily parsable list with the state of the current tests is this a reasonable thing to do, and would creating a simple file in each /tests directory with the information be good enough? If so, I can add one to my next test, and update it with what I've done so far. In general, while Francois' presentation is a good place to get started, I think it'd be a lot easier if there was a document off of winehq with recommendations on how to build, test, and document tests. Lowering the difficulty threshold, is more likely to draw more people to do so. Thanks, .Geoff

4 11

Re: Wine List Control compatibility
by Tony Lambregts 30 Mar '02

30 Mar '02

Peter Quax wrote: >Hello, > >>>Some things will break if you start trying to use a bunch of native >>>DLLs. And especially trying to use the native comctrl is likely to break >>>things. >>> >>>That said, I downloaded and tried out the program. To get it to run, I >>>used these native DLLs: >>> > >>>With that, the listview appears to be working for me just fine, assuming >>>you are talking about the one with the labels Oefening, Titel, and Item. >>>This is with current CVS. >>> >>I get about the same thing with the same problems (except I havent >>crashed) but I have some time.It would be much easier if there is an >>english version of this program.I don't have a soundcard.(maybe thats >>why I havnt crashed yet). I probably could get one. Does anyone want to >>recommend a cheep one that works well with linux? >> > >Both of you, thanks very much for your help. > >First of all I forgot to mention that the use of sound is not an issue (we >don't use that at our school), so that is not a problem whatsoever. > >I tried using the dll configuration as given and indeed it shows the list >control (just as it did before), but as I mentioned the image lists are >incorrect. To demonstrate this, I've taken a couple of screen shots to give >you an idea of what it should look like : > >http://alpha.luc.ac.be/~lucp1313/juniorwin.jpg : this is the windows version >that shows the correct icons in the list control (at the bottom) > >http://alpha.luc.ac.be/~lucp1313/juniorwine.jpg : this is the wine version >which demonstrates the incorrect behaviour of the icons > >You can clearly see that there is a difference. Now, when I doubleclick for >example 4-1 in the 'oefening' column to start this exercise, the window that >comes up doesn't show all of the text. A second anomaly is that from time to >time, the cursor will disappear. This is shown in the next 2 screenshots : > >http://alpha.luc.ac.be/~lucp1313/juniorwin2.jpg : this is the windows >version that shows the correct text > >http://alpha.luc.ac.be/~lucp1313/juniorwine2.jpg : this is the wine version >which demonstrate the lack of text in the upper left corner > >I hope this made my problems a bit more clear ? Also, I'm afraid that there >isn't an english version of this package available. I tried contacting the >authors but they don't seem to respond to any of my emails. > >Again, thanks for all your help > >Regards, >Peter Quax. > It looks like its not translating the color palet correctly. What color depth are you running at? My guess is that it is 16. If this is correct then try increasing it. It may be that the text is just not showing up because of this problem. I have CC:ed the Wine development list in order that the real wine gurus can have a look at this. How long do you have before you have to subject the little children to the "Windows Solution". Tony Lambregts

1 0

RE: Improving the regression testing infrastructure
by Geoffrey Hausheer 30 Mar '02

30 Mar '02

> > True. So what we need is to add a function in the > testing framework > > so that tests can get argc/argv/envp. Seems like a > reasonable approach. > I was more thinking adding some wt_argc and wt_argv, with init in main > so that we don't have to deal with the portability issues of > the __argc, > __ ARGC... Is there a reason we can't just use environment variables rather than argc/argv? I would think that would be less of a hassle than using argc/argv. .Geoff ----------------------------------------------------- Protect yourself from spam, use http://sneakemail.com

3 2

Unicode header control used by listview
by Uwe Bonnes 29 Mar '02

29 Mar '02

Hallo, some application made from a zip archive "4957.exe", that uses the listview.c sample from microsoft floating around since at least 1996, uses commctrl headers and shows only the first letter of the text in the header tabs. This is caused by (wine) listview.c creating the header windows as unicode, but in the commctrl initialization the header class was registered as ascii. When the header text is inserted, it is translated to unicode. When it is read out for display, it is treated as ascii, as the unicode flag of the header control isn't set. So reading of only one character succeeds. So either we set the header unicode-flag when creating the header control in listview, or we register the header class as unicode. Appended patch switches the charset after creating the control in listview.c. Does this sound right? Feedback welcome! Changelog dlls/comctrl32/listview.c: LISTVIEW_Create Switch header control charset to unicode -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing -- Index: wine/dlls/comctl32/listview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.125 diff -u -r1.125 listview.c --- wine/dlls/comctl32/listview.c 20 Mar 2002 00:53:42 -0000 1.125 +++ wine/dlls/comctl32/listview.c 29 Mar 2002 20:58:21 -0000 @@ -8002,6 +8002,9 @@ 0, 0, 0, 0, hwnd, (HMENU)0, lpcs->hInstance, NULL); + /* set header unicode format */ + SendMessageW(infoPtr->hwndHeader, HDM_SETUNICODEFORMAT,(WPARAM)TRUE,(LPARAM)NULL); + /* set header font */ SendMessageW(infoPtr->hwndHeader, WM_SETFONT, (WPARAM)infoPtr->hFont, (LPARAM)TRUE);

1 0

freetype
by Morten Welinder 29 Mar '02

29 Mar '02

I get the message *** Note: Your system appears to have the FreeType 2 runtime libraries *** installed, but 'freetype-config' is not in your PATH. Install the *** freetype-devel package (or its equivalent on your distribution) to *** enable Wine to use TrueType fonts. even though I do have freetype-config in my PATH. It seems related to the test dnl Check that we have at least freetype/freetype.h if test "$ac_cv_header_freetype_freetype_h" = "yes" -a "$wine_cv_fttrigon" = "yes" (Note: comments, message, and code do not agree) I don't seem to have the <ft2build.h> and <freetype/fttrigon.h> files. Should I? This is on a SuSE7.3 system, FWIW. Morten

1 0

cvs doesn't build .. my fault?
by Paul Millar 29 Mar '02

29 Mar '02

Hi, A couple of things: First, I've noticed cvs didn't build for me anymore. The problem was because I removed the header files for ncurses (ie removed the ncurses-devel RPM). The file dlls/ttydrv/bitmap.c then failed to compile. Having had a look at the code in ttydrv, its fairly obvious it wont build without either curses or ncurses installed. A simple patch (wine-diff-1) provides a better error message. It shouldn't be needed (with the next patch), but might help bug finding in the future. But, shouldn't wine simply abstain from building ttydrv if a (n?)curses package isn't available? I've attached another patch (wine-diff-2) that does that. AFAIK, there's no knock-on effects. Second problem, when attempting to verify the build-failure on a different machine (hathi), it failed, but in a different part of the build! It only succeeded on the third machine (romulus) On hathi, a RH-7.0 (w/ Linus-2.4.3 kernel) I got: > make[2]: Entering directory `/disk/hathi1/paulm/wine/dlls/ntdll' > LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" > ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c > -spec ./ntdll.spec > make[2]: *** [ntdll.spec.c] Segmentation fault (core dumped) [...] After some investigation, it transpires that gcc on hathi (the RH-7.0 machine) builds broken winebuild programs (the unicode library was fine). The RH-7.1 (romulus) could "fix" the problem by recompiling just the winebuild directory. The problem turned out to be because I had old gcc-2.96 RPMs installed. After updating to the latest upgrade RPMs winebuild is built correctly, but wrc is now broken: it segfaults whenever its run. Can anyone with a 7.0 machine verify this? Cheers, Paul.

3 3

how to unsubscribe?
by Ludootje 29 Mar '02

29 Mar '02

Hello, First of all I'd like to say I'm sorry to both you people with this. I tried some stuff to unsubscribe by going to the default urls of sourceforge lists etc, but that didn't helped. I went to wine.sf.net, but didn't found any public mailing list, and I can't remember where I subscribed to this list. The reason I want to unsubsribe (temporariliy) is that I'm off for vacation, and don't feel like reading tons of wine-devel mails when I'm back ;-) So, where can I unsubscribe, and resubscribe (for when I'm back)? Or even better, is there an option like with sourceforge lists where I just edit my preferences and check the box which says I don't want to receive any mails anymore temporarily? Thanks in advance, Ludootje --- Linux: because rebooting is for adding hardware. M$: because choices are confusing.

3 2

update in EDIT_WM_SetText
by Rizsanyi Zsolt 29 Mar '02

29 Mar '02

Hi! I have this next patch: --- controls/edit.c Fri Mar 29 19:03:25 2002 +++ controls/edit.c Fri Mar 29 19:03:09 2002 @@ -4727,7 +4727,10 @@ * if it is multiline, or it is part of combobox */ if( !((es->style & ES_MULTILINE) || es->hwndListBox)) + { EDIT_NOTIFY_PARENT(hwnd, es, EN_CHANGE, "EN_CHANGE"); + EDIT_NOTIFY_PARENT(hwnd, es, EN_UPDATE, "EN_UPDATE"); + } EDIT_EM_ScrollCaret(hwnd, es); } Which fixes an update problem in my program. As much as I understand the program reeds the state of the edit on every EN_UPDATE event. And because EN_UPDATE was not sent, so the program operated with undefined values and could not find the words (its a dictionary program). I see, that the above code is somewhat weird, because two events are sent. But of course if the programs rely on it, then it has to be so. I will let to somebody more acquinted with wine and windows to decide whether this solution is ok. Best regards Zsolt Rizsanyi

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel