wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

Re: MIDL and COM
by Peter Samuelson 07 Dec '01

07 Dec '01

I know this thread is a couple weeks old, I saw it on Wine Weekly News... [A. Julliard] > > If we want to use .idl files we'll have to come up with our own > > compiler, and then we can put the .idl source in the tree and > > compile it at build time. [Ove Kaaven] > Hmm. Even when using flex and bison, it sounds like a fair amount of > work... wonder who would volunteer? The FreeDCE Project has a DCE IDL compiler which I understand is mostly compatible with MIDL.EXE. See http://sf.net/projects/freedce and http://www.dcerpc.net/ (the latter seems to be malfunctioning at the moment). Peter

2 4

Re: Read/WriteProcessMemory fix
by Alexandre Julliard 07 Dec '01

07 Dec '01

Andrew <andrew(a)transgaming.com> writes: > This fixes a bug in ReadProcessMemory and WriteProcessMemory, and > rearranges some of the code. (In particular, all the code that knows > that ptrace works in ints has been contained to server/ptrace.c.) What bug is it fixing? I'm not sure the reorganisation is a good idea; it seems less efficient, less portable, and AFAICS broken for accesses of less than an int size. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: SystemParametersInfo: DoubleClick actions
by Andriy Palamarchuk 07 Dec '01

07 Dec '01

The last week I submitted this patch, but it is not applied yet. Are there any problems with the patch? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

2 1

Re: Fix for MS debug info problems with winedbg
by Francois Gouget 06 Dec '01

06 Dec '01

On Thu, 6 Dec 2001, Dave Hawkes wrote: > Fix for some types of C++ debug info that can cause winedbg to crash. Seems like the patch is missing :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

2 1

Re:UNC patch
by Eric Pouech 06 Dec '01

06 Dec '01

I think we should need some kind of configuration for this (to provide a bit more flexibility to end users) this would means,for example, allow or not automatic UNC operations (for now only binding a UNC name to a mounted SMB share). As in Wine, we don't allow mounting, as a default, all the file hierarchy, it would be interesting to provide the same type of functionnalities (bazed on host names for example... but I fear this would be a bit too complex to do). But as a starter, the option to enable binding should be made available. A+ > Hello, > > as suggested awhile ago from Dan Kegel on cemw. > > > If Wine handled UNC paths as follows: > > Given a UNC path \\foo\bar, > > look at /etc/mtab for a matching smbfs mount. > > If one is found, look at .wine/config for a drive letter mapped to that mount. > > If one is found, convert the UNC path to be relative to that drive letter. > > ChangeLog > --------- > * files/file.c: > Stefan.Leichter(a)camLine.com > implemented UNC filenames using samba shares mounted according to > /etc/mtab --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

3 2

Re:UNC patch
by Eric Pouech 06 Dec '01

06 Dec '01

> Sorry, I have no idea what you are talking about. Maybe it is my bad > english or my little knowledge about windows. no, it's my French ;-) what I'm talking about binding is the operation of making the relationship between a UNC name and a (samba-) mounted SMB share. the equivalent operation for names (making the relationship between a DOS driver letter and a Unix directory) is driven by the Wine configuration. Even, if both schemes are a bit different, I thought we need the same configuration capabilities in Wine. These are several things we could do (first one is a must have IMO, the others are open to discussion) - enable / disable the UNC to mount point parsing - enable / disable the UNX to mount point parsing on a per host basis - fully configure the UNC to mount point (like we do for DOS drive letters) - ... A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

2 1

SHLWAPI pre-submit questions
by Jon Griffiths 06 Dec '01

06 Dec '01

Hi, I've been hacking on SHLWAPI.dll for a couple of months now while holidaying around Thailand, using a beaten up laptop. Since I just obtained free use of a real machine with a good net connection, I want to start submitting my work but I thought I'd clear up a few style issues beforehand: 1. Is it OK to give meaningful names to undocumented functions? e.g. SHLWAPI_1/2 => UrlGetInfoA/W SHLWAPI_5/6 => PathFindOnPathExA/W I want to do this where the names are no-brainers, as in the case above, and the functions are referenced by the dll internally. 2. Is it OK to sync shlwapi.h with the windows version ? e.g. Remove undocumented entries Remove its dependence on obj_base.h (windows has none) Add the function exclusion defines as per windows I assume this is fine, but doing this causes the next question - 3. How to deal with shared undocumented functions? e.g. StrRetToBufA/W is used by shell32, but should not defined in shlwapi.h. Here there are 4 Choices: 1. Define twice (Ugly) 2. Put into a new wine/undocshlwapi.h (Seems that these are depreciated?) 3. Define anyway (Im not a fan of having undoc functions in public headers) 4. Have shell32 functions #include "../shlwapi/internal.h" (A little unclean) I'd like to go for 4, any objections? I'll start feeding in the new function implementations over the next little while, once the structure is sorted. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________________________ Do You Yahoo!? Buy the perfect holiday gifts at Yahoo! Shopping. http://shopping.yahoo.com

5 7

Happy Christmas wine
by Russell Howe 05 Dec '01

05 Dec '01

I got sent a Christmas card in Windows EXE format. Since it works perfectly with wine I thought I'd share it :) The file is at http://www2.cs.man.ac.uk/~hower0/crimbo.exe.gz -- Russell Howe rhowe(a)mindless.com

1 0

dlls/winedos/module.c:632: `write_pipe' undeclared
by Gerald Pfeifer 05 Dec '01

05 Dec '01

revision 1.10 date: 2001/12/04 19:54:45; author: julliard; state: Exp; lines: +41 -60 Moved most of the real-mode stuff to dlls/winedos. of dlls/winedos/module.c causes the following build failure on FreeBSD 4.4: /usr/bin/gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o module.o module.c module.c: In function `MZ_AllocDPMITask': module.c:614: warning: `return' with a value, in function returning void module.c: In function `MZ_Current': module.c:632: `write_pipe' undeclared (first use in this function) module.c:632: (Each undeclared identifier is reported only once module.c:632: for each function it appears in.) module.c:633: warning: control reaches end of non-void function gmake[2]: *** [module.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/winedos' gmake[1]: *** [winedos/libwinedos.so] Error 2 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

Re: [RFC] Async I/O patch: server code + ReadFileEx()
by Mike McCormack 05 Dec '01

05 Dec '01

Hi Martin, i hadn't heard from you in a while, so i though you might have given up after nobody said anything about the last patch, but i see you've been busy :-) i also had a go at fixing the problems you pointed out. i've attached the patch i've been working on... don't use it, it _will_ crash your wineserver! i need to create a requeue async request like yours, and activate my queues properly. The code is written to support async on serial port objects, not file objects. Some thoughts: * Shouldn't each wineserver object should manage it's own queues? Many different types of requests can be overlapped ... for example WaitNamedPipe can be overlapped. Should every object keep a queue for waiting on named pipes? * wineserver should manage the timeouts and activation of requests (i see we agree there) * Wouldn't it be better to pass an status code back to the client rather than the poll events? That way we can have STATUS_TIMEOUT, STATUS_PENDING, STATUS_CANCELLED, etc. STATUS_PENDING can be the signal to start reading/writing/etc. Mike Original message from: Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> > > >Hi, > >here is a patch that fixes some of the issues with the async IO >implementation in Wine that we discussed previously. My work on this >was delayed by other duties, sorry. To make matters worse, I'll be >out of office for the next 4 weeks (vacation :-) > > THIS PATCH IS NOT FOR PRODUCTION USE. > >I am submitting it as a RFC to show the basic concepts I am aiming at. >Most important is the server-side code (server/async.h, server/async.c) >that demonstrates the basic mechanism I am suggesting. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

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