wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Impressive success
by John K. Hohm 23 Oct '02

23 Oct '02

I just got an ATAPI Plextor PlexWriter 40/12/40A (which rocks), and Plextor's Win32-only firmware updater worked flawlessly in wine, a few months old CVS. Kudos to all involved in supporting that sort of access!

2 1

Re: wine not detecting CUPS printers
by Dan Fer 23 Oct '02

23 Oct '02

>From: "Dan Fer" <ezra_daniel(a)hotmail.com> >To: wine-devel(a)winehq.com >Subject: wine not detecting wine printers >Date: Wed, 23 Oct 2002 16:32:09 +0200 > > > > >Has anyone tried using cups under Wine in any of the latest builds? > >I tried to builds from this month and none detect any printer. > >Is there a patch? Anything I could use to fix it? > > > > > > >_________________________________________________________________ >MSN. Más Útil Cada Día http://www.msn.es/intmap/ _________________________________________________________________ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.microsoft.com/es

1 0

Re: French resources
by Vincent Béron 23 Oct '02

23 Oct '02

Le mer 23/10/2002 à 16:09, Vincent Béron a écrit : > This brings some French resources up-to-date with the English ones. > There are 3 resources not yet done: dlls/avifil32/avifil32_Fr.rc, > dlls/comctl32/comctl_Fr.rc and programs/winefile/Fr.rc. > > Plus it corrects a small typo in Shell32_En.rc. > > License: X11 and LGPL, as usual > > Changelog > Bring some French resources in sync with English ones. > > Vincent > ---- > Alexandre, Forget the programs/progman/Fr.rc from this patch. The one you just commited is better. But the rest of the patch is meant to be applied. Do you want me to resend a new one without that file? Vincent

1 0

Re: Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins
by chrismorgan＠rcn.com 23 Oct '02

23 Oct '02

Just so people don't think the code has fallen off of the face of the planet ;-) Currently I'm working on two things with the wine jack driver , one of which needs to be complete before I submit the patch, the other can wait until some ongoing jack support is complete. 1. The driver currently closes and opens jack connections synchronously with wodOpen and wodClose. The problem is that jack doesn't actually close the clients right away, sometimes it can take many seconds for this to occur. Apparently this is a known jack bug but I'm also wondering if this is a problem in wines pthread implementation of conditions(there is no support for them right now). Either way I've implemented a workaround that basically consists of opening jack connections and marking them as in-use or available as apps open or close audio devices. This behavior can be enabled/disabled via a define in the driver. This isn't complete yet but it should be soon and would prevent the lockups and delays that currently make things a pain. 2. I don't know of an easy way to do resampling so the input audio matches the sample rate that jack expects. What I want is to be able to do something along the lines of: set_sample_rates(input_rate, jack_output_rate); set_resample_algorithm(x); /* pick a reasonable algorithm based on the current cpu and latency requirements */ And then in the callback routine something like: resample(audio_data_in, *audio_data_out); I haven't found anything even close to this simple as of yet, if anyone has any suggestions feel free to mail me about them. There is someone on the jack mailing list working on a resampling library that is supposed to be easy to use and flexable. Either way, this isn't critical although your music sounds funny if your sample rates don't line up very well ;-) Otherwise I'm also looking into a crash with using the jack driver and directsound that might be due to the client process and memory allocation. After working on the arts driver I realized that the future of audio servers really is callback based. It is quite frustrating to see so little use of jack and so much use of poor solutions like direct hardware drivers(alsa/oss) or high latency servers like artsd. No offense intended to people that work on or use either of those audio solutions, it just doesn't make sense when you want to have multiple apps outputting audio at the same time or if you need low latency(high end audio, games?, etc). I'll see what I can do to get things cleaned up and a patch submitted in the next week, conditional of course upon Alexandre accepting jack support into wine. At least now I have someone other than myself with an interest in using jack and wine together ;-) Thanks, Chris > > From: "Kjetil S. Matheussen" <k.s.matheussen(a)notam02.no> > Date: 2002/10/23 Wed PM 12:18:13 EDT > To: linux-audio-dev(a)music.columbia.edu > CC: wine-devel(a)winehq.com > Subject: Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins > on Linux in real time > > > > On Wed, 23 Oct 2002, Taybin Rutkin wrote: > > > On Wed, 23 Oct 2002, Kjetil S. Matheussen wrote: > > > > > Could it be possible to overcome all problems mentioned just by simply > > > adding jack-support to the wine-server? Then someone could make a simple > > > windows-program for chaining directx and vst plug-ins. > > > > Someone has done this, I believe: > > http://kt.zork.net/wine/wn20021011_139.html#2 > > > Wow, it allready exist. Hey, wine-people, this driver is really needed for > real-time audio-work, and for programs as sound-editors, multitrackers > and interactive dsp programs as pd, jmax, and a lot of others. Artsd > (f.ex) is not an alternative in its current form, and probably never will > be either. Its something else. I guess Paul or some other competant person > can explain a bit more why jack is so important. > > > -- > > > > >

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

I did some testing and found that *\\whatever.exe does not work, while *whatever.exe does. In case anyone thinks to themselves, "but that could cause problems for xwhatever.exe!", I tested further and found that it only affects programs with the name whatever.exe and not those such as xwhatever.exe. -- Jeff S. >We could add this to show different behaviours : > >; you can specify applications too >; This one will apply for all notepad.exe >;"*\\notepad.exe" = "native, builtin" >; This one will apply only for a particular file >;"C:\\regedit.exe" = "native, builtin" > >Is everyone ok ? _________________________________________________________________ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp

3 2

Fixing OLE_GetFormatW
by Medland, Bill 23 Oct '02

23 Oct '02

I am just about to fix OLE_GetFormatW. (As far as I can see it can't have worked since rev 1.1). Before correcting the minor error I want to check something. Can anyone with access to NT answer this for me? If you pass a format string to GetDateFormatW that contains time-formatting characters I presume it just throws them away. Similarly if you pass a format string to GetTimeFormatW that contains date-formatting characters I presume it throws them away. Bill

1 0

fairly old wine regression: no$gmb no longer works
by Jonathan Gevaryahu 23 Oct '02

23 Oct '02

In wine builds from early? last year until January 29th, 2002, no$gmb (Nocash gameboy emulator) worked reasonably in wine (yes it would crash if you did 'animate trace' for too long, but that's a seperate issue). the commit which broke it was to wine/dlls/comctl32/status.c, on January 29th at 11:54 am. However, the fix that was done to status.c seems to be valid (later fixes to status.c do the same as what the fix did, I believe), so I suspect that the bug stems from some other issue which causes it to need the incorrect behavior in status.c in order to work. (personally I think it was something done during January that makes it need the incorrect status.c behavior, but I'm probably wrong) The nocash website is http://www.work.de/nocash/ or http://nocash.work.de/ Jonathan Gevaryahu

2 2

Bug tracked down in mci.c
by Erland Lewin 23 Oct '02

23 Oct '02

Hello, I just got the latest wine from cvs, and it crashed when I tried to run Half Life. The problem turned out to be in mci.c, in the mciSendStringA function. The variable lpCmd is set to point into the (in my case mciavi) driver's command table, at the word "open". However, towards the end of the mciSendStringA function, there is the following code: if (strcmp(verb, "open") == 0) { if ((dwRet = MCI_FinishOpen(wmd, (LPMCI_OPEN_PARMSA)data, dwFlags))) MCI_UnLoadMciDriver(iData, wmd); /* FIXME: notification is not properly shared across two opens */ } else { dwRet = MCI_SendCommand(wmd->wDeviceID, MCI_GetMessage(lpCmd), dwFlags, (DWORD)data, TRUE); } TRACE("=> 1/ %lx (%s)\n", dwRet, lpstrRet); dwRet = MCI_HandleReturnValues(iData, dwRet, wmd, lpCmd, data, lpstrRet, uRetLen); The problem is that MCI_UnLoadMciDriver is called, which causes the driver to be removed from memory, which means that lpCmd points to invalid memory. When MCI_HandleReturnValues then tries to use its lpCmd parameter, a segmentation fault will occur, becuase it tries to read from unmapped memory. I did a quick hack to work around the problem (lpCmd = strdup( lpCmd )) before the MCI_FinishOpen. I'd appreciate it if someone else could add a better permanent fix... Thanks for the good work on Wine!

2 1

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

> Actually there is a portable solution. Here's what i did when > I compiled > the Wine tests on Windows: > > Run 'vcvars32.bat' first. When you install Microsoft Visual C++ you > can either tell it to add environment variables with the useful stuff > (either in autoexec.bat or the registry for NT), or just rely on > 'vcvars32.bat'. This script is usually in the include directory: > c:\Program Files\Microsoft Visual Studio\VC98\include\vcvars32.bat > > Well, so I run it on the command line and then in the > makefile (a realy > .mak file) I put: > > INCLUDE=$(TOTOP)\include;$(INCLUDE) > > Then I don't use -I at all and the compiler will automatically use the > environment variable. If using the .mak file directly from the IDE you > don't even need to run vcvars32.bat, First of all I use .dsw/.dsp files not Makefile. OK, they are sort of Makefile but not quite. Secondly the idea is that have different targets so you can easily switch between them. So that does quite cut it. > However I still had include order problems: part of the headers were > coming from MS and part from Wine but did not have time to > look into it > in detail. So I ended up extracting the tests from the Wine > tree. But if > you are able to avoid the header mixup then the above could work. As Alexandre suggested I copied the needed header files. It work eventhough it is a little kludgy. Oh well, it will do for now. Now I just have to properly fix all compile error instead of just kludging them...

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > Of course compiling every DLL with the Microsoft headers requires > > fixing all of include/wine/ but then as long as we have a solution > > when we get where eventually is good enough IMHO, doing that is no > > particular rush. Having the Wine tests work properly sooner > > rather than later is much more important though. > > I agree getting the Wine tests to work soon is important, but you > don't really need the final header organization for that; you can > easily work around the current problem by copying files around or > specifying an absolute -I option. True. I have already done so. It works. Patch posted to wine-patches. > I don't think we have found a fully satisfying solution yet, and IMO > the situation will be clearer when the dll separation is finished and > the loose ends are cleaned up, so I'd prefer to wait until then to > decide on the final structure. OK. As you wish. > (And my secret hope is that by then we > will be able to switch to Subversion which should make renaming files > a lot easier; but that's another topic...) Ah, nice. :-)

1 0

message box fix.
by Rein Klazes 23 Oct '02

23 Oct '02

Hi, Fix for recent Messagebox breakage. windows/ : msgbox.c In MessageBoxIndirectW call FindResourceEx with arguments in the right order. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Docu fix for builtin/native apps
by Sylvain Petreolle 23 Oct '02

23 Oct '02

Changelog : Added valid entries into samples/config to specify if an app should be loaded builtin or native. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

wine not detecting wine printers
by Dan Fer 23 Oct '02

23 Oct '02

Has anyone tried using cups under Wine in any of the latest builds? I tried to builds from this month and none detect any printer. Is there a patch? Anything I could use to fix it? _________________________________________________________________ MSN. Más Útil Cada Día http://www.msn.es/intmap/

1 0

Re: Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

This patch did the trick. Well I cannot test it at the moment, but as the value INT_MAX (0x7fffffff) was the issue, I know this will fix it. The limit works a lot better (is a lot safer) than the 'special' value. ... - if (i == 0x7fff) + if (i >= 0x7fff) i = hdpa->nItemCount; ... >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >On October 23, 2002 01:29 am, Jeff Smith wrote: > > Oops, your previous message got lost in the shuffle... > > I'm sure anything is better than the little patch I wrote. > > I was just taking a minimalist approach to get treeview working. > >No, your patch was quite good. Would have certainly fixed the treeview, >but I think apps depend on the extended behavior. Does my patch fix >the problems you were experiencing? > >-- >Dimi. _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp

1 0

Re: Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

Oops, your previous message got lost in the shuffle... I'm sure anything is better than the little patch I wrote. I was just taking a minimalist approach to get treeview working. -- Jeff S Dimi wrote: >On October 23, 2002 12:44 am, Jeff Smith wrote: > > I discovered treeview uses DSA's and Dimi recently > > changed the max element number in DSA's to 0x7fff (SHRT_MAX). > > Note this value has the special meaning in DSA_InsertPtr > > functions of 'add new element to end of array'. > >This was my initial reaction to this thing, as well. But I >think my fix (sent earlier with Subject DPA_InsertPtr) is >better. Please try it out -- it should fix your problem. > >BTW, I've also audited all other uses of DPA_InsertPtr, >and they are fine. We should be back to normal now (well, >after my patch is applied, of course). > >-- >Dimi. _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp

2 1

LogonUser(), netapi work
by Martin Wilck 23 Oct '02

23 Oct '02

Hi, after having been busy with other stuff for a while, I'd like to inquire the status of my LogonUser() patch (http://www.winehq.com/hypermail/wine-devel/2002/09/0448.html) I have had almost no feedback, positive or negative, on this, and it wasn't applied either. I still think it could be useful, although it is clear that wine won't (shouldn't) be able to change personality in the foreseeable future. Andriy, what is the status of your netapi work? 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 1

Re: Using winbind with Wine
by Martin Wilck 23 Oct '02

23 Oct '02

Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett: > Firstly, it's good to see that winbind is starting to get some interest > :-) I have been ignoring it so far, but in the context of the current inquiries I tried it out and was impressed :-) > Secondly, don't fall into the trap squid (with my encouragement I might > add...) fell into - don't use the winbind pipe directly. The winbind > API is an internal Samba API, and can change without warning. Hmm - what other APIs are there? The only libraries that are accessible are nss_winbind and pam_winbind. Those two already carry us a long way, BUT ... I started thinking about other options when I found the "wbinfo -n" call. AFAIK there is no way to obtain equivalent info through PAM/NSS, simply because these APIs have no concept of a SID. Obviously apart from the SID there is a lot more information to gather from a PDC. I have not digged deeply enough into this to be able to enumerate everything, but think of the different GetUserInfo() calls on NT. libsmbclient can't be used by wine because it's GPL. And even if we could use it, it's headers only define calls related to shares and printing, which is not what I'm currently aiming at. > As to unicode, I > have designated one call as being in utf8, to cope with external > interaction, so it's possible things can happen here. What matters to wine is that if a call goes like this: Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC <-> Windows server, we must ensure that the Unicode string wine receives from the app reaches the server ungarbled. 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

8 12

Marshalling code for me to use?
by Greg Turner 23 Oct '02

23 Oct '02

Before I go off and duplicate a bunch of work somebody already did, I wanted to verify that wine has no existing implementation of NDR data marshalling? I don't know of such a thing, but I don't necessarily have the big picture. rpcrt4 needs this for somewhat obvious reasons, and the format is well documented by OpenGroup if we need to start an implementation from scratch. -- gmt

4 8

another snapshot (F_PL1_pre1)
by Greg Turner 23 Oct '02

23 Oct '02

relative to yesterday's RPC_E_PL15_unmerged.diff. LICENSE: X11 CHANGELOG: * dlls/rpcrt4: ndr_marshall.c, ndr_midl.c, ndr_misc.h, rpcrt4_main.c, ndr_stubless.c; include: rpcndr.h, wine/rpcfc.h: Greg Turner <gmturner007(a)ameritech.net> - make explicit some hidden include dependencies - Implement NdrGetBuffer, NdrFreeBuffer, NdrConformantStringBufferSize and NdrConformantStringMarshall - define the RPC_FC_C_CSTRING constant - perhaps I don't want those MIDL_*_FORMAT_STRING structs, after all. removed. - add todo list - MIDL_STUB_MESSAGE.uFlags aren't. - comment out the NdrClientCall2 mock-up since some of that stuff is in the process of being implemented. -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO

1 0

Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

Intro: Once I got wine to finally execute the native regedit, treeview was bringing it down. Background: I discovered treeview uses DSA's and Dimi recently changed the max element number in DSA's to 0x7fff (SHRT_MAX). Note this value has the special meaning in DSA_InsertPtr functions of 'add new element to end of array'. Problem: INT_MAX (0x7fffffff) was being passed from treeview to DSA_InsertPtr. This caused failure returns and eventually a seg fault. Conclusion: This patch fixes the problem (according to the style of other calls to DSA_InsertPtr), and native regedit now works. Questions for further thought: I wonder, should 0x7fff be used explicitly, or should SHRT_MAX be used in places like this instead? Changelog: Treeview fix due to change in maximum DSA size. -- Jeff S. Index: dlls/comctl32/treeview.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/treeview.c,v retrieving revision 1.103 diff -u -r1.103 treeview.c --- dlls/comctl32/treeview.c 6 Sep 2002 19:41:18 -0000 1.103 +++ dlls/comctl32/treeview.c 23 Oct 2002 04:12:53 -0000 @@ -949,7 +949,7 @@ if (!newItem) return NULL; - if (DPA_InsertPtr(infoPtr->items, INT_MAX, newItem) == -1) + if (DPA_InsertPtr(infoPtr->items, 0x7fff, newItem) == -1) { COMCTL32_Free(newItem); return NULL; @@ -2885,7 +2885,7 @@ for (child = item->firstChild; child != NULL; child = child->nextSibling) { - if (DPA_InsertPtr(list, INT_MAX, child) == -1) + if (DPA_InsertPtr(list, 0x7fff, child) == -1) { DPA_Destroy(list); return NULL; _________________________________________________________________ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

I agree that the example should be changed to indicate a 'valid' entry if this is the way it is supposed to be. This would have saved me a lot of trouble and confusion. Now I can work on getting native regedit working again. -- Jeff S. >Shouldn't we update the sample entry in documentation/sample/config ? > > ; you can specify applications too >-"*\\notepad.exe" = "native, builtin" >+"notepad.exe" = "native, builtin" > ; default for all other dlls > "*" = "builtin, native" > > > It's the way it's supposed to work, because it mimics the way > > loadorder works for dlls: a simple "regedit.exe" matches only if > > regedit is in the system directory. Otherwise you need to specify the > > full path, or use a wildcard entry like "*regedit.exe". > > > > -- > > Alexandre Julliard > > julliard(a)winehq.com _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

Found something: it works if I fully qualify the command name. I was trying this in the DllOverrides / command-line respectively: "regedit.exe" = "native, builtin" --dll regedit.exe=n,b What I have to do for it to work is this: "C:\\Windows\\regedit.exe" = "native, builtin" --dll C:\\Windows\\regedit.exe=n,b I still do not think this is *exactly* as it should be, but I'm finally on the track to figuring it out. -- Jeff S. _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp

3 2

[RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

As some of you probably know I have been working on compiling Wine on Windows using Microsoft Visual C/C++ (MSVC). Even though it doesn't really work that well yet there have been at least some success. Anyway recently I have began trying to get the Wine tests to compile and work using MSVC. More specifically I have been trying to get the my generated tests for data structure packing (tests/generated.c) to work. This currently works quite well. A few patches regarding errors found coming soon. However there are at least two intresting ways to compile and run the tests on Windows. 1. Compile using the Wine headers. 2. Compile using the Microsoft headers. Currently only (1) works in a portable way. To get (2) to work I had to add the directory of the Microsoft includes to the begining of the include path. This is not very portable since it differs from installation to installation. I have currently hardcoding my specific directory. The above have to be done because the Wine tests includes include/wine/test.h as thus ..\..\..\include (or similar depending on directory depth have to be added the the include). This overides the Microsoft headers!!! Microsoft C unlike GNU C have no option to avoid this other than adding the path the Microsoft include directory which as I previously mention varies depend on installation. :-) However I finally think I have found a portable solution, that will work not only with the Wine test but also with Wine itself (eventhough that is perhaps less instresting right now). We currently have the directory structure like include: Wine's version of Windows headers include/wine: Wine's internal and "extension" headers I would like to have a directory structure like include: Wine's version of Windows headers include/wine: Wine's internal headers include/wine/wine: Wine's "extension" headers With "extension" headers I mean that headers that are exported and usuable by Winelib applications. This would allow me to, using MSVC, just do /I ..\..\..\include\wine instead of the current very ugly and unportable /I d:\program files\microsoft visual studio\vc98\include /I ..\..\..\include So concretely what I think needs to be done (not tested) is the following. cd include/wine mkdir wine mv exception.h test.h unicode.h wine # Then include/Makefile.in needs to be changed accordingly as well. # In principle all the include/wine/ files named in include/Makefile.in # should be moved as well. However the files named above is enough for # the Wine tests AFAICS. --- Make.rules.in 19 Oct 2002 17:15:00 -0000 1.131 +++ Make.rules.in 21 Oct 2002 12:58:35 -0000 @@ -45,7 +45,7 @@ LN = @LN@ LN_S = @LN_S@ TOOLSDIR = @TOOLSDIR@ -DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include $(EXTRAINCL) +DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include -I$(TOPSRCDIR)/include/wine $(EXTRAINCL) ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS) LD = @LD@ LDFLAGS = @LDFLAGS@ So what do you think? Note that compiling Winelib applications under Linux might benefit from this as well since it makes it easier to use the real Microsoft headers together the Wine extensions (wine/*.h). Sure currently GNU C chokes on this but one day some compiler (GNU C or some other) might not...

3 2

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > We could do that following instead: > > (1) /usr/include/wine => /usr/include/wine/windows > > (2) /usr/include/wine/wine => /usr/include/wine/windows/wine > > (3) /usr/include/wine/wine/wine => /usr/include/wine > > > > Also note (2) will disappear eventually. > > Well, it's somewhat better, but it's still too complex IMO. Where is the complexity? If you want to port a Window application, you add -I/usr/include/wine/windows and everything as much as like under Windows as possible. If you in addition wish to call some Wine "extension" no problem just do #include "wine/foo.h" or similar. If you just want to use the Windows API in an Unix application you need anything at all. Just do #include "wine/windows/wincrypt.h" and you're done. [Linking is a separate problem, of course. But then, this changes nothing as far as this is concerned] > Maybe what > we should do is put the (3) headers directly in /usr/include, like > /usr/include/wine_unicode.h. But this would work only if we don't have > many of them, so we probably want to work on simplifying this first. I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h None of them requires any -I. It is more a convention that if you have many .h you have a directory, if not, well then you can have a directory anyway, it is up to you. > Also note that this is not going to solve your problem, because > wine/test.h is more a category (2) header Well wine/test.h is really kind of a special case anyway it could be moved to programs/winetest/include/wine or something under whatever name it is not really a concern. Perhaps we should move programs/winetest/wtmain.c to test/ and make it a library similar to library/ and unicode/. This is what I did with MSVC, eventhough I did it in programs/winetest instead. > (or maybe you need a new > category for Wine internal headers that don't get installed). You mean for files like windef16.h? Well, in the long run such files really belongs in the dlls/* directories. In the extent that that can't they really are Wine "extension" that might as well be used by any Winelib application not just internally should IMHO be installed. But yes, we certainly need some place to put them in the meantime, since this isn't happing over night. However I think that they can remain in include/wine/ until we move them one by one. See below. > > PS. Of course we could move include/*.h to include/wine/windows or > > something like that but then it is no real use and beside it ruins > > the cvs patch log. Better stick to the ugly include/wine/wine > > solution interally IMHO. > > Not an option. If we have to move the files we'll move them; it's > better to avoid moving things around too much. but we shouldn't let > CVS limitations impose a broken structure. OK. > Now if we can find a non > broken structure that also doesn't involve moving files that's better. Perhaps this would work: mkdir library/wine mv include/wine/{library,port}.h library/wine mkdir unicode/wine mv include/wine/unicode.h unicode/wine mkdir dlls/ntdll/wine mv include/wine/exception.h dlls/ntdll/wine Sure it would mean a few more -I internally but it would not be that bad. Then during install all these files as well as some files from include/wine/ ends up in /usr/include/wine and the include/ files end up in /usr/include/wine/windows or /usr/include/wine/win32 not sure what is best. That would require moving a minimum of files. As before eventually far in the future include/wine/ would be empty. Transition done. We needn't move everything right now either. As mentioned before running the Wine test with the Microsoft headers currently AFAICS only requires that we fix wine/{exception,test,unicode}.h. Of course compiling every DLL with the Microsoft headers requires fixing all of include/wine/ but then as long as we have a solution when we get where eventually is good enough IMHO, doing that is no particular rush. Having the Wine tests work properly sooner rather than later is much more important though.

3 2

using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

3 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