January 2004 - Wine-Devel - list.winehq.org

Re: DMUSIC: my latest work

by Rok Mandeljc

> It breaks parallel makes and dll separation. Dlls should not depend on > one other this way. The best way is to duplicate the few things you > need in each dll. OK, guess you're right... but just as a thought, would it make any difference if I made symlinks from dmusic/dmusic_common.c to others and then list them as "local" sources (can diff & cvs hadle symlinks)? Or just copying dmusic_common.c to all dm* folders and then include them locally? (as for dmusic_common.h, there won't be much need for this one then and I could put its contents in dm*_private.h). -- "Destruction is the work of an afternoon. Creation is the work of a lifetime." -- Kamahl, druid acolyte

Jan. 4, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > Again, why? The named pipe server has to support > multiple accesses, so multiple processes can create > unique connections to the same pipe, and let the > server worry about concurrency. Even if that weren't > the case, using a synchronization object and shared > data in the wineserver would be able to control > access. In the multithreaded case, you only need to > implement concurrent control in the dll that > implements named pipes (most appropriately ntdll). I > had to synchronize NetBIOS receives across threads in > netapi32.dll, and this doesn't seem any harder. You have to do inter-process synchronization, pipe handles can be shared between processes. I don't see how you can do that without putting everything into the wine server, which is the same as putting it into the kernel except with a large performance hit (and not only for named pipes, but for all file I/O, since it will prevent many optimizations). But feel free to prove me wrong; I haven't studied the protocol in detail so maybe I'm missing something. -- Alexandre Julliard julliard(a)winehq.com

Jan. 4, 2004

[Bug 1903] using dead_diaeresis i.e. e + ¨ hangs wine

by grant williamson

Hi, not sure if anyone else has experienced this. since patch http://cvs.winehq.com/patch.py?id=10332 was added to cvs (20031205), if I type a dead_diaeresis - "¨" followed by a letter, which would normally produce a "ë" or a "ü" it simply makes wine hang. removing this patch(I removed it on latest cvs) and the problem goes away, can someone find out why this causes an issue? -- grant williamson <traxtopel(a)fastmail.fm>

Jan. 4, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > In the remote case, what we need is for the kernel > to manage the whole > protocol, so that we can do read() and write() calls > as if it were a > normal socket. You cannot manage the protocol in the > client process, > it breaks down as soon as two threads (or worse, > processes) share the > same pipe. Again, why? The named pipe server has to support multiple accesses, so multiple processes can create unique connections to the same pipe, and let the server worry about concurrency. Even if that weren't the case, using a synchronization object and shared data in the wineserver would be able to control access. In the multithreaded case, you only need to implement concurrent control in the dll that implements named pipes (most appropriately ntdll). I had to synchronize NetBIOS receives across threads in netapi32.dll, and this doesn't seem any harder. --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 4, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > I'm still not getting it. Those two SMBs are SMBtrans > SMBs, a single request and (typically) a single > response. My NetShareEnum and NetServerEnum functions > also use SMBtrans. What's hard? What does the kernel > do for us that makes it easier? Setting the message type was an example of things that require kernel support in the local case. Obviously you cannot send SMB requests on a socketpair. In the remote case, what we need is for the kernel to manage the whole protocol, so that we can do read() and write() calls as if it were a normal socket. You cannot manage the protocol in the client process, it breaks down as soon as two threads (or worse, processes) share the same pipe. -- Alexandre Julliard julliard(a)winehq.com

Jan. 4, 2004

#pre5 - comdlg32 MS_VC + PSDK porting

by Steven Edwards

Hello, I am calling this patch pre5 rather than #5 because it doesnt fully address the rest of the PSDK porting issues and one of my new years resolutions for 2004 is for every patch I send to winehq to be good enough to go right in to CVS. ;) With this patch we can build 90% of comdlg32 on MS_VC with the PSDK except for one major bug and one minor question. 1. Can we please fix winnt.h line 175? This #define NONAMELESSSTRUCT thing is wrong. It breaks building on the PSDK and w32api. I have not be able to find any thing about it in Microsofts documentation or headers. If we removed support for it its going to break GCC 2.8.xx but if someone is on 2.8 its time to upgrade. /me is quoting here from the Microsoft headers under Fair use and all of that...... "// // For compilers that don't support nameless unions // #ifndef DUMMYUNIONNAME #ifdef NONAMELESSUNION #define DUMMYUNIONNAME u #define DUMMYUNIONNAME2 u2 #define DUMMYUNIONNAME3 u3 #define DUMMYUNIONNAME4 u4 #define DUMMYUNIONNAME5 u5 #else #define DUMMYUNIONNAME #define DUMMYUNIONNAME2 #define DUMMYUNIONNAME3 #define DUMMYUNIONNAME4 #define DUMMYUNIONNAME5 #endif #endif // DUMMYUNIONNAME " Thats it. All I can find is the DUMMYUNION stuff in some of the headers. If we just remove support for DUMMYSTRUCT in WINE its going to break a lot of stuff so we will prob'l need to perl script the cleanup. 2. Do you want me to dump printdlg.h now and compleate the cleanup or can it wait untill after the DUMMYSTRUCT thing is fixed? I can move the rest of the structures and internal function declairations to cdlg.h and cdlg16.h now but I want to wait till I can get printdlg.c to compile with out bitching about missing member s1 and u1 blah... Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 4, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > > The named pipe state can be queried via the > > QNmPHandState SMB and changed via the > SetNmPHandState > > SMB. See the X/Open IPC mechanisms for SMB, p114 > and > > p116 ( > > > Sure, if you already have SMB named pipes, then > implementing SMB names > pipes becomes rather easy. The problem is > implementing them on top of > socket pairs... I'm still not getting it. Those two SMBs are SMBtrans SMBs, a single request and (typically) a single response. My NetShareEnum and NetServerEnum functions also use SMBtrans. What's hard? What does the kernel do for us that makes it easier? --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 4, 2004

Re: PATCH: Fix DLL constructors on OpenBSD

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Will this patch also remove the need for the wrapper for C++ programs? Hopefully yes, that's the whole point of the patch. -- Alexandre Julliard julliard(a)winehq.com

Jan. 4, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > The named pipe state can be queried via the > QNmPHandState SMB and changed via the SetNmPHandState > SMB. See the X/Open IPC mechanisms for SMB, p114 and > p116 ( > http://www.opengroup.org/products/publications/catalog/c195.htm > ) Sure, if you already have SMB named pipes, then implementing SMB names pipes becomes rather easy. The problem is implementing them on top of socket pairs... -- Alexandre Julliard julliard(a)winehq.com

Jan. 4, 2004

Re: Warning: .stabs: description field ...

by Eric Pouech

Uwe Bonnes a écrit : > Hallo, > > since some days, make in wine/programs/winetest produces: > gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o winetest.exe.spec.o winetest.exe.spec.c > /tmp/ccOKsOhH.s: Assembler messages: > /tmp/ccOKsOhH.s:852680: Warning: .stabs: description field '1a1be' too big, try a different debug format > /tmp/ccOKsOhH.s:852683: Warning: .stabs: description field '1a1c7' too big, try a different debug format > /tmp/ccOKsOhH.s:852686: Warning: .stabn: description field '1a1c7' too big, try a different debug format > > This is on a Suse 9.0 system. Is this a problem with my setup or do others > observe it too? it in winetest. we embed USERDATA (for test programs) which are larger than what stabs can handle, hence the warning. It's harmless. A+

Jan. 4, 2004

Re: winecfg to configure directsound options?

by Dimitrie O. Paun

On January 4, 2004 12:09 pm, Eric Pouech wrote: > So I'd go for a specific tab which could grow in the future Remember, the idea is to keep winecfg as simple as possible, not to add to it all possible options. In other words, unless an option is very commonly changed, it shouldn't go into winecfg. Rather, it should be changed through regedit. -- Dimi.

Jan. 4, 2004

Re: Warning: .stabs: description field ...

by Marcus Meissner

On Sun, Jan 04, 2004 at 06:08:40PM +0100, Uwe Bonnes wrote: > Hallo, > > since some days, make in wine/programs/winetest produces: > gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o winetest.exe.spec.o winetest.exe.spec.c > /tmp/ccOKsOhH.s: Assembler messages: > /tmp/ccOKsOhH.s:852680: Warning: .stabs: description field '1a1be' too big, try a different debug format > /tmp/ccOKsOhH.s:852683: Warning: .stabs: description field '1a1c7' too big, try a different debug format > /tmp/ccOKsOhH.s:852686: Warning: .stabn: description field '1a1c7' too big, try a different debug format > > This is on a Suse 9.0 system. Is this a problem with my setup or do others > observe it too? I observe it too. I think winetest is just getting too large for a .stabs debuggable file. The error appears harmless though. Ciao, Marcus

Jan. 4, 2004

Re: winecfg to configure directsound options?

by Eric Pouech

Chris Morgan a écrit : > I was planning to add the audio driver as a configuration option in winecfg > but had a few questions. > > Does anyone use the directsound options? If so it probably makes sense to > have an "Audio" tab in winecfg with the audio driver and the dsound options. > If not then it might make sense to put the audio driver alone on another > page, maybe the general config page? > > Should we have a multimedia page? What other multimedia options would go > there? at minima, we would need to define: - which sound drivers are enabled (winmm drivers) - which is the default sound card (if several are present) then we could add: - the dsound options (but they are rarely used) - midi mapper options (see dlls/winmm/midimap/midimap.c) but this is absolutely not needed for now... So I'd go for a specific tab which could grow in the future A+

Jan. 4, 2004

Warning: .stabs: description field ...

by Uwe Bonnes

Hallo, since some days, make in wine/programs/winetest produces: gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o winetest.exe.spec.o winetest.exe.spec.c /tmp/ccOKsOhH.s: Assembler messages: /tmp/ccOKsOhH.s:852680: Warning: .stabs: description field '1a1be' too big, try a different debug format /tmp/ccOKsOhH.s:852683: Warning: .stabs: description field '1a1c7' too big, try a different debug format /tmp/ccOKsOhH.s:852686: Warning: .stabn: description field '1a1c7' too big, try a different debug format This is on a Suse 9.0 system. Is this a problem with my setup or do others observe it too? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 4, 2004

Re: PATCH: Fix DLL constructors on OpenBSD

by Dimitrie O. Paun

On January 3, 2004 06:39 pm, Alexandre Julliard wrote: > Anyway, that constructor stuff is going to change, because we > need to intercept constructors and run them from the dll entry > point. I'm working on a patch to do that, which will hopefully > solve your problem at the same time. Will this patch also remove the need for the wrapper for C++ programs? -- Dimi.

Jan. 4, 2004

Re: PATCH: Fix DLL constructors on OpenBSD

by Boaz Harrosh

Dear Alexandre Please explain in a few words what you're going to do. Is this going to effect C++ Global data constructors as well. I'm Just working, well more like fumbling, on a problem in STLPort with global initialization of cout cin cerror (stdout stdin stderror). Is it possible that, while in a global C++ constructor, I am meeting an uninitialized DLL Jump table (I'm not sure what is the official name for it). Is the jump table initialized after the glib c "global_ctors_aux" chain? Alexandre Julliard wrote: >wiml(a)underhill.hhhh.org (Wim Lewis) writes: > > > >>What is it that _init() does on Linux, that the DLL init code needs >>to run first? I'd be interested in trying to write an autoconf test >>or something, if possible. >> >> > >I believe there was a problem with constructors being called in >reverse link order. Also any object file of the dll can potentially >have a .init section which would then break badly. Anyway, that >constructor stuff is going to change, because we need to intercept >constructors and run them from the dll entry point. I'm working on a >patch to do that, which will hopefully solve your problem at the same >time. > > >

Jan. 4, 2004

Re: Status ToDo's #2

by Christian Costa

Tom wrote: > > Comments, Suggestions? > > Tom > > ------------------------------------------------------------------------ > > > Wine Status - Known To Do's > > > Window management > > * Rewrite Wine's window management code to be able to change the > visual of an X window once the window has been created. > * In Desktop Mode all processes started from one wine invocation > should be confined to one desktop window. > * Window management needs proper inter-process handling of > activation, focus, repaint. > * Workaround for the "no keyboard without Desktop mode" problem. > > > National Language Support > > * We currently lack a way to model hierarchical resources like > those required by calendar information (each locale has a > variable number of calendars, with different attributes). This > is a show stopper for completing the NLS Api > (Get/EnumCalendarInfo etc). > * Our text output needs to substitute fonts on the fly when > characters to be printed cannot be represented in the current font. > * Make sure ASCII functions call the Unicode one and not the other > way around.(probably will stay forever.) > * Add localization to more languages.(probably will stay forever.) > * Add localization to more parts of Wine.(probably will stay forever.) > * Better support of Chinese, Korean, Japanese...(currently in works) > * Better support of BiDi - Arabic, Hebrew... > > > X11drv > > * Add support for keyboard layout APIs. > * Better integration with window managers > > > NTDLL > > * Implement security APIs and make them use native OS security > facilities. > > > Kernel32 > > * Split 16/32 function, finish moving stuff into ntdll (review FS > & device support) > * Implement non-local named pipes and mailslots over SMB > * Implement SMB over Netbios > > > Comdlg32 > > * Add a Network Neighborhood-style browser to the file dialog > > > Netapi32 > > * Implement the Net* functions using rpcrt4 > * Implement NetServerEnum and NetShareEnum using SMB > * Netbios support for IPX > > > Wininet > > * Needs thread safety and unicodization > > > Winsock > > * SIO_GET_INTERFACE_LIST support for IPX > * IPv6 support > * More unit tests, e.g. for asynchronous IO. > * Make sure OOB data is handled properly. > * WS2: Implement service programming interface (SPI), use for > supporting other services. > * Try to provide more services such as IrDA natively. > * Fix stubs left in ws2_32.spec > > > Cabinet > > * Compression API's remain unimplemented > > > RPCRT4 > > * Implement the undocumented "NT Ports" API (aka "LPC") used by native NT > * Fill out the matrix of per-type /Oi marshalling API's. > * Some real RPC tests,although there are some tests of some peripheral rpcrt4 API's -- no actual RPC's are tested. > * Implement /Oicf "stubless" marshalling > * Implement full stub/proxy support for widl > * Get Wine's DCOM to use wine's RPC as appropriate. > * Fix the wire protocol > - Implement the OXID resolver and other ORPC peccadilloes > > > > DirectX > >[DirectShow] > > * Filter manager (IGraphBuilder) > * Video renderer > * Audio renderer > * Registry entries > >[DirectDraw] > > * YUV overlays > * Support for FOURCC surface > >[D3D] > > * Begin to share most of the openGL code between d3d8 and d3d9, begining with shaders, textures and state blocks > * Abstract APIs to be usable by ddraw > * Implement a better drawing pipeline thinking about hardware and software shaders > * Compressed texture support > * Improve Z Buffer support > * Multi texturing (and more generally, OpenGL extension handling) > * Off screen rendering > * Proper color keying > * Finish migration of D3D1-7 code to use d3dcore > * Add hardware vertex shader and pixel shader support > * LOD support > * Multisampling (antialising) support > * Palette texturing fixes (not really tested) > * Swapchain support > * Better device management (mainly caps) > * index/vertex buffer hardware support > * Surface->DC handling > * Real Preloading support (using a memory manager) > * UpdateTexture/UpdateSurface > * various optimisations > >[DirectSound] > > * Hardware accelerated direct sound capture driver support using the Windows CE2 HAL API > * 3D buffer support in software is present but incomplete. > * 3D buffer hardware support > * Sound effects on buffers > * Capture effects > * Full duplex support is stubbed out but not functional. > * DX9 support for new PCM formats (24/32 bit and float samples) and for more than 2 channels is not present. > >[DirectMusic] > > * DMusicPerformance scanning of files > >[DirectInput] > > * Improve DX8 support (especially joystick) > >[DirectPlay] > > * Add support for DX8 > >[MSDMO] > > * Fix stubs left in msdmo.spec > >[DevEnum] > > * Support the creation of special filters (Midi renderer, DSound renderer, WaveOut, WaveIn) > and support the binding to these filters. > > > > Multimedia > >sound drivers: > * Improve the jack audio server, e.g. WaveIn & Resampling. > * Implement the audio compression codecs. > * Fix Sound Blaster emulation. > >all audio architecture: > * No longer use the hack in Wine sound drivers to map the DSound driver interface to an existing WinMM driver. > (impacts dsound.dll and winmm + all low level audio drivers)(will likely require a real installation scheme for MM drivers) > >ALSA multimedia driver: > * Mixer Support > * MiDi inn Support > * Check for 1.0 correctness > >MCI (Media Control Interface) drivers > * Missing the mcianim drivers. > >mciavi: > * Handling of palettes > * Recording > * Lots of messages still need to be handled > * Synchronization > * Replace AVI file parser by using API from avifil32 > * Support more and less than one audio stream > * Stopping while playing should stop audio playback ASAP > * Opening must be possible without filename (use load later to) > >avifil32: (sorted by decreasing priority) > * Make the whole library thread save > * Interface for AVI files: > - native version has problems with reading our files > (Is it still so?) > * API for clipboard: > - only stubs. (native version doesn't work). > * AVIFileProxy is missing. > * We have no implementation for IAVIStreaming, which doesn't > result in missing functionality, but in possible performance > loss. Even the native version has such an interface only for > the AVI file handler. > >msvfw32: > * DrawDib needs some work: > - Some flags are ignored > - handle palette > * semi-stub implementation for file dialogs with AVI preview. > Need to use OFN_ENABLEHOOK flag. > * Stub implementation for codec-selection-dialog > * Resources are missing (also see the 2 above points) > * StretchDib method is missing > * Many 16-bit methods are missing > * MCIWnd: > - Bug: shouldn't open device with filename if none given. > - Bug: Windows stays empty when opening of device fails. > >avicap32: "Video Capture" > * Only stub DLL > >Opengl32: > * Support all WGL extensions which have GLX counterparts (like PBuffers or render to texture for example). > > > > FreeBSD > > * Add support for MZ_SUPPORTED > > > DOS > > * VM86 emulation still has races in irq handling. > * DPMI supports now irqs but still not interrupt reflection. > * Obsolete Win32s VxDs need to be deleted. > * VxD handling should be rewritten so that it no longer uses a > separate 16-bit DLL. > * If Win16 program uses real mode code, there are code paths where > Wine fails to properly initialize DOS memory. > * DOS memory management code needs restructuring. > * Ioport emulation code should be migrated to winedos. > * VESA emulation is missing many important functions. > * Bitplane VGA modes are totally unsupported. > * Many DOS7 extensions are missing. > * System timer code only supports simple cases. > * DOS4GW does not work. > * NTDLL still has lots of DOS emulation code. > > > GDI > > * DIB engine > > > GDB > > * Add the MSC/PDB info support to gdb > > > Winedbg > > * Make winedbg use dbghelp DLL > * Speed up PDB support > - Implement support for latest MSC formats > > > > DDE > > * Enhance memory management issues (interprocess sending) > > > OLE > > * Handle apartments properly in CoCreateInstance, etc. > * Type library handling (parsing them is not yet complete and > saving them is not implemented at all) > * Implement ICreateTypeLib support > * Implement Var* (e.g. VarMod) and variant conversion routines > * User defined types (e.g. IRecordInfo) > * Custom marshalling functions for various data types > * Implement missing features in OLE*. > > > Native Programs > > * Winhelp: fix invocation thru WinHelp > - lots of macros are still missing > > > > 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,....) > * Subpixel rendering - a.k.a. ClearType > * Reduce per font startup time > > > Printers > > * Write a printer configuration applet > > > Tools > > * Wine installation process should install and configure wine > * Perform Windows' reboot operations automatically when required > * Winemaker fixes > * Run C regression tests on Windows with MSVC > * Work on WRC as it does not find system headers > * wineconsole: add configuration bar + resizing capabilities > > > Instructions > > * Documentation updates > > > Aspect or Component > > * Review of Wine Server Protocol > * Finalize Server Protocol > * Visual C++'s native COM support > * Create replacement of browser component (Internet Explorer/IExplore) > > > Porting issues for Mingw/Cygwin/MS_VC > > * Better separation of win16/32 code > * Remove/rewrite win16/9x API dependency 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 > > > For the full 0.9 Bug List, please see Tasklets > <http://bugs.winehq.com/buglist.cgi?keywords=tasklet>For the full 1.0 > Bug List, please see Tasklist > <http://bugs.winehq.com/buglist.cgi?keywords=tasklist> > > > I think it's worth noting to improve audio latency (in audio architecture section?) even if it is more related to the wineserver and the kernel. Actually it's not possible to do serious audio stuff (at least on my box). Bye, Christian PS: s/MiDi inn/Midi IN/

Jan. 4, 2004

Re: Status ToDo's #2

by Christian Costa

Sylvain Petreolle wrote: > --- Tom <twickline(a)skybest.com> a écrit : > > > >>Comments, Suggestions? >> >>Tom >> >> Hi, >> >> >ALSA multimedia driver: > * Mixer Support > * MiDi inn Support > * Check for 1.0 correctness > >winealsa now has mixer support since Dec 11 2003 (thanks to Christian) > > No it's wrong. I added WaveIn support. :-) Bye, Christian

Jan. 4, 2004

AutoCad 2000 latest status ?

by John

I know there are interests in autocad 2000 status with wine. I was happy to read in http://appdb.winehq.org/appview.php?appId=86&versionId=102 that autocad 2000 actually starts up now, although there seams to be a file open problem. I just wanted to forward this news in case someone is interested in fixing the details now that it at least starts up. ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html

Jan. 4, 2004

Re: Congradulations - windef.h

by Boaz Harrosh

Maybe you are right! I have a small machine (PIII 512Mg). Also large swap space might help. But it take ages. 3.0 it is instantly. Ivan Leo Murray-Smith wrote: >>You cannot use KDevelop 2.1 release with wine. Too many files to deep. >>It will crash trying to import that project. (After 10 minuets of a >>progress bar) >> >> >Sucessfully imported, configured, currently building in KDevelop 2.1 shipped >with Mandrake Linux 9.2 > >Ivan. > > > > > > >

Jan. 4, 2004

Re: Congradulations - windef.h

by Boaz Harrosh

Yes it does! exactly the same. Sorry! I checked, and double checked, by diffing against Last CVS. But I didn't realize winegcc went such a long way. In any way I wish it would be an header. dllimport/dllexport gives me a warning even with -fms-extensions. In an header I could turn that off. Also later today I will submit "uuidof" and "declspec ( property () )". These must go in an header, but they can be on the side and manually included by those who needs them. Should I submit them to MinGW they might have use for them too. Dimitrie O. Paun wrote: >On January 1, 2004 07:42 am, Boaz Harrosh wrote: > > >>In short __declspec( selectany ) && __declspec( thread ) >> >> > >These are supported just fine by winegcc, what's wrong >with it? AFACT, it's supported exactly the same way as >in your patch... > > >

Jan. 4, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Dan Kegel <dank(a)gmane.kegel.com> wrote: > My goodness. I didn't know that document existed. > Thanks for > the link! Is there a complete list anywhere of > Win32 APIs > that have been documented by opengroup.org? My pleasure. Don't know of one, but check out the references section of Chris Hertel's (beyond sufficient praise) Implementing CIFS book, http://ubiqx.org/cifs/References.html That's where I found the link. --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 4, 2004

Re: commctrl.c

by Dmitry Timoshkov

"Ge van Geldorp" <ge(a)gse.nl> wrote: > Changelog: > Don't destroy heap during unload, as other DLLs which haven't unloaded > yet may still depend on it (DPA* callers) The patch is wrong. A more correct way to fix this is to simply use process heap in DPA (and MRU) APIs. Perhaps even go further and completely remove any use of the private comctl32 heap. -- Dmitry.

Jan. 4, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > Juan Lang <juan_lang(a)yahoo.com> writes: > > > Why? What problems will we run into if we don't? > It > > may be clear to you, but it isn't to me. > > Mike can probably give you more details, but there > are some features > that cannot be supported on standard socket pairs, > for instance > switching between byte and message modes on the fly, > or some of the > blocking conditions. The named pipe state can be queried via the QNmPHandState SMB and changed via the SetNmPHandState SMB. See the X/Open IPC mechanisms for SMB, p114 and p116 ( http://www.opengroup.org/products/publications/catalog/c195.htm ) --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 3, 2004

winecfg to configure directsound options?

by Chris Morgan

I was planning to add the audio driver as a configuration option in winecfg but had a few questions. Does anyone use the directsound options? If so it probably makes sense to have an "Audio" tab in winecfg with the audio driver and the dsound options. If not then it might make sense to put the audio driver alone on another page, maybe the general config page? Should we have a multimedia page? What other multimedia options would go there? Thanks, Chris

Jan. 3, 2004