wine-devel

wine-devel@winehq.org

84463 discussions

Re: [patch] Listview fixes
by Dimitrie O. Paun 24 Sep '02

24 Sep '02

On September 24, 2002 05:43 pm, Paul Rupe wrote: > - Initialize memory to prevent crashes when -debugmsg +listview is on > + ZeroMemory(&lvItem, sizeof(lvItem)); Guys, *Please* stop adding these ZeroMemory calls! They just hide bugs, it is almost always the wrong fix (for the listview at least). Alexandre, you can apply the patch, I'll go through the ZeroMemory one more time anyway... -- Dimi.

1 0

ToDo's
by Thomas Wickline 24 Sep '02

24 Sep '02

Hello, Here is the status of what I have so far on the ToDo's. I am not sure what section to put alot of this in so I just made Tools , Instructions & Aspect or Component for now. As much feedback as possiable is welcomed . Tom ----------------------- Wine ToDo's as of 9/24/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: "provider" interface * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec Multimedia wave audio * Open Sound System: Support for full-duplex. Fix bugs. * Drivers for other APIs (ALSA, Esound, others). 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). 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 * VxD support * PAM (Pluggable Authentication Modules) * SEH support * Visual C++'s native COM support * Complete the SMB code (Server Message Block) * Implement WinNT file handling * Add DWARF2 support * Implement a DIB engine * Speed up PDB support * Network UNC path handling * Libfontconfig support * Create replacement of browser component (Internet Explorer/I 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

2 1

RFC: Winsock todo's
by Martin Wilck 24 Sep '02

24 Sep '02

This is a RFC for comments. I may currently be the "offical" winsock maintainer in wine, but I wrote only a very small part of the code. I invite everybody, especially the authors of the other parts of winsock, to comment on these opinions. On Son, 2002-09-22, 18.48 Thomas Wickline wrote: > Can you give me a update on winsock todo's ? > And any other todo that you are aware of .. I have received very few bug reports lately, so I guess the basic Winsock functionality is working. A few important patches went in after the latest CVS snapshot, though. In general, the Winsock implementation in wine has a few parts that look really hackish and would need substantial cleanup. IMO this applies to the async.c file in total, but maybe I am doing injustice to authors of that file. I just find the code is really hard to read. Things like the User-space callbacks in WSAAccept() are impossible to implement correctly because the Unix accept() system call doesn't support callbacks. I do not like the fact that some Winsock1 calls, in particular select(), use direct system calls instead of using related wine APIs, e.g. WaitforMultipleEvents(). Actually if you have sockets with overlapped IO this may cause havoc. Changing this seems to be an average-difficulty task, suitable for contributors with some insight into wine internals. I'd like to see this fixed before 1.0. There are quite a few stubs left in ws2_32.spec. Some of these can probably be implemented easily and would be good work for beginners or casual wine contributors looking for a simple task, e.g. WSADuplicateSocketW(), WSAAddressToString[AW], WSAHtonl(). More unit tests need to be written, also a nice task for people interested in Winsock. Wine has no concept of the Winsock2 "provider" interface. All calls to these functions are either stubs or dummy functions, such as WSAEnumProtocols(). I had a patch for this, but never got it ready for prime-time. It is unrealistic to support a "real" provider interface, allowing (like Windows) to hook new protocol handlers in the network stack, but at least we should pass some realistic information to clients. Should be done for 1.0. There is no such thing as a QOS or socket group concept in wine either, but these seem to be rarely-used features -> post-1.0, if needed at all. 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. Alexandre is against using threads. 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. (I still havent't figured out whether aio will support sockets, though). A non-winsock todo that comes to my mind is support for NT security concepts such as tokens. But that would be a big one and should probably also be postponed after 1.0 Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

Re: Edit updates
by Dimitrie O. Paun 24 Sep '02

24 Sep '02

On September 24, 2002 02:09 am, Dimitrie O. Paun wrote: > This patch is trying to bring the edit.c in line > with the other controls. There is a problem with this patch, please don't apply. -- Dimi.

1 0

Using winbind with Wine
by Martin Wilck 24 Sep '02

24 Sep '02

Hello, There has been a discussion on wine-devel about using winbind for purposes like user authorization, retrieving user and group information, and more. It seemed reasonable to use PAM and NSS for the basic lookups and leave it to the sysadmin to configure these services to use winbind. Winbind offers some more functionality than that, though, such as SID lookups. Continuing along that line, it would be desirable to have a more generic interface than what winbindd currently offers - actually it would be nice to be able to access all RPC calls that samba supports through an interface like winbindd's. * Are there any plans by the Samba team to extend winbindd in this direction? * If no, would the Samba team accept patches from wine developers implementing such extensions to winbindd? * Does winbind support client requests (from the Unix side) where strings are in Unicode format, i.e. could wine pass Unicode strings from Windows applications to windbind directly? * If no, would it be possible to extend winbindd to support this without modifying the samba libraries? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

winebootup
by Raul Dias 24 Sep '02

24 Sep '02

Hi, What happened to winebootup? >From documentation/packaging.sgml: <varlistentry><term><filename>winebootup</filename></term> <listitem> <para> Winelib app to be found in programs/. It'll be called by the winelauncher wine wrapper startup script for every first-time wine invocation. Its purpose is to process all Windows startup autorun mechanisms, such as wininit.ini, win.ini Load=/Run=, registry keys: RenameFiles/Run/RunOnce*/RunServices*, Startup folders. </para> </listitem> </varlistentry> and it not under wine's tree. Does it exist? (or ever did?) Is there something similar to handle RunOnce keys? I just want to avoid doing a duplicated work. []'s Raul Dias

2 1

Re: Correct and update executable types in PathIsExe
by Jeff Smith 24 Sep '02

24 Sep '02

I was just going by what MSDN says. Screensavers (SCR) are just like regular executables with a standard (I believe) command-line arguement interface. I really know next to nothing about SCF files. BTW, my version of Windows (95-OSR-2.1) is so old, it doesn't even have .cmd -- Jeff Smith >From: Alexandre Julliard <julliard(a)winehq.com> >To: "Jeff Smith" <whydoubt(a)hotmail.com> >CC: wine-devel(a)winehq.com >Subject: Re: Correct and update executable types in PathIsExe >Date: 23 Sep 2002 11:13:43 -0700 > >.pif is clearly right, but are you sure about .scr and .scf? My >version of Windows doesn't do that. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

1 0

Re: winapi update
by Alexandre Julliard 24 Sep '02

24 Sep '02

Patrik Stridvall <ps(a)leissner.se> writes: > Fixed some issues found by winapi_check. I'd prefer that we didn't add standard headers on the dll separation hacks. We don't want to give the impression that these functions are legitimate exports. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: export {Start,End}GraphicsExposures from x11drv
by Alexandre Julliard 23 Sep '02

23 Sep '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Fundamentally, the main purpose of a USER driver is to deal > with windowing, and as such, it needs to be able to compute > invalidated areas. It thus makes sense to for it to export > functions that let you query this information. > > The start/end interface used by x11drv makes sense, and it > looks sane enough to be exported. I disagree. Graphics exposures are a very X11 specific concept, they don't belong in the generic driver interface. This kind of change leads to the approach that we used before: do everything in USER and add a few strategically placed calls to x11drv where we really need it. That's the wrong approach, because it cannot be adapted to other drivers except by adding more and more driver calls all over USER. The new approach is to put the driver in charge as much as possible; this means a lot more work is done inside the driver functions, which in turn gives a lot more flexibility. Of course reconciling that with dll separation is not always trivial, but that's part of the fun... -- Alexandre Julliard julliard(a)winehq.com

2 9

Re: Correct and update executable types in PathIsExe
by Alexandre Julliard 23 Sep '02

23 Sep '02

"Jeff Smith" <whydoubt(a)hotmail.com> writes: > Looking at PathIsExe, I thought PID was probably supposed to be PIF > (Program Information File). I checked MSDN, and found this was the > case. I also found two more types that need to be recognized: SCR > (SCReensaver) and SCF (Shell Command File?). .pif is clearly right, but are you sure about .scr and .scf? My version of Windows doesn't do that. -- Alexandre Julliard julliard(a)winehq.com

2 2

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