September 2002 - Wine-Devel

Call for feeback

by Thomas Wickline

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

Sept. 29, 2002

Unable to compile current CVS

by Ann and Jason Edmeades

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

Sept. 29, 2002

ToDo's

by Thomas Wickline

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

Sept. 29, 2002

Re: wineoss patch

by Eric Pouech

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+

Sept. 29, 2002

Re: Implement {G|S}etWindowLongPtr

by Eric Pouech

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+

Sept. 29, 2002

Re: Accept -g3 stabs info (sketchy?)

by Eric Pouech

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

Sept. 29, 2002

Fix: Anti-aliasing for font sizes >8

by Dag Wieers

Hi, I noticed recently that Wine was able to do anti-aliasing for font sizes >16 although my Gnome 2 looked nice with anti-aliasing of <16. I started to look why Wine apps were only anti-aliased for >16, and I came across this: --- dlls/x11drv/xrender.c.orig 2002-09-29 12:56:27.000000000 +0200 +++ dlls/x11drv/xrender.c 2002-09-29 12:56:56.000000000 +0200 @@ -322,7 +322,7 @@ assert(entry->nrealized == 0); - if(antialias && abs(plfsz->lf.lfHeight * plfsz->xform.eM22) > 16) { + if(antialias && abs(plfsz->lf.lfHeight * plfsz->xform.eM22) > 8) { pf.depth = 8; pf.direct.alphaMask = 0xff; } else { When I changed this, my Notes was much nicer to work with. I presume there is a reason why anti-aliasing was off, but I would reconsider that decision. You can look for yourself on these 2 screenshots: http://dag.wieers.com/Screenshot-2.png http://dag.wieers.com/Screenshot-3.png Especially look at the widgets. Thanks for your feedback, (please Cc: because I'm not subscribed) -- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ -- «Any errors in spelling, tact or fact are transmission errors»

Sept. 29, 2002

Re: patch to MZ_Exec() PE executables

by Sylvain Petreolle

I don't understand this. Do you mean a command line greater than 126 chars is executed only when CMDLINE is set? > And, finally, you are ignoring long command lines > from DOS program stored in CMDLINE environment > variable. (I have already exchanged private email with > Chris Morgan about this; DOS programs can be passed > command tails longer than 126 characters using CMDLINE > environment variable. Similarly, DOS programs may pass > long command lines to programs they execute.) > > -- > Jukka Heinonen <http://www.iki.fi/jhei/> > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Sept. 29, 2002

Re: patch to MZ_Exec() PE executables

by Jukka Heinonen

> Look reasonable? No. Command tail is not null terminated so you cannot use strlen. DOS exec function "load and exec" is synchronous so you should return to caller only after created process has finished. In addition to hFile lead found by Ove Kaaven, you are leaking handles in PROCESS_INFORMATION. Using fixed size buffer for full command line without sanity checks is a bad idea and will cause problems sooner or later. And, finally, you are ignoring long command lines from DOS program stored in CMDLINE environment variable. (I have already exchanged private email with Chris Morgan about this; DOS programs can be passed command tails longer than 126 characters using CMDLINE environment variable. Similarly, DOS programs may pass long command lines to programs they execute.) -- Jukka Heinonen <http://www.iki.fi/jhei/>

Sept. 29, 2002

Re: Wine ToDo's

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > >1. Add support for Hebrew and Arabic: worker Shachar Shemesh. > > > Actually, he had that one under "BiDi support". Yes, I know. I would suggest to move "BiDi support" as an item of a larger task "National Language Support". -- Dmitry.

Sept. 29, 2002