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

Re: Fix for MoveFileExA

by Gerhard W. Gruber

On Thu, 31 Jan 2002 20:25:32 +0100, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: >Please, please, please not even more duplication ! >I really don't want to know how many times wininit.ini stuff has been >implemented/semi-implemented/... I didn't knew that there is already something. >If you *really* want to do some stuff, then get >http://home.nexgo.de/andi.mohr/download/winebootup.tar.bz2 >and start improving its wininit.ini handling >(this needs improving, AFAIK). OK. I just downloaded it. I hope I know how to open bz2. :) >Questions ? Just ask. Why is the To: field or the Reply-To: not set to the mailinglist instead of the poster? -- Bye, Gerhard If you think education is expensive, try ignorance.

Jan. 31, 2002

Re: Microsoft Visual C (MSVC) compabillity

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > All of the forms: > > (1) void WINAPI (*foo)(void); > (2) void (* WINAPI foo)(void); > (3) void (WINAPI *foo)(void); > > Seems to work with gcc. Even with gcc 2.7.x. I believe the problems were rather with g++. In my 2.95.4 version, case (2) still doesn't work (well it compiles but generates wrong code). Case (3) works though, so that sounds like the way to go, I'll apply your patch. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

ROTD (Rant Of The Day): patches

by Dimitrie O. Paun

Guys, I've come to _hate_ diffs attached as Application/OCTET-STREAM. Can you please, Please, PLEASE, attach them as Text/PLAIN? I use Pine over a ssh connection to read wine-{devel,patches}, and I can simply view the Text/PLAIN attachments, whereas I have to: -- press V to view the list of attachments -- select the attachment I want to view -- press S to save it to disk -- exit Pine -- start vi to actually view the thing -- restart pine... Just to view a Application/OCTET-STREAM attachment. Which means 2 things: -- I get frustrated (and look what happens when I do:)) -- I simply ignore those patches For all these reasons (and more), I think Linus is right when he insists on: -- ONE patch per email -- ONLY Text/PLAIN attachments. -- Dimi.

Jan. 31, 2002

Re: Pajama Sam's unmanaged window

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Hmm. I thought SetWindowLong worked differently than SetClassLong. Weird > stuff... Yes it does, you are right my explanation was more for SetClassLong than SetWindowLong. Basically SetClassLong will affect all windows created with a given class, SetWindowLong will affect a single window, and creating a new class + GetClassLong on the old one will affect all windows created with the new class but not those created with the old class. The nice thing with the Windows API is that everything is so straightforward... -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

Re: Pajama Sam's unmanaged window

by Ove Kaaven

On 31 Jan 2002, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > Do you have any examples where it might not work... window subclassing is > > the act of using SetWindowLong to replace the window procedure, which does > > not change the class atom, as far as I know? > > That's if you want to subclass all windows of a given class. Hmm. I thought SetWindowLong worked differently than SetClassLong. Weird stuff...

Jan. 31, 2002

Re: SetupAPI (dll)

by Stefan Görling

Dear Andreas, > So just go ahead immediately :) I'm right on it. A Simple stupid question. Is there a simple way to read a line from a HANDLE or a unixhandle? I've looked a bit at ReadFile (file/file.c) but I'm lazy, so if there is a better way :) /Stefan

Jan. 31, 2002

Re: Pajama Sam's unmanaged window

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Do you have any examples where it might not work... window subclassing is > the act of using SetWindowLong to replace the window procedure, which does > not change the class atom, as far as I know? That's if you want to subclass all windows of a given class. If you just want to create your own menu windows but not change the existing menus, you would create a new class with a new name, and then chain down to the menu window proc for any unhandled message. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

Re: mingw32 port and cygwin

by Alexandre Julliard

"Steven Edwards" <Steven_Ed4153(a)yahoo.com> writes: > The last major thing will be the spec and def differences. Because we > are compiling with mingw and making windows dlls using dlltool, we need > to easily convert from specs to defs. I was going to write a shell > script or a simple c program that did this but if anyone has a more > elegant solution please feel free to suggest one. I'd suggest making winebuild generate the .defs; this way you don't need to write a new .spec file parser. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

Re: Pajama Sam's unmanaged window

by Ove Kaaven

On Fri, 1 Feb 2002, Dmitry Timoshkov wrote: > "Ori Pessach" <ori_pessach_blah(a)yahoo.com> wrote: > > > > Since this is probably not the case, perhaps it's better to check for the > > > popup menu class in is_window_managed(), something like > > > > > > if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return > > > FALSE; > > > > Ah ha! Exactly what I had in mind. After thinking about this, it seemed to me > > that is_window_managed() should examine the window's class, as well as its > > style bits, since the class will give a more accurate indication of what kind > > of window we're dealing with than just the style bits. > > Unfortunately this aproach does not work well in all cases, especially in > the case of subclassed windows. Do you have any examples where it might not work... window subclassing is the act of using SetWindowLong to replace the window procedure, which does not change the class atom, as far as I know?

Jan. 31, 2002

Re: CreateProcess API - undocumented use

by Andreas Mohr

On Thu, Jan 31, 2002 at 04:54:55PM -0200, Ricardo wrote: > > Hmm, so you mean some program launches another program, passing a value > > in STARTUPINFO.dwFillAttribute, right ? > > If so, how does the launched process retrieve the STARTUPINFO content > > in your case ? > > It's writen a file with a random name that's read by the second program. > > > Wine certainly doesn't pass the STARTUPINFO strut content to program > > space yet; it's simply being used for initializing certain aspects of > > the new program. > > What I saw was that I run the first program, it write the file and wine > closes, then it restart with the other program, but it can't read the file > because it lost the file name, isn't it? It's the same error I get when I > run the second program alone. Well, show us how the second program is supposed to get at that data, and we'll show you what doesn't work at the moment. I'm still a bit ignorant about how exactly your programs do that data transfer (especially on the "client" side), thus please show us how this is supposed to be done. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 31, 2002