wine-devel

wine-devel@winehq.org

84471 discussions

Re: Fix to protect users from selves.
by Guy L. Albertelli 30 Sep '02

30 Sep '02

To all that answered: I also abhor the kludge that I wrote. I also recognize that the test would catch possible *valid* filenames. I will attempt to find the keys that cause the rename to occur. However, the point of the patch was to: 1. Provide the developers with a way not to have their Windows system (real or fake) be renamed during development. I got tired of renaming the directories back to what they should have been. 2. Protect the end users from destroying their Windows system during testing/playing. The last thing we should want is the impression that Wine is dangerous because of unexpected consequences due to simple appearing actions. "comp.emulators.ms-windows.wine" still gets complaints from user that have done this very action. Guy

2 1

CVS server broken ?
by Sylvain Petreolle 30 Sep '02

30 Sep '02

Hi, trying to do a cvs update I get nothing on screen today, even when trying to do a simple cvs status (normally it would take seconds). cvs.winehq.com responds to ping though, could an admin look at it ? Thanks for your action. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

Debugger no more starting
by Uwe Bonnes 30 Sep '02

30 Sep '02

Hallo, since some time for me the debugger doesn't start when a program crashes. As there was a lot of reorganization, my non-standard setup (try to run wine in place) and due to lack of time to verify (workload, holidays) I can't tell when exactly the breackage occured. The exception (here in a simple test program, doing an int21 in 32 bit mode), the exception is thrown. win32/exception.c:start_debugger_atomic() creates the event 088f7250: queue_exception_event() = 0 { handle=0 } 088f7250: create_event( manual_reset=1, initial_state=0, inherit=1, name=L"") 088f7250: create_event() = 0 { handle=100 } wine: Unhandled exception, starting debugger... ... The event-handle is passed to the winedbg command line: trace:seh:start_debugger Starting debugger format_size 58 (fmt=h:\tmp\wine\compile\wine\programs\winedbg\wined bg %ld %ld) trace:seh:start_debugger h:\tmp\wine\compile\wine\programs\winedbg\winedbg 134683568 100 088f7250: *signal* signal=14 088f7250: create_file( access=80000000, inherit=0, sharing=00000001,create=3, attrs=00000000, drive_type=4, f ... We select on that handle: 088f7250: select( flags=4, cookie=0x412d05e0, sec=0, usec=0, handles={100} ) ... After winedbg startup, winedbg tries to set this event 088f75a0:Ret kernel32.DebugActiveProcess() retval=00000001 ret=404e1f04 088f75a0:Call kernel32.SetEvent(00000064) ret=404e33b6 088f75a0: event_op( handle=100, op=1 ) 088f75a0: event_op() = INVALID_HANDLE 088f75a0:Ret kernel32.SetEvent() retval=00000000 ret=404e33b6 but the event is invalid and winedbg shuts down immediately: 088f75a0:Call kernel32.ExitProcess(00000000) ret=404ca18f Any idea, what's going wrong? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 7

dlls/ completion nit
by Dimitrie O. Paun 30 Sep '02

30 Sep '02

Hi guys, You'll probably think I'm crazy, but here it goes :) : I work a *lot* from the the command line, and I depend quite a bit on completion. Problem is, all those xxx.dll.so links in dlls/ are screwing with it sometimes, as is the case for avifile.dll.so, etc. Even when the dir name is a proper prefix of the link, it's still annoying as I don't get the / completed automatically, then I hesitate whether to add it or not, and so on. So my small proposal: what about creating them in a sub dir, say dlls/lib or something like that? I'd be willing to cook up a patch, if people are OK with the idea. ;) -- Dimi.

4 6

Re: Listview updates (G0)
by Paul Rupe 30 Sep '02

30 Sep '02

On 27 Sep 2002, dpaun(a)rogers.com wrote: > @@ -3564,7 +3604,6 @@ > dis.rcItem.bottom = dis.rcItem.top + > infoPtr->nItemHeight; OffsetRect(&dis.rcItem, ptOrig.x, > 0); > > - ZeroMemory(&item, sizeof(item)); > item.iItem = nItem; > item.iSubItem = 0; > item.mask = LVIF_PARAM; > @@ -5555,7 +5584,6 @@ > { > LVITEMW lvItem; > > - ZeroMemory(&lvItem, sizeof(lvItem)); > lvItem.mask = LVIF_INDENT; > lvItem.iItem = nItem; > lvItem.iSubItem = 0; With these two ZeroMemory calls removed, I'm getting crashes in Xnews due to the uninitialized pszText member. In both cases, it happens when LISTVIEW_GetItemT gets the LVITEMW structure and calls notify_dispinfoT (line 5186 or so). -- Paul Rupe "She smiled, in the end." p r u p e @ m y r e a l b o x . c o m | Oppose government police-ware on your PC! | Stop the Consumer Broadband and Digital Television Promotion Act! | <http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html>

3 3

Re: Fix to protect users from selves.
by Dmitry Timoshkov 29 Sep '02

29 Sep '02

"Guy L. Albertelli" <galberte(a)neo.lrun.com> wrote: > files/file.c > - Prevent Explorer.exe from renaming directories to !$!$... I'm strongly against adding such kludges in the Wine source. -- Dmitry.

3 2

Printing with CUPS
by Mason Kidd 29 Sep '02

29 Sep '02

I'm having trouble printing using CUPS. When I try and print in notepad I get a dialog saying: Cannot print the Untitled file. Be sure that your printer is connected properly and use Control Panel to verify that the printer is configured properly. My setup is Redhat 7.3 with the following CUPS packages: cups-libs-1.1.14-15 cups-drivers-hpijs-1.1-0.20020313.3 cups-devel-1.1.14-15 cups-drivers-pnm2ppa-1.1-0.20020313.3 cups-1.1.14-15 cups-drivers-1.1-0.20020313.3 I have tried both wine-20020409 and the latest CVS. I am printing to a HP Laserjet 1100 using the "HP LaserJet 1100, Foomatic + gimp-print" driver. This is setup to print using IPP to a print server that is also running CUPS(same version). I have not modified any of the printing or fonts options in the wine config file, since the instructions say it is automatic. I am printing from Notepad. Doing a trace of the PSDRV, it reads all of the AFM files and detects the fonts ok. Also, during ParsePPD it finds all of the paper sizes correctly. But then I get a message: trace:psdrv:PSDRV_FindPrinterInfo No 'Paper Size' for printer 'hplj1100' trace:psdrv:PSDRV_FindPrinterInfo No 'FontSubTable' for printer 'hplj1100' And then when it tries to print: trace:psdrv:PSDRV_CreateDC (WINEPS hplj1100 LPT1: (nil)) trace:psdrv:PSDRV_UpdateDevCaps ImageableArea = 0,0 - 0,0: PageSize = 0x0 trace:psdrv:PSDRV_UpdateDevCaps devcaps: horzSize = -2147483648mm, vertSize = -2147483648mm, horzRes = 0, vertRes = 0 Which doesn't seem right. It then selects the pen and brush, and looks like it will print, and the it calls DeleteDC. I have attached the full trace, with +psdrv and +commdlg. I have a full trace at: www.mrkidd.com/~mrkidd/print.trace.txt It really seems like it is almost working, but something is wrong with the paper size. How can I find why it sets everything up and then deletes the DC? Anyone have any ideas? Mason Kidd

1 0

Wine ToDo's
by Thomas Wickline 29 Sep '02

29 Sep '02

Hello, Here is the current state of the ToDo's. If anyone is aware of changes that need to be made please let me know . Tom ---------------- Wine ToDo's as of 9/26/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * ASCII function work Winsock: * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec. DirectSound: * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Sound drivers: * Alsa driver (on final 0.9 interface) Video: * Implement native codecs (RLE...) GDI: * Write a DIB engine * DIB engine to do 32-bit graphics manipulation DDE: * Enhance memory management issues (interprocess sending) Wineconsole: * Add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) Native programs: * Winhelp: fix invocation thru WinHelp * Winedbg: make winedbg use dbghelp DLL File management: * Implement NT file namespace * UNC support * Allow flexibility in FS "mounting" (for example, SMB shares) Fonts: * Support for non-TT fonts (eg Type1, bitmap, ...) * Support for client side rendering on non-RENDER enabled XServers * Subpixel rendering - a.k.a. ClearType. * Integration with libfontconfig * Reduce per font startup time. * Libfontconfig support Printers: * Write a printer configuation applet * Fix the Type1 font downloader for HP4000 printers Tools: * Wine installation process should install and configure wine * Winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions: * Write a proper Users Guide Introduction * Documentation updates Aspect or Component: * More DLL Separation * BiDi support * Review of Wine Server Protocol * Finalize Server Protocol * PAM (Pluggable Authentication Modules) * Visual C++'s native COM support * Add DWARF2 support * Speed up PDB support * Create replacement of browser component (Internet Explorer/I Porting issues for Mingw/Cygwin/MS_VC * Better seperation of win16/32 code. * Remove/rewite win16/9x api dependancy on newer code * Remove/rewrite wineisms from code * Rewrite/fix unixisms in most WINE dlls * Documentation fixes low priority items: * VxD support with dynamic loading Add links to: Tasklets: http://bugs.winehq.com/buglist.cgi?keywords=tasklet tasklist: http://bugs.winehq.com/buglist.cgi?keywords=tasklist For a full list of .9/1.0 task's

4 4

Re: Accept -g3 stabs info (sketchy?)
by Eric Pouech 29 Sep '02

29 Sep '02

> + case 'k': /* 'const' modifier */ > + case 'B': /* 'volatile' modifier */ > + /* just kinda ignore the modifier, I guess -gmt */ > + if (DEBUG_PTS_ReadTypedef(ptd, NULL, &ref_dt) == -1) return -1; > + new_dt = DEBUG_NewDataType(DEBUG_GetType(ref_dt), NULL); > + /* I don't get this.. but I figure this is kind of like "r" > + so I cut and pasted from there ... -gmt */ > + assert(!*DEBUG_FileSubNr2StabEnum(filenr1, subnr1)); > + *DEBUG_FileSubNr2StabEnum(filenr1, subnr1) = new_dt; > break; > case '(': > ptd->ptr--; this should rather be: + break; + case 'k': /* 'const' modifier */ + case 'B': /* 'volatile' modifier */ + /* just kinda ignore the modifier, I guess -gmt */ + if (DEBUG_PTS_ReadTypedef(ptd, NULL, &new_dt) == -1) return -1; patch is untested anyway (gcc 2.95 doesn't emit those, even in -g3 mode) however, it's strange that your gdb like debuggers crash in -gstabs2 mode IMO, we should keep (as of today) wine in -gstabs2 mode and not jump to level 3 A+

2 2

Call for feeback
by Thomas Wickline 29 Sep '02

29 Sep '02

Hello , When I started the ToDo's I was unsure about what section to place some Tasks under so I just made... 1) Tools: 2) Instructions: 3) Aspect or Component: And placed items under those three sections and ask for feedback about where they belong. I have moved alot of the Tasks from my original list to there proper place. This is the remaing list .. If it looks alright can someone just say everything looks fine ? If something is out of place and you know where it goes can you * please * let me know where it goes. I dont feel comfortable making changes that im not totally sure about . I just want the page to have up to date and ACCURATE information on it ... Should there be a compile/build section ?? Tom --- Remaing list Tools: * Wine installation process should install and configure wine * Winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions: * Write a proper Users Guide Introduction * Documentation updates Aspect or Component: * More DLL Separation * Review of Wine Server Protocol * Finalize Server Protocol * PAM (Pluggable Authentication Modules) * Visual C++'s native COM support * Add DWARF2 support * Speed up PDB support * Create replacement of browser component (Internet Explorer/I

1 0

Unable to compile current CVS
by Ann and Jason Edmeades 29 Sep '02

29 Sep '02

No, we should be able to compile withiout mesa if we did before my patch. Unfortunately I dont know how to do this (I did warn alongside my patch) - Is there any chance you could work out how dlls/ddraw handles this issue so we can do the same. I suspect for non-gl enabled machines (until we go via a HAL) we should hava a d3d8.dll which just returns an error on the Direct3DCreate8 call. Jason

1 0

ToDo's
by Thomas Wickline 29 Sep '02

29 Sep '02

Hello, Here is the changes to ( National Language Support ) Does it look alright with everyone ? If not let me know and ill patch it again . Everything else is the same I removed BiDi from Aspect or Component: as well. Tom ---- Wine ToDo's as of 9/29/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * Make sure ASCII functions call the Unicode one and not the other way around. * BiDi support * Add support for Hebrew and Arabic * Add support for more keyboard layouts to x11drv * Figure out what should be done for better support of Chinese, Korean, Japanese -- snip

1 0

Re: wineoss patch
by Eric Pouech 29 Sep '02

29 Sep '02

Ove Kaaven a écrit : > > I can imagine Eric has a better patch for the following problem: > OSS/Commercial does not allow an open device to continue operation after a > SNDCTL_DSP_RESET, the device must be reopened (which is what their API > docs recommend). The following patch is what we have in WineX to get > around the issue, but it will only compile on ReWind and Wine if the > #define FULL_DUPLEX is enabled. But perhaps it's good enough if Eric > doesn't have a better one. And I have some fullduplex patches that I can > only submit after this issue is resolved. I think the best way is to store device parameters in all cases (full duplex or not) and then make use of them (transform the reset in close/open pair) moreover, full duplex infra has been around for a while, and didn't generate much complains... so I think we can remove now the support for the non FULLDUPLEX part finally, wine now as a notion of OSSDEVICE (shared by wavein and waveout) which could make some function defs a bit simpler I'll try to whip something out from Ove's first patch A+

1 0

Re: Implement {G|S}etWindowLongPtr
by Eric Pouech 29 Sep '02

29 Sep '02

György 'Nog' Jeney a écrit : > > Apply this patch and observe nearly the whole wine recompile :) > > ChangLog: > * include/winuser.h > * win/win.c > Implement {G|S}etWindowLongPtr I don't want to see a whole wine recompilation every day, so I think those defs #define SetWindowLong WINELIB_NAME_AW(SetWindowLong) +LONG_PTR WINAPI SetWindowLongA(HWND,INT,LONG_PTR); +LONG_PTR WINAPI SetWindowLongW(HWND,INT,LONG_PTR); +#define SetWindowLongPtr WINELIB_NAME_AW(SetWindowLongPtr) should be instead #define SetWindowLong WINELIB_NAME_AW(SetWindowLong) +LONG_PTR WINAPI SetWindowLongPtrA(HWND,INT,LONG_PTR); +LONG_PTR WINAPI SetWindowLongPtrW(HWND,INT,LONG_PTR); +#define SetWindowLongPtr WINELIB_NAME_AW(SetWindowLongPtr) A+

1 0

Exception while trying to install winace 2.2
by György 'Nog' Jeney 29 Sep '02

29 Sep '02

While trying to get the winace 2.2 installer to run on wine, I got the following exception without any messages on the console: First chance exception: page fault on read access to 0x23c94fed in 32-bit code (0x23c94fed). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:23c94fed ESP:40682e52 EBP:00400000 EFLAGS:00010646( R- 00 DI Z- -P1 ) EAX:00000000 EBX:40682e66 ECX:0000038b EDX:00420654 ESI:00000001 EDI:0044efb5 Stack dump: 0x40682e52 (_end+0x32cc32): 004209e2 40682e98 00420658 00000000 0x40682e62 (_end+0x32cc42): 00000000 00463047 0042066b 40682f44 0x40682e72 (_end+0x32cc52): 00463000 401111c0 00000001 40682f38 0x40682e82 (_end+0x32cc62): 40682e96 400fd024 00463042 00000600 0x40682e92 (_end+0x32cc72): 00463000 2f440246 c81a4068 66b12fc3 0x40682ea2 (_end+0x32cc82): c19d6f8a 25b92f81 51634d58 33c04011 0x40682eb2 (_end+0x32cc92): 0011: sel=008f base=401133c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x23c94fed (_end+0x1bc38885) (ebp=00400000) 1 0x00000002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) 0x23c94fed (_end+0x1bc38885): *** Invalid address 0x23c94fed (_end+0x1bc38885) -- no code -- It seemd to me that the stack frame(s?) got corrupted so I debugged further. It seems that the app throws an exception and catches it later on. I set a breakpoint on EXC_CallHandler where the backtrace still looked fine. Just before wine calls the exception handler, it pushes edx and then edi onto the stack, then the handler gets called: call *%edx. This puts excecution into 0x420658 which calls 0x4206ac. The assembly code at 0x4206ac looks like this: 0x004206ac (wace22.exe.+0x1f6ac in C:\wace22.exe): xorl %eax,%eax 0x004206ae (wace22.exe.+0x1f6ae in C:\wace22.exe): popl %esi 0x004206af (wace22.exe.+0x1f6af in C:\wace22.exe): movl %fs:0x0(%eax),%ebx 0x004206b2 (wace22.exe.+0x1f6b2 in C:\wace22.exe): movl 0x0(%ebx),%ebx 0x004206b4 (wace22.exe.+0x1f6b4 in C:\wace22.exe): leal 0xffffffd6(%ebx),%esp 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe): popl %ebp This last pop is what makes the backtrace weird, before this the backtrace looks like: =>0 0x004206b7 (wace22.exe.+0x1f6b7 in C:\wace22.exe) (ebp=40570938) 1 0x400c84c0 (EXC_RtlRaiseException+0x10c(rec=0x405709dc, context=0x40570a34) [exception.c:214] in libntdll.dll.so) (ebp=405709c0) 2 0x400d26e9 (do_segv+0x1a5(context=0x40570d1c, trap_code=0x400d2b98, cr2=0x40570a50, err_code=0x1) [signal_i386.c:798] in libntdll.dll.so) (ebp=40570a2c) 3 0x400d2b4c (segv_handler+0x3c(__signal=0x2b, __context=0x2b) [[signal_i386.c:986] in libntdll.dll.so) (ebp=40570d28) 4 0x0000008f (ebp=00000000) But after it, it looks like this: =>0 0x004206c1 (wace22.exe.+0x1f6c1 in C:\wace22.exe) (ebp=00400000) 1 0x00000002 (ebp=00505a4d) *** Invalid address 0x00505a4d (wace22.exe.EntryPoint+0xa2a0b) Is this normal? If I just continue from this point then the first exception will be thrown but quite a lot of functions get called between here and that exception. The exception handler never does return. Any one have any ideas as to what might go wrong here? nog.

1 0

Unable to compile current CVS
by Guy L. Albertelli 29 Sep '02

29 Sep '02

It seems that the D3D8 code depends heavily on both GL/gl.h and GL/glx.h being present. My system RH 6.1 does not have those header files. Is GL a requirement for developers now?? Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>> Bathed in his currents of liquid helium, self-contained, immobile, vastly well informed by every mechanical sense: Shalmaneser. Every now and again there passes through his circuts a pulse which carries the cybernetic equivalent of the phrase, "Christ, what an imagination I've got. " - Stand on Zanzibar by John Brunner

1 0

patch to MZ_Exec() PE executables
by Chris Morgan 28 Sep '02

28 Sep '02

Guess this got lost when I mailed it from my web mail account... Look reasonable? dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Add PE support to MZ_Exec().

2 1

Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527)
by Uwe Bonnes 28 Sep '02

28 Sep '02

Hallo, the Open-GL Mesa patches (http://cvs.winehq.com/patch.py?id=5527) in wine/dlls/ddraw/mesa_private.h unconditional inclused GL/gl.h and GL/glx.h. On my Suse V8.0 system ( with the mesa package installed and the mesa-devel package not installed) this leads to: make[2]: Wechsel in das Verzeichnis Verzeichnis »/home/bon/tmp/wine/compile/wine-realclean/wine/dlls/ddraw« gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTR ANT -I/usr/X11R6/include -o dsurface/main.o dsurface/main.c In file included from dsurface/main.c:27: mesa_private.h:32: GL/gl.h: Datei oder Verzeichnis nicht gefunden mesa_private.h:33: GL/glx.h: Datei oder Verzeichnis nicht gefunden make[2]: *** [dsurface/main.o] Fehler 1 Probably it's a bad idea to only install mesa and not mesa-devel, but I think wine should cope with this situation or at least warn the user about that. 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

Re: A problem reading configuration file
by Sylvain Petreolle 28 Sep '02

28 Sep '02

Me too. I made some programs with assembly under MS-DOS in the 90s before switching to Linux ;) > I think its normal. Findfirst finds the first entry, and findnext > returns only > the next :) > I'm sure it works that way. I have tried to check that in some > documentation, > but if I remember right then I have used those in something like > Borland > Delphi at the university. But I dont have Delphi at home... > > If that is ok, then do you have some idea, what could be the problem? > There was a patch applied few days ago on findnext... perhaps it's it. http://www.winehq.com/hypermail/wine-patches/2002/09/0243.html ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: A problem reading configuration file
by Sylvain Petreolle 28 Sep '02

28 Sep '02

Remarque : message transféré en pièce jointe. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Fix for msvcrt sscanf/swscanf
by Uwe Bonnes 28 Sep '02

28 Sep '02

>>>>> "Jukka" == Jukka Heinonen <jhei(a)iki.fi> writes: Jukka> Wine msvcrt sscanf and swscanf implementations incorrectly expect Jukka> strings to end with EOF. This crashes some applications which did Jukka> work with older versions of Wine that just forwarded msvcrt Jukka> sscanf to libc sscanf. Jukka> Changelog: Functions sscanf and swscanf now expect strings to be Jukka> terminated with null (0) instead of EOF (-1). I asked some weeks ago about the test framework for msvcrt, but nobody jumped on the waggon. The mix of msvcrt and libc was something I couldn't do myself. Perhaps somebody can come up with someting. It sure is important to codify findings like Jukkas. 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

Re: [Controversial] Developper only CVS sandbox
by Dan Kegel 28 Sep '02

28 Sep '02

I've strongly opposed to using ClearCase for Wine development :-) I'm also somewhat opposed to CVS. The big problem with CVS is that it makes it *too* easy to contribute changes, and too hard to disentangle changes later when trying to contribute them back to the main tree. (This kind of thing has caused huge nightmares in the past.) So all you folks that feel that creating and posting patches is hard -- the payoff is *each change is much easier to peer review*. That makes for much higher quality code! If you really want to use a CVS-like system, go have a look at Bitkeeper. It's free for open source projects, and it is the only source code control system that doesn't make it hard to disentangle changes later. - Dan

2 1

Re: RFC: Winsock todo's
by Dan Kegel 28 Sep '02

28 Sep '02

Martin Wilck wrote: > Although I had a relevant part in implementing the asynchronous IO in > winsock, I am not quite content with it because it is not really > asynchronous. And not really high-performance, I bet (though I wouldn't know, I haven't looked at the code or tested it). > Alexandre is against using threads. Me, too. glibc uses threads to emulate aio, and the performance is poor. On platforms that natively support AIO, I bet you *really* want to implement Wine AIO using Posix AIO if you can. > On Linux at least, Ben > LaHaise's asyncio can be expected to become part of the > 2.6 kernel series, and if that happens the wine asynchronous IO > functionality should be rewritten to use the asyncio API on systems that > support it. Yes. Exactly. > (I still havent't figured out whether aio will support > sockets, though). It will. SGI's kaio does already, and Ben's will support it when he's finished. That should give good performance. - Dan p.s. Looks like the threads implementation for the 2.6 kernel will rock, too. See http://www.kegel.com/c10k.html#threaded (Somebody remind me why Wine has its own threads implementation again? Is it because the semantics are too different from Posix threads?)

1 0

Status of *ongoing* wine improvements?
by Dan Kegel 28 Sep '02

28 Sep '02

The To-Do list Steven Edwards is putting together looks like a nice menu of Things That Need To Be Done But Have Not Been Started Yet. A similar list, of ongoing work, might be useful in a different way. Check out http://www.kernelnewbies.org/status/ It has a number of nice features: * status of each proposed enhancement (planned / started / alpha / beta / ready / merged) * each line is a link to a wine-devel post or web page describing the proposed work * each line has the names of people actually working on them * items changed since last week are bold * only items expected to be finished before the feature freeze for the next release are included This list might be pretty short for Wine, but it'd be a nice way of tracking progress. - Dan

1 0

Re: DIB engine
by Gavriel State 28 Sep '02

28 Sep '02

Ove Kaaven wrote: > Well, here is the DIB engine that a couple of people at TransGaming > (mostly David Hammerton, I think) did some work on a while ago, I finally > got around to review it and make sure it compiles against the current > ReWind (though perhaps it needs a few tweaks to compile against Wine). > It's not all that complete by any means, but we wanted to get it out > there, so feel free to comment on it (or even apply it to Wine if it's > good enough). Primary attribution should go to Jonathan Meunier, a co-op student who worked with us earlier this year. David Hammerton, Peter Hunniset, and I all assisted with it to one degree or another. If there is any general interest in pursuing DIB Engine work, we would of course appreciate it if developers are willing to license their contributions to ReWind. Ove seems to have forgotten to include the documentation, which includes some nice background on DIB issues in general, and should go into the documentation directory. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ gav(a)transgaming.com TRANSGAMING TECHNOLOGIES DIB ENGINE DOCUMENTATION (GDI RENDERER) Copyright (c) 2002 TransGaming Technologies Inc. SCENARIO -------- The Win32 API allows for a graphics format called DIBSections. DIBSections allow the application to write to the image in two ways: Direct Access and through GDI. Direct Access means that the application can simply write whatever data it likes to the image - the application has a pointer to the physical image bits, and can write to this with no problem. In ReWind's X11 Driver we can emulate this kind of access by using XImages. The GDI access allows the application to do a whole heap of extra stuff to its graphics, including special rendering such as lines, polygons, ellipses and so on. ReWind emulates such calls through the use of X11's renderer by using XPixmaps. With a DIBSection, the Win32 API allows both of these features to be used on a single image. This is currently supported by ReWind, but it can be slow at times and rather 'hacky'. This is achieved using the following method: o When a DIBSection is created, space is allocated for the application (where the application can directly write to). This is also an XImage. o Another XImage is created for 'conversions' (see depth conversion). o An XPixmap (which is a X Drawable) is created on the X Server. o The application-side data is memory protected to no access. Now, ReWind's X11 driver keeps track of which "image" is most up-to-date, it has 3 mods: gdimod, appmod and insync. (There is actually a 4th mod called 'auxmod' which is used for auxiliary tasks such as OpenGL). These mods represent different states, as follows: o gdimod means that the XPixmap has the most up-to-date version of the image, it was written to last. o appmod means that the application has the most up-to-date version, it has written the image data manually. o insync means that the both the images are up-to-date, they contain the same data. The application can then write into the memory which it is given direct access to, but when it tries to do so a segmentation fault is raised because the memory has been protected. This segmentation fault is caught by ReWind which it recognizes as an attempt to access the application data of a DIBSection. A "coercion" is now called on this DIBSection. If the DIBSection is in gdimod at the time of the segmentation fault, a copy is necessary before we allow the application to write to the DIBSection. The Pixmap is then fetched from X and placed into the XImage in the correct format. The Application is now free to write to the image data, the DIBSection is placed in appmod. A similar thing happens when a GDI painting function gets called, we ensure that the DIBSection is in gdimod (The Pixmap is up-to-date). X is then free to to its rendering. A Problem: Depth conversions and X Limitations: There are many other "nicer" ways that could, in theory, work. With some extensions X is able to render into a XImage, we could use Shared Memory Pixmaps or we could work on getting the upcoming on-the-fly X depth changing into XFree86 4.3. Unfortunately none of these are complete enough to work for our needs. One of the big things that many of them lack is palette support (8bit graphics). So, presently XPixmaps must be in the depth format that the users current X is running at. But the application only knows one way to draw to the DIBSection: The format it requested. This means we have to do depth conversions when we do our coercions from one format to another. This can be slow, particularly if we are constantly doing the conversions. One of the worst cases is when the application requested 8 bit paletted mode and X is running in 24bit mode. A copy from appmod to gdimod/insync involves indexing each color and placing it in the new XImage, then sending it over to X. A copy in the other direction involves a reverse palette lookup, for each pixel we have to cycle through the 256 possible colors and find the correct index for them. This gets quite harsh on X when doing a large image, for example take a 1024x768 screen at 24bits (padded to 32bits): That becomes a 3 megabyte copy every time, doing that often can really slow things down. DIRECT DRAW USAGE ----------------- One important use of DIBSections is DirectDraw. Although games may not explicitly use DIBSections themselves, ReWind does. In Rewind a DirectDraw surface is basically a DIBSection. This is because DirectDraw can be used much like a DIBSection: The application can draw directly to it, yet Win32 can still do GDI rendering to it. For this reason many Win32 DirectDraw applications suffer serious performance problems as a result of DIBSections. Several games you may wish to look at are StarCraft (not too bad because it uses a 640x480 surface) and Age of Empires 2 (badly effected, as it uses a 1024x768 paleted surface). A BETTER SOLUTIONS: THE DIBENGINE --------------------------------- A better solution for this problem has constantly been discussed and is the DIB Engine. The purpose of the DIB Engine is to implement a fully functional GDI renderer capable of doing all the things X is presently used for, plus others which are currently unimplemented in any way. The DIB Engine would basically be able to take care of all GDI rendering when needed itself by rendering into the application memory (at the depth requested by the application). This would save on the copying backwards and forwards most of the time. (Although we would still have the copy to X when blitting to the primary surface). A DIBEngine has to implement a lot of functionality and must include the raw functions to render things like lines, polygons, ellipses and so on to the image. Another functionality of a DIBEngine should be to understand the ROP modes given to the various blitting functions. ROP stands for Raster Operations and is a method by which an application can make customize a blit fairly extensively. In Win32 there are two types of ROP's: Binary ROP's and Tenerary ROP's. Tenerary ROP's allow for up to 256 different types of blitting and are described by a string in reverse polish notation. An example Tenerary ROP could be DPSoo which is described as "Destination OR'd with Brush (pattern) OR'd with Source" and then blitted into the source. That is a fairly simple ROP3 code. Currently there is no suitable external library which could be exploited to make a DIBEngine in ReWind. One of the more promising libraries, Microwindows, has problems with different depths and ultimately has to be hooked into the underlying driver and hence does not solve the problem of removing the coercions. TRANSGAMING'S DIBENGINE ----------------------- TransGaming Technologies has been developing a DIBEngine in order to finally solve all the problems discussed above. The DIBEngine developed by TransGaming is partially complete, but more work is still needed for it to be fully functional. Current features include: o Drawing of lines o Partial drawing of ellipses o Drawing of polygons (several of the implementations, such as Polygon, Polyline, etc) o Filling of polygons (including patterns) o Pattern blitting o ROP2 and ROP3 engines Most of the support is there to complete the DIBEngine, for example the incomplete primitives can make use of the pattern blitting and so on. There is still a some functionality that has to be completed, and the current TODO list is as follows: o Implement outlined and filled shapes. o Implement curved shapes (Ellipse, Chord, Pie, Arc, etc). o Complete other drawing functionality (Round Rect, SetPixal etc). o Implement the different pens (Varying thickness, dotted, geometric, etc). o Line drawing needs to implement draw_last_point flag. o Brushes can only be 8x8 in Windows 95, we need to care about this. o Implement of clipping regions (Win32 has many types of clipping including rectangles, elliptic and more). o Implement text/fonts. o Take care of SetBrushOrgEx Currently the DIBEngine only supports a 16bit X Server and 16 bit drawing this means we need to: o Implement drawing for all possible depths (modify underlying pixel draw functions only). o Support Paletted modes. o Currently X11DRV_CreateBitmap only supports the current X depth. If a DIBSection is created at 32bits, and thus we try to use a 32bit brush, the whole thing will break. We either need to do depth conversions before calling X11DRV_CreateBitmap or do something else. Some things which need fixing up include: o Find depth masks for HBITMAPs o Properly implement BitBlt/PatBlt's and StertchBlt's. BitBlt takes the destination's DC functions, but this may not be safe if the source is not a DIBSection (see the information below on hooking into ReWind). o Optimzation. Currently the DIBEngine is not as fast as X for most drawing functions. Speedups can be done in the area of the ROP parser, pixel drawing, line drawing and filling. The code contains some comments of specific areas that need work. o DLL Seperation: Ideally the DIBEngine should be placed into its own DLL. This will allow it to be used for different graphics drivers, amongst other things. HOOKING INTO REWIND ------------------- For each GDI function that exists there is a driver-specific wrapper function that does some simply checking / optimizing / calculations before sending it onto the drivers specific rendering functions. For the X11DRV these exist in graphics/x11drv/graphics.c. This is where we divert calls to the DIBEngine when necessary. For speed optimizations (minimizing the number of coercions that take place) we put several conditions on which renderer to use. If the DIBSection is in gdimod (eg, Pixmap is most up-to-date) we use the drivers (eg, x11's) renderer; if the DIBSection is in appmod we use the DIBEngine. It should be noted that by doing this, the term 'gdimod' is now redundant because infact a DIBSection could be in appmod yet have been last modified by a GDI function.

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