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

Re: Don't let cabinet Extract() crash IE

by Gregory M. Turner

On Tuesday 06 January 2004 12:10 pm, Mike Hearn wrote: > On Tue, 2004-01-06 at 17:59, Stefan Leichter wrote: > > The pointer points to a structure like this: > > > > struct ExtractFileList { > > LPSTR filename; > > struct ExtractFileList *next; > > DWORD unknown; // always 1L > > } ; > > Could the unknown be a boolean? > > > Did your start modifying/fixing the extract function for this item? If > > not i will do it. > > No, I didn't, please do it :) > > thanks -mike Just a wild guess -- might this unknown boolean be whether or not (1 meaning "not," I guess) to "run" the extracted file? This is one part of the "standard" that is rather unclear (for example, what does "run" mean, exactly, and who does the running?), so one never knows where it might pop up, and it would make sense that real-world instances were "always" the same... Thanks for all these investigations; wish I was able to provide more help right now, but I have very little time ATM. -gmt

Jan. 6, 2004

Re: shell shorcuts

by Martin Fuchs

Hello, On 06.01.2004 18:51:16 Subhobroto Sinha wrote: > I had completed the patch for IPersistFile::Load() and associated functions. > In the last patch which I had submitted for review here, Mike McCormack had > pointed out an incorrect assumption that I had made about all locales being > DBCS. Thanks to him, many of you will not suffer ;) I am working on the ReactOS Explorer, which uses Wine's shell32 implementation. We already have made many bugfixes and estensions to the shell link and other shell32 code. One of those extensions is the implementation of control panel in shell namespace. We will post this big patch for shell32 next time. (when some remaining problems will be solved) As I saw in from the comment in your Stream_LoadString() patch, you are not sure about the meaning of the SCF_UNICODE flag in *.lnk files. Well, I think it's because it has been defined wrong. I am currently using this definition: #define SCF_UNICODE 0x80 (instead of 0x1000) This is at least compatible to links of WIN95 (ANSI strings) and WIN XP (UTF16 strings). I did not yet test any other operating system versions. With this corrected defintion and a few more extensions Stream_LoadString() works pretty well on ReactOS. Regards, Martin

Jan. 6, 2004

Re: no keyboard events in ddraw application.

by Mike Hearn

On Tue, 06 Jan 2004 08:53:01 -0600, Aric Stewart wrote: > if you place them into a desktop then it works fine. I am unfamiliar > enough with that level of the windowing code that i am unsure how to fix > it right. I think the reason we make these windows unmanaged is because they don't have window borders - if you can figure out a patch to allow them to be managed that would go some way towards fixing this issue I think (though fullscreened apps would still require some more work). The tricky bit is being able to tell the difference between windows created for toplevel windows by the app and stuff like menu popups, tooltips etc.

Jan. 6, 2004

Re: Don't let cabinet Extract() crash IE

by Mike Hearn

On Tue, 2004-01-06 at 17:59, Stefan Leichter wrote: > The pointer points to a structure like this: > > struct ExtractFileList { > LPSTR filename; > struct ExtractFileList *next; > DWORD unknown; // always 1L > } ; Could the unknown be a boolean? > Did your start modifying/fixing the extract function for this item? If not i > will do it. No, I didn't, please do it :) thanks -mike

Jan. 6, 2004

Re: Don't let cabinet Extract() crash IE

by Stefan Leichter

Am Freitag, 2. Januar 2004 17:28 schrieb Mike Hearn: > Hi Stefan, > > The attached patch is necessary for IE installer to work again. It seems > the magic value is not always correct: advpack derefs this value so it > probably points to a struct. I'll try and find out what it contains when > using the native DLL (if anything). > > It seems to be optional, making it 0 allows IE to continue. > Hi Mike, your are right. Its a pointer to a structure. By running native cabinet.dll i found that the dll allocates two memory areas per file inside the cabinet that are not freed within the extract function. The first memory area is always 12 bytes. The size of the second one is the length of the filename without path plus 1. The pointer points to a structure like this: struct ExtractFileList { LPSTR filename; struct ExtractFileList *next; DWORD unknown; // always 1L } ; Did your start modifying/fixing the extract function for this item? If not i will do it. Bye Stefan

Jan. 6, 2004

Of games and shorcuts [was -> Re:More Games Tested]

by Subhobroto Sinha

Hello all, I had completed the patch for IPersistFile::Load() and associated functions. In the last patch which I had submitted for review here, Mike McCormack had pointed out an incorrect assumption that I had made about all locales being DBCS. Thanks to him, many of you will not suffer ;) Now that I fixed that last (?) weeny, I had sent it to Mike for a review. However, it seems he's a bit down now, and after waiting for about a week for his reply, I thought maybe I should ask you guys to nitpick ;) I really send this in because I went through Mike Kost's post 'More Games Tested', and I saw lots of 'err:menubuilder' and 'err:menubuilder:WinMain failed to build menu item for C:\windows\Start Menu\Programs\.......\ShortcutName.lnk' messages in his report. Hopefully, this patch should solve it ... If I get any bug reports, I will be happy to fill them out,else this one's going to Alexandre (with a few cosmetic changes of course !) Regards Subhobroto Sinha

Jan. 6, 2004

Re: Re: install default config files to $PREFIX/share/wine

by Dimitrie O. Paun

> Where do you want to have windows/ and windows/system/ > directory? In / of the UNIX filesystem, world writeable? :) OK, fine, you have a point :) But what I'm trying to say is that we can actually get away with a static config of sorts. We don't need a A: drive, it's mostly useless these days anyhow (and can be accessed through other means anyhow). Yes, we need C: to be writable and have the Windows directories, which means it can't point to /. Fine. So we'll need another one (Z is OK) to point to /. For perfect usability however, we would need definitions for CD drives ... So Alexandre seems to be right: something at boot time needs to look for devices. Or we can just have C: point to /, and install a symlink into / for the Windows dir. But then we'll have to always follow symlinks which can be a problem. Darn! -- Dimi.

Jan. 6, 2004

Re: event.c freezes on XFilterEvent

by Vik

Hi, > I have been quite busy recently but will try hard to get a patch put > together to get that all into wine. Wow! That will be fantastic! >If you want to work on it before i > get a chance you can hit the crossover source tree which i believe in > pointed to somewhere on our web site. I'll make sure I get my paws on the source tree, and see what I can do. Cheers Vik On Tuesday 06 January 2004 23:56, Aric Stewart wrote: > Hello, > > I have done extensive XIM work in the crossover tree and have it > working very well with a wide range of input methods including half and > full ime input methods used in applications such as office-jp. > > I have been quite busy recently but will try hard to get a patch put > together to get that all into wine. If you want to work on it before i > get a chance you can hit the crossover source tree which i believe in > pointed to somewhere on our web site. > > -aric > > Vik wrote: > > Hi, > > Happy New Year! > > > >>If I were you I would contect Mike McCormack & Jon Griffiths...... > > > > Thanks for the lead, I believe most of the current XIM patch code we use > > came from Mike's patch in 2002, and a mix of many other people's patches. > > I'll see if I can get in touch with him... > > > >>I'm sure -debug info would be apprishiated.. > > > > I'm sure it is... although, I'm not too sure on how to go about doing > > this. I'm thinking the wine --debugmsg output is not going to help much, > > so when debugging something like this, would I have to go into gdb or > > something of that sorts? (sorry I'm still rather new to all this :) ) > > > > I suppose since the whole CJK support issue is on the TODO, it has to be > > dealt with some how sooner or later. I'm more than willing to invest some > > time on this, although I'm not sure how much I can do. > > > > I'll see if I can "fix" it first and submit a patch here for review... :) > > XIM and all can come later... It's more of an annoyance issue right now > > anyway, as I often hit shift+space by accident (while typing in English) > > and brings the application to a halt. One thing I can think of right now > > is to get rid of the XIM related calls and think about implementing it > > better. Although that might not be a good way to go about it... > > > >>only the russians and french can spell correct in english :-) (we speak > >>it, they fix spelling mistakes = 50/50) > > > > Hehe. The important thing I guess is to get the point across :-) > > > > Cheers > > Vik -- ------------ Vikram Kumar vik(a)zone81.com

Jan. 6, 2004

Re: install default config files to $PREFIX/share/wine

by Jakob Eriksson

Marcus Meissner wrote: [snip] > >Where do you want to have windows/ and windows/system/ directory? In / >of the UNIX filesystem, world writeable? :) > >For SuSE, I have: > A: /media/floppy/ > > C: %HOME/.wine/fake_windows/ > ...some cd drives... > > X: /tmp/ > Y: %HOME% > Z: / > > > [snip] What are the common attack vectors of viruses and trojans and what can I do to prevent them? regards, Jakob

Jan. 6, 2004

Re: Re: install default config files to $PREFIX/share/wine

by chmorgan＠charter.net

If we also had working defaults for the users cdrom drive(s) and floppy drive then this would work quite well. Many users will want to install applications from cdrom. We could autodetect this at startup. Chris > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/01/06 Tue AM 09:44:05 EST > To: Alexandre Julliard <julliard(a)winehq.org>, > Marcus Meissner <marcus(a)jet.franken.de> > CC: cmorgan(a)alum.WPI.EDU, wine-devel(a)winehq.com > Subject: Re: install default config files to $PREFIX/share/wine > > On January 5, 2004 05:27 pm, Alexandre Julliard wrote: > > We will need a tool (maybe wineboot) to setup the initial drive config > > according to the machine setup. A default config file is not going to > > help with that anyway. > > I'd say we just have a C: drive pointing to / (root). This setup > is definitely the most user friendly, and the one most in the > spirit of Unix (one large tree). A user of a Unix system will be > most confortable with it, and it will create the least unexpected > behavior. > > Thinking about this, I'm not even sure why we encourage people to > define drives (by having a nice UI in winecfg)... What's wrong > with only a C: drive by default? Power users have regedit :) > > -- > Dimi. > > > >

Jan. 6, 2004

Re: install default config files to $PREFIX/share/wine

by Vincent Béron

Le mar 06/01/2004 à 09:44, Dimitrie O. Paun a écrit : > On January 5, 2004 05:27 pm, Alexandre Julliard wrote: > > We will need a tool (maybe wineboot) to setup the initial drive config > > according to the machine setup. A default config file is not going to > > help with that anyway. > > I'd say we just have a C: drive pointing to / (root). This setup > is definitely the most user friendly, and the one most in the > spirit of Unix (one large tree). A user of a Unix system will be > most confortable with it, and it will create the least unexpected > behavior. > > Thinking about this, I'm not even sure why we encourage people to > define drives (by having a nice UI in winecfg)... What's wrong > with only a C: drive by default? Power users have regedit :) Are you thinking that all installers (CD-based) are able to cope with the data not at the root of a drive? What about those which just know that C:\Windows or C:\Program Files are always present and valid? My small experience (mostly second-hand, I must say) is that's not always the case. Vincent

Jan. 6, 2004

Re: event.c freezes on XFilterEvent

by Aric Stewart

Hello, I have done extensive XIM work in the crossover tree and have it working very well with a wide range of input methods including half and full ime input methods used in applications such as office-jp. I have been quite busy recently but will try hard to get a patch put together to get that all into wine. If you want to work on it before i get a chance you can hit the crossover source tree which i believe in pointed to somewhere on our web site. -aric Vik wrote: > Hi, > Happy New Year! > > >>If I were you I would contect Mike McCormack & Jon Griffiths...... > > Thanks for the lead, I believe most of the current XIM patch code we use came > from Mike's patch in 2002, and a mix of many other people's patches. > I'll see if I can get in touch with him... > > >>I'm sure -debug info would be apprishiated.. > > I'm sure it is... although, I'm not too sure on how to go about doing this. > I'm thinking the wine --debugmsg output is not going to help much, so when > debugging something like this, would I have to go into gdb or something of > that sorts? (sorry I'm still rather new to all this :) ) > > I suppose since the whole CJK support issue is on the TODO, it has to be dealt > with some how sooner or later. I'm more than willing to invest some time on > this, although I'm not sure how much I can do. > > I'll see if I can "fix" it first and submit a patch here for review... :) > XIM and all can come later... It's more of an annoyance issue right now > anyway, as I often hit shift+space by accident (while typing in English) and > brings the application to a halt. One thing I can think of right now is to > get rid of the XIM related calls and think about implementing it better. > Although that might not be a good way to go about it... > > >>only the russians and french can spell correct in english :-) (we speak >>it, they fix spelling mistakes = 50/50) > > Hehe. The important thing I guess is to get the point across :-) > > Cheers > Vik > >

Jan. 6, 2004

Re: Re: install default config files to $PREFIX/share/wine

by brettholcomb＠charter.net

Do you really mean / and not ~? I sure don't want my C: pointing at /. And if there are more than one user how do I keep their stuff separate. What about access permissions to / - a normal user doesn't have it to many places. > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/01/06 Tue AM 09:44:05 EST > To: Alexandre Julliard <julliard(a)winehq.org>, > Marcus Meissner <marcus(a)jet.franken.de> > CC: cmorgan(a)alum.wpi.edu, wine-devel(a)winehq.com > Subject: Re: install default config files to $PREFIX/share/wine > > On January 5, 2004 05:27 pm, Alexandre Julliard wrote: > > We will need a tool (maybe wineboot) to setup the initial drive config > > according to the machine setup. A default config file is not going to > > help with that anyway. > > I'd say we just have a C: drive pointing to / (root). This setup > is definitely the most user friendly, and the one most in the > spirit of Unix (one large tree). A user of a Unix system will be > most confortable with it, and it will create the least unexpected > behavior. > > Thinking about this, I'm not even sure why we encourage people to > define drives (by having a nice UI in winecfg)... What's wrong > with only a C: drive by default? Power users have regedit :) > > -- > Dimi. > > >

Jan. 6, 2004

Re: install default config files to $PREFIX/share/wine

by Marcus Meissner

On Tue, Jan 06, 2004 at 09:44:05AM -0500, Dimitrie O. Paun wrote: > On January 5, 2004 05:27 pm, Alexandre Julliard wrote: > > We will need a tool (maybe wineboot) to setup the initial drive config > > according to the machine setup. A default config file is not going to > > help with that anyway. > > I'd say we just have a C: drive pointing to / (root). This setup > is definitely the most user friendly, and the one most in the > spirit of Unix (one large tree). A user of a Unix system will be > most confortable with it, and it will create the least unexpected > behavior. > > Thinking about this, I'm not even sure why we encourage people to > define drives (by having a nice UI in winecfg)... What's wrong > with only a C: drive by default? Power users have regedit :) Well, no. Where do you want to have windows/ and windows/system/ directory? In / of the UNIX filesystem, world writeable? :) For SuSE, I have: A: /media/floppy/ C: %HOME/.wine/fake_windows/ ...some cd drives... X: /tmp/ Y: %HOME% Z: / But this is case for endless discussion I guess. We could just make "C:" redefineable and leave the rest as default for instance. Ciao, Marcus

Jan. 6, 2004

Re: no keyboard events in ddraw application.

by Aric Stewart

I believe this is the same issue i am seeing with IE started in full screen mode. It appears that those windows are being created in unmanaged mode and thus never generate any of the focus events that wine uses to try to track input focus. if you place them into a desktop then it works fine. I am unfamiliar enough with that level of the windowing code that i am unsure how to fix it right. -aric Oleg Prokhorov wrote: > Hello wine-devel, > > I've got a problem with 'Theme Hospital' game application. It requires > some keyboard input to start. > > But the problem is that this application doesn't receive any > keyboard events. > > I've put some checks inside function process_events (dlls/x11drv/event.c) > but they show that no keyboard events (KeyPress, KeyRelease) > > I don't have any experience in this area and ask for you guidance, > where to look at. >

Jan. 6, 2004

Re: #pre5 - comdlg32 MS_VC + PSDK porting

by Dimitrie O. Paun

On January 4, 2004 01:39 pm, Steven Edwards wrote: > 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. Alexandre, let's just get rid of the NONAMELESSSTRUCT support, it just causes problems, and the benefit is a bit dubious. Any interesting compiler will probably be compatible with either msvc or gcc or both. Should I look at creating a patch? -- Dimi.

Jan. 6, 2004

Re: install default config files to $PREFIX/share/wine

by Dimitrie O. Paun

On January 5, 2004 05:27 pm, Alexandre Julliard wrote: > We will need a tool (maybe wineboot) to setup the initial drive config > according to the machine setup. A default config file is not going to > help with that anyway. I'd say we just have a C: drive pointing to / (root). This setup is definitely the most user friendly, and the one most in the spirit of Unix (one large tree). A user of a Unix system will be most confortable with it, and it will create the least unexpected behavior. Thinking about this, I'm not even sure why we encourage people to define drives (by having a nice UI in winecfg)... What's wrong with only a C: drive by default? Power users have regedit :) -- Dimi.

Jan. 6, 2004

RE: Will DCOM98 be pulled?

by Ivan Leo Murray-Smith

>can somebody with legal knowledge check the EULA and see if we >are allowed to redistribute this file? No legal knowledge needed, the EULA at http://www.microsoft.com/com/dcom/dcom98/eula.asp is very clear, and says that the user cannot distribute the dcom installer. Ivan.

Jan. 6, 2004

RE: Still having problems with Wine CVS

by Robert Shearman

> Hi, > I posted before in wine-users, but I haven't had any answer. > > I compiled, as usual, wine from cvs, but in the last weeks I have > this error > every file I try to run: > > err:msg:QUEUE_CreateMsgQueue Cannot get thread queueMain exe > initialization > for L"C:\\Program Files\\DepWalker\\depends.exe" failed, status c0000142 This is likely due to user32 not being recompiled properly and doing the wrong server call. If you haven't already make'd and "make install"'d user32, do so now. Otherwise, do a "make clean && make" and then a "make install". Note: whenever there are server changes you should at least recompile ntdll,kernel,user and gdi. > Only the path changes (correctly), the status code is always the same. > Can anyone help me? I had the same problem, but it was because I was too lazy to properly fix my build tree so I could install the whole lot at once. Rob

Jan. 6, 2004

no keyboard events in ddraw application.

by Oleg Prokhorov

Hello wine-devel, I've got a problem with 'Theme Hospital' game application. It requires some keyboard input to start. But the problem is that this application doesn't receive any keyboard events. I've put some checks inside function process_events (dlls/x11drv/event.c) but they show that no keyboard events (KeyPress, KeyRelease) I don't have any experience in this area and ask for you guidance, where to look at. -- Best regards, Oleg mailto:xolegpro(a)rbcmail.ru

Jan. 6, 2004

Re: Donations at SourceForge

by Tom

On Mon, 05 Jan 2004 01:40:20 -0500, Dimitrie O Paun <dpaun(a)rogers.com> wrote: > Hi folks, > > After intense setup work from Alexandre and myself (about 3 > clicks per person :P), we've managed to enable donations > through our SourceForge page: > > http://sourceforge.net/projects/wine/ > > Direct donation link: > > http://sourceforge.net/donate/index.php?group_id=6241 > > Now, to test the new facility, we need as many users as > possible make all sorts of donations to the project...;) > looks like a donations page update to me.. :) I'll update the page in a day or so. Tom

Jan. 6, 2004

Still having problems with Wine CVS

by Flameeyes

Hi, I posted before in wine-users, but I haven't had any answer. I compiled, as usual, wine from cvs, but in the last weeks I have this error every file I try to run: err:msg:QUEUE_CreateMsgQueue Cannot get thread queueMain exe initialization for L"C:\\Program Files\\DepWalker\\depends.exe" failed, status c0000142 Only the path changes (correctly), the status code is always the same. Can anyone help me? -- Flameeyes <dgp85(a)users.sourceforge.net> You can find LIRC for 2.6 kernels at http://flameeyes.web.ctonet.it/

Jan. 6, 2004

Re: AutoCad 2000 latest status ?

by P. Christeas

> 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. > At what point did Acad 2000 fail? For me, it just started up fine (since several months, CVS versions). At a few points (most notably with floating toolbars) it would have trouble. One other thing: The start dialog (the one where you choose 'empty project/file open/templates' etc. has blank (no text in them) buttons. But that wouldn't stop me from using acad. I do have a compile problem with wine right now, so I can't do tests with wine-latest. The one I now have (compiled) is Wine 20031016.

Jan. 6, 2004

Re: Hack for the '-pthread' at make depend

by P. Christeas

>... > FYI, I haven't managed to complete the make procedure anyway. It seems that > the 2.6.0 kernel headers (/usr/include/linux/) wrt. the scsi ones have some > trouble: > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ > -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing > -gstabs+ -Wpointer-arith -g -O2 -o cdrom.o cdrom.c > In file included from cdrom.c:47: > /usr/include/scsi/scsi.h:203: error: syntax error before "u8" > /usr/include/scsi/scsi.h:205: error: syntax error before "_r2" > /usr/include/scsi/scsi.h:206: error: syntax error before > "block_desc_length" /usr/include/scsi/scsi.h:207: error: syntax error > before "density" /usr/include/scsi/scsi.h:208: error: syntax error before > "number_blocks_hi" /usr/include/scsi/scsi.h:209: error: syntax error before > "number_blocks_med" /usr/include/scsi/scsi.h:210: error: syntax error > before "number_blocks_lo" /usr/include/scsi/scsi.h:211: error: syntax error > before "_r3" > /usr/include/scsi/scsi.h:212: error: syntax error before "block_length_hi" > /usr/include/scsi/scsi.h:213: error: syntax error before "block_length_med" > /usr/include/scsi/scsi.h:214: error: syntax error before "block_length_lo" > /usr/include/scsi/scsi.h:221: error: syntax error before "u8" > In file included from ../../include/winbase.h:22, > from cdrom.c:79: > ../../include/winerror.h:43:1: warning: "FAILED" redefined > In file included from cdrom.c:47: > /usr/include/scsi/scsi.h:301:1: warning: this is the location of the > previous definition Good news. I 've just seen this at LKML : http://marc.theaimsgroup.com/?l=linux-kernel&m=107338033309435&w=2 It means that this compile oddity will be fixed at kernel side (2.6.1).

Jan. 6, 2004

FONTSIZE

by Boaz Harrosh

Alexandre Julliard wrote: >Boaz Harrosh <boaz(a)hishome.net> writes: > > > >>Some simple fix for C++ with the macro FONTSIZE >>So ATL and MFC can compile. >> >> > >Why do you need that? It's not in the SDK header AFAICS. > > > Very good question: I'm not sure my self. The fix I send is no good either. In MFC I have simple declarations like this: FONTDESC _afxFontDescDefault = { sizeof(FONTDESC), OLESTR("MS Sans Serif"), FONTSIZE(12) , FW_NORMAL, DEFAULT_CHARSET, FALSE, FALSE, FALSE }; The VC++ will accept curly brackets fine. ..., {12000, 0}, but in GCC(++) it doesn't like that because of the CY union. It expects a single long long scalar instead. as so: ..., { 12000 }, so my new patch is: <Patch> Index: include/olectl.h =================================================================== RCS file: /home/wine/wine/include/olectl.h,v retrieving revision 1.19 diff -u -r1.19 olectl.h --- include/olectl.h 5 Sep 2003 23:15:44 -0000 1.19 +++ include/olectl.h 5 Jan 2004 08:24:39 -0000 @@ -97,7 +97,11 @@ BOOL fStrikethrough; } FONTDESC, *LPFONTDESC; -#define FONTSIZE(n) { n##0000, 0 } +#ifdef __cplusplus +# define FONTSIZE(n) { n##0000 } /*gcc expects one scalar for a long long in CY union*/ +#else +# define FONTSIZE(n) { n##0000, 0 } +#endif /*__cplusplus*/ #define PICTYPE_UNINITIALIZED (-1) #define PICTYPE_NONE 0 </Patch> My be it should be the same for c but I was afraid to touch

Jan. 6, 2004