SPARC assembly won't compile, problems with NT headers
winegcc from the current WineHQ produces assembly output for SPARC systems
that cannot be processed by the assembler.
1. "operation combines symbols in different segments" error.
This problem arises because the imports code attempts to generate a relocation
involving symbols in different segments (one in the text segment and one in
the data segment). SPARC assemblers (including gas on a SPARC) cannot deal
with relocations involving symbols in different segments. This only affects
position independent code and can be avoided by changing the assembly code
output in imports.c to something simpler.
2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data
section}"
This problem is more sinister. It arises from the same limitation as the first
problem, but is not susceptible to being worked around. The offending code is
the code that attempts to generate the NT header of the executable -
specifically the SizeOfImage element. I can't see any way at this point to
provide for this calculation to be done until after the linker output is
generated. I suspect the solution to this problem is to just output a zero in
this location and have winegcc modify the executable image to insert the
correct values after the linker has created it.
Does anybody have any objections to this solution or another approach to
suggest?
--
Troy Rollo - [EMAIL PROTECTED]
Re: [lostwages] Remove winetools from download page
On 12/21/05, Tom Wickline <[EMAIL PROTECTED]> wrote: > > Happy Holiday's > Happy Holidays to you too :) -- James Hawkins
Re: [lostwages] Remove winetools from download page
On 12/21/05, James Hawkins <[EMAIL PROTECTED]> wrote: > On 12/21/05, Tom Wickline <[EMAIL PROTECTED]> wrote: > > > > So you agree that is currently needed, I believe it should stay until 1.0 > > > > The link or the program? Whether the program itself is needed is up > to the users of winetools, and they show that it's useful in the very > least, which I agree. Whether winetools is useful or not is not in > question though. As I and others have stated in previous emails, wine > should not promote the use of winetools nor restrict its use. > winetools should be a completely separate entity with a separate > mailing list, bugzilla, etc, and the link should not be on wine's > download page. For the reasons stated previously, this is in the best > interest of the developers of wine, but more importantly the users of > wine in the long run. To sum my replies up, I hole heartily agree with you James it's just that we differ on when not if the link should be removed. Winetools helps people run programs that they might not be able to and it helps them do that now. And that's what 99.9% of end users care about, can I run what I want to now? If the answer is no 99.8% of them will leave while .1% might stick around and wait on a fix. Happy Holiday's Tom > > -- > James Hawkins >
Re: [lostwages] Remove winetools from download page
On 12/21/05, Tom Wickline <[EMAIL PROTECTED]> wrote: > > So you agree that is currently needed, I believe it should stay until 1.0 > The link or the program? Whether the program itself is needed is up to the users of winetools, and they show that it's useful in the very least, which I agree. Whether winetools is useful or not is not in question though. As I and others have stated in previous emails, wine should not promote the use of winetools nor restrict its use. winetools should be a completely separate entity with a separate mailing list, bugzilla, etc, and the link should not be on wine's download page. For the reasons stated previously, this is in the best interest of the developers of wine, but more importantly the users of wine in the long run. -- James Hawkins
Re: [lostwages] Remove winetools from download page
On 12/21/05, James Hawkins <[EMAIL PROTECTED]> wrote: winetools will > eventually no longer be needed (which is a good thing!), and this is > one of the first steps towards that process and wine 1.0. So you agree that is currently needed, I believe it should stay until 1.0 Tom > > -- > James Hawkins >
Re: Bug 3885
Tom Spear gmail.com> writes: > > Aric Cyr wrote: > >>>I took a look at the D3D_OK hack, and I believe the problem to be > >>>CheckDeviceFormat in wined3d/directx.c. This function should return an > >>>error if > >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. > >>>Currently > >>>it just returns OK for most formats though. This code is really just a > >>>stub as > >>>it stands, and needs to be converted to check if there are any visuals that > >>>meet > >>>the requested format's requirements, and if there is, return D3D_OK, > >>>otherwise > >>>D3D_NOTAVAILBLE. > >>> > >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case > >>>(you'll need to add it) in wined3d/directx.c in > >>>IWineD3DImpl_CheckDeviceFormat() > >>>and see if that fixes that issue or not. This would be just another hack > >>>though, so a real patch would still be necessary as I decribed above. > > Well I took a stab at adding the case for D3DFMT_D32, to the bottom of > the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed > to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes > the first one and then goes to do the second one, but crashes in a > different spot, so it seems we also have some stack corrupion (as was > mentioned in the bug).. So that hack works for now, I would suggest > that since the rest of that code is stubbed out, we should probably go > ahead and submit a patch so we can at least run the darn thing and then > start debugging the stack corruption issue. Thanks for testing this out. You have proved my theory correct, so I'll see about making a patch which will correct CheckDeviceFormat(). Basically that whole function needs a re-write, so I'd rather do it that way than to put this hack in there. Especially since, I assume, this problem is not present on nVidia systems, only ATI. > I should add that on the first run, I disabled the title screens between > benchmarks, and changed the "Display and CPU Settings" so that I was > using 32-bit textures and triple buffering, and it ran thru several of > the tests, while on the 2nd and 3rd runs, I left all settings at > defaults; during run 2, it died just after the title screen for mark #2, > and during run 3, it died in the middle of mark #2... If I'm not mistaken, doesn't 3DMark change resolutions between benchmark and title screens? If so, it is possible, and quite likely that there is a resolution change bug in wine. If I recall, I had similar crashing problems with World of Warcraft if I tried to change resolutions from in-game. Regards, Aric
Re: [lostwages] Remove winetools from download page
On 12/21/05, Tom Wickline <[EMAIL PROTECTED]> wrote: > > Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say > we need to have Wine run everything out of the box and to accomplish this were > going to remove a link to a user friendly tool that currently helps our users. > If users continue to use winetools, wine won't get the needed testing coverage that will really help boost the development process. Many bugs will go unnoticed, new features won't be tested, and we won't get the feedback to make wine better. That's the beauty of open source; users are encouraged to tell us every bug or missing feature, and we will do our best to address the issues. The more eyes on wine, the better. > Then what? your going to have just as many, if not even more people on > IRC asking for > help who other wise wouldn't have had to do so. > I would love to see that day. I have no problem with people asking for help with wine on wine-users or IRC. The problem is when people report problems that are winetool specific, as Vitaliy initially stated. That's one of the reasons why I advocate a winetools specific mailing list, so people using winetools can reach the people that work on winetools. > > Wine is easy for me, and I'm sure for yourself to use and configure > but this is just not the case for a large number of people! > Usability is another rapidly progressing area of wine. You are exactly right in that it is easy for us to use, so we can't see through the eyes of a new wine user. We need more people to try wine out and tell us exactly what are is too difficult or not intuitive to use. That way we can fix it and make it easier for potentially many more users. If that user had used winetools, we would never get the report, and the issue would still remain. > > Removing WineTools is the worst thing this project could do at this time, as > its the *only* free GUI that makes a genuine attempt to help first > time users. On the contrary, winecfg is a great tool aimed to ease the use of wine and is being actively developed. Keep in mind that we don't want to remove winetools, just phase out winetools by advancing wine itself, and avoid promoting it from winehq. This should be taken in no way as an insult to winetools developers or users. The winetools developers are very competent, and their work is appreciated. winetools will eventually no longer be needed (which is a good thing!), and this is one of the first steps towards that process and wine 1.0. -- James Hawkins
Re: [lostwages] Remove winetools from download page
On 12/21/05, James Hawkins <[EMAIL PROTECTED]> wrote: > > As much as I appreciate the work you, Joachim, and others have put > into winetools, we're getting closer to the point in time when > winetools needs to be phased out by a better, more functional wine. > Part of this process is removing it from the official download page. Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards to say we need to have Wine run everything out of the box and to accomplish this were going to remove a link to a user friendly tool that currently helps our users. Then what? your going to have just as many, if not even more people on IRC asking for help who other wise wouldn't have had to do so. Wine is easy for me, and I'm sure for yourself to use and configure but this is just not the case for a large number of people! Removing WineTools is the worst thing this project could do at this time, as its the *only* free GUI that makes a genuine attempt to help first time users. Tom > > -- > James Hawkins > > >
Re: [lostwages] Remove winetools from download page
n 12/21/05, Sven Paschukat <[EMAIL PROTECTED]> wrote: > > Joachim says that he has 30.000 downloads per month. That's a big number > and if only one percent of the users has problems, then of course your > hear of them. > That's the problem; a clear distinction between wine and winetools is required. The wine-devel and wine-users lists are for the wine project, and any problems users have with winetools, or because of winetools, should be reported on a winetools mailing list. > And of course mostly users only report when they have problems. Can you > refer these users to the Wine users mailing list? We need detailed > feedback to fix remaining problems. > > James, please don't see the value of winetools only from a developers > view. Normal linux users don't want to test builtin dlls, they just want > to get their windows apps working on linux. IMHO it's better for Wine if > the users become an easy feeling of success instead of letting them fall > from one pitball into another. > Trust me, I don't. I think winetools is a great app, and I've used it on several occasions. I agree that most users want to easily use their windows apps using winetools, and I'm not of the opinion that they shouldn't use winetools. Vitaliy's point is that wine is progressing rapidly towards a 1.0 stable release. Wine's COM implementation is being worked on heavily, along with msi (and uncountless other areas.) Wine is at the point where a user shouldn't need winetools to use many windows apps. For example, it's possible to install IE6 by only registering one native dll and using another native dll for the installer. As much as I appreciate the work you, Joachim, and others have put into winetools, we're getting closer to the point in time when winetools needs to be phased out by a better, more functional wine. Part of this process is removing it from the official download page. -- James Hawkins
Re: [lostwages] Remove winetools from download page
On 12/21/05, Sven Paschukat <[EMAIL PROTECTED]> wrote: > James, please don't see the value of winetools only from a developers > view. Normal linux users don't want to test builtin dlls, they just want > to get their windows apps working on linux. IMHO it's better for Wine if > the users become an easy feeling of success instead of letting them fall > from one pitball into another. I agree that Winetools has an intended audience and I think there's a place for an app like that. Heck, look at CodeWeavers and their cxsetup program. Having said that, are there things that Winetools does that need to be moved into Wine? I'm not sure anyone has ever looked at that. Are there registry settings that belong in wine.inf? Any time a .EXE can't be run out of the box you have to question what Wine is doing wrong to prevent that. -Brian
Need help fixing deadlock (GDI)
Hi, I have spent days finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some more traces I feel I am pretty close but I'm stuck now. The problem is connected to GDI's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is this comment "FIXME: there is a race condition here"... is that the cause? Btw. this might be the same problem as bug #3125. Can somebody give me a hint on how to tackle this? If you need more output please let me know. Thanks a lot, Cihan
Re: [lostwages] Remove winetools from download page
Vitaliy Margolen schrieb: > I can't say how many people have come to #winehq with different problems > that were related to winetools. From what I could see, not a single > person who I talked to had winetools installed and had Wine programs > working properly. Well, it was just a few month ago when Joachim and me has reworked the winetools. It is no longer config file based, it is using the registry now. We have tested it on multiple Linux distributions and the newest release WineTools 0.9 III hasn't showed serious problems when walking through the menus as intended. Joachim says that he has 30.000 downloads per month. That's a big number and if only one percent of the users has problems, then of course your hear of them. And of course mostly users only report when they have problems. Can you refer these users to the Wine users mailing list? We need detailed feedback to fix remaining problems. James, please don't see the value of winetools only from a developers view. Normal linux users don't want to test builtin dlls, they just want to get their windows apps working on linux. IMHO it's better for Wine if the users become an easy feeling of success instead of letting them fall from one pitball into another. Thanks for the assistance of Tom and Michael. Sven
Re: Bug 3885
Aric Cyr wrote: I took a look at the D3D_OK hack, and I believe the problem to be CheckDeviceFormat in wined3d/directx.c. This function should return an error if D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently it just returns OK for most formats though. This code is really just a stub as it stands, and needs to be converted to check if there are any visuals that meet the requested format's requirements, and if there is, return D3D_OK, otherwise D3D_NOTAVAILBLE. To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case (you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() and see if that fixes that issue or not. This would be just another hack though, so a real patch would still be necessary as I decribed above. Well I took a stab at adding the case for D3DFMT_D32, to the bottom of the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes the first one and then goes to do the second one, but crashes in a different spot, so it seems we also have some stack corrupion (as was mentioned in the bug).. So that hack works for now, I would suggest that since the rest of that code is stubbed out, we should probably go ahead and submit a patch so we can at least run the darn thing and then start debugging the stack corruption issue. I should add that on the first run, I disabled the title screens between benchmarks, and changed the "Display and CPU Settings" so that I was using 32-bit textures and triple buffering, and it ran thru several of the tests, while on the 2nd and 3rd runs, I left all settings at defaults; during run 2, it died just after the title screen for mark #2, and during run 3, it died in the middle of mark #2... begin:vcard fn:Tom n:Spear;Tom note:a.k.a. Dustin Navea x-mozilla-html:TRUE version:2.1 end:vcard
_itow tests in ntdll/tests
Hi, I was just diving into this as there is failure for months with this test on Winxp-SP2 and W2K3. We call _itow, like this: result = p_itow(ulong2str[0].value, NULL, 10); This however seems not be allowed anymore. Changing it to WCHAR buffer[LARGE_STRI_BUFFER_LENGTH + 1]; result = p_itow(ulong2str[0].value, buffer, 10); make the test succeed, but I don't know what the author wanted with these tests. Any ideas ? Cheers, Paul.
Re: PATCH/RFC: defer OLE apartment window creation
On Wed, Dec 21, 2005 at 02:55:14AM +, Robert Shearman wrote:
> Marcus Meissner wrote:
>
> >@@ -257,6 +254,15 @@
> >return apt;
> >}
> >
> >+void make_apartment_window(APARTMENT *apt) {
> >+if (apt->win) return;
> >+if (!(apt->model & COINIT_APARTMENTTHREADED))
> >+return;
> >+apt->win = CreateWindowW(wszAptWinClass, NULL, 0,
> >+ 0, 0, 0, 0,
> >+ 0, 0, OLE32_hInstance, NULL);
> >+}
> >+
> >
>
> This isn't thread-safe. It would also be better to make this an accessor
> function for the win field of struct apartment and fix up all callers to
> use this. I still have to verify on Windows whether this is what it does
> or whether it does something funny with message loops.
I lack the time and testing abilities to do this right now (and now
on xmas break).
Its just a quick hack to get Google Earth running.
It is now up to showing the famous GL "black screen". :(
(WINEDLLOVERRIDES=*usp10=n)
Ciao, Marcus
Re: sound enabled but no driver checked
Robert Reif wrote: > Cihan Altinay wrote: > >> Quoting Robert Reif <[EMAIL PROTECTED]>: >> >> >> >>> Cihan Altinay wrote: >>> >>> >>> With a fresh wine prefix sound is enabled but I can't see which driver is used because none of them is checked in the new winecfg sound dialog. Did we forget to initialize the boxes on first run? Cheers, Cihan >>> >>> Use regedit to show HKCU/Software/wine/Drivers/Audio. >>> Chances are it's empty (no drivers checked) so sound is >>> disabled. It could be set to a driver that is not available >>> but winecfg checks for that and should give you an error. >>> >> >> >> Well... the key doesn't exist unless I run winecfg at least once >> and change something. In that case it's not really important because >> a user will probably do that anyway. >> The only minor issue would be that someone runs winecfg for the first >> time and is satisfied with the defaults (no driver checked -> sound off) >> so without any changes he dismisses winecfg. And in this case it seems >> one of the drivers is used by default (sound on). >> >> Cheers, >> Cihan >> >> >> >> > I have a patch to fix this. OSS is the default if there is no registry > key. Great! Will you submit it?
Re: has the LGPL licence fell through ?
> > It is not a requirement that patches be submitted - only that source code be > made available. Patches are normally submitted because it is more convenient > for the developer if the change is in the canonical version. If the developer > does not see the value of having their patch in the canonical tree, they will > not (and are not required to) submit it. In fact, the only person that can demand anything wrt the LGPL is someone that is running their software. So if someone has bought a copy of TurboLinux 11 in Japan, they have the right to demand a copy of the source code to the Wine bits in Project David; presumably they'd have to ask Turbo Linux. Be great if someone would do that... Cheers, Jeremy
Re: [lostwages] Remove winetools from download page
On 12/21/05, Michael Jung <[EMAIL PROTECTED]> wrote: > > I did'nt use winetools for quite a while now, but it was a great tool to get a > newbie up and running with wine back then. If it hurts us more than it helps > today, then we should take some action. But could we perhaps get in contact > with Joachim von Thadden before we remove the link? He has put a lot of > effort in winetools and he's a great wine advocate (He wrote a multi page > technical article on wine for c't magazine a few months ago, which is one of > the big computer publications here in germany. This article was based on > winetools, but also did a lot of advertising for CodeWeavers and Wine in > general). In my opinion he deserves some respect from our part. We should > give him a chance to fix the problems with winetools before we silently > remove the link. I am in agreement with the above paragraph.. Cheers, Tom > > Bye, > -- > Michael Jung > [EMAIL PROTECTED] > >
Re: has the LGPL licence fell through ?
Hi, On Wed, Dec 21, 2005 at 07:48:09AM +, Aric Cyr wrote: > Seeing that SpecOps Labs history of ignoring Wine developers extends for more > than a year, then yes I can agree with that. Yup, there has been more silence than anything else. > According to their Partners' page, IBM and Turbolinux and a few others seem to > be footing the bill. I'm sure a well written email to either of those places > would get a real response, and probably apply due pressure on SpecOps Labs. Oh, now that's "interesting". Especially given that IBM's usual stance about Wine is often said to be... umm... let's say "mildly sceptical". But since the "Partners" text already mentions that it is an IBM Philippines cooperation, this seems to imply that the corporation's left hand doesn't know what the right hand is doing (yet! this might change in the future... Hello SpecOpsLabs!). Oh well... Andreas Mohr
Re: has the LGPL licence fell through ? (forw)
Joerg Mayer loplof.de> writes: > On Wed, Dec 21, 2005 at 07:48:09AM +, Aric Cyr wrote: > > Maybe I'll fire off an email to Turbolinux to see what they have to say, > > although technically unless I purchase or receive their product I am not > > directly entitled to the GPL/LGPL code from them. Anyone have a copy of > > Can you please let me know why you think that? > > > 2. You may modify your copy or copies of the Library or any portion > of it, thus forming a work based on the Library, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) The modified work must itself be a software library. > > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > > c) You must cause the whole of the work to be licensed at no > charge to all third parties under the terms of this License. > ... > --- You are reading this from the wrong point of view I believe. The "You" in this case would be SpecOps Labs. They implicitly agree to this LGPL license by modifying hte copyrighted code. > > So I guess if they are using some code of yours that you provided to them > under > LGPL, you are entiteld to request the source. In case this goes to court > you'll > need a copy, but for now it is sufficient to be sure that they are > distributing > a product based on your code which is covered by the LGPL. Anyone who buys their product, or anyone they give their product to is entitled to the source code. >From LGPL section 4 (remember, "You" = SpecOps Labs): 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. > Again: It is *you* who granted them the right to use your code, and by putting > it under LGPL you made sure that you are entitled to any changes they make to > *the* code once they start distributing your code (or derivatives) to thrid > parties. That way you can reqeust the changes even when the new product costs $10M. No,that's not the way GPL or LGPL works I'm afraid. These licenses exist so that the users of the applications, etc will always have free access to the source code, and the free rights to redistribute it as necessary. Their purpose is free speech not free beer. As Brian said, they are perfectly in their right upto now (as long as there are no products with Wine code floating around), it's just that they are really sticking it to the the community and not playing nice. It is (current) philisophical, not legal. When someone gets a copy of David, and SpecOps Labs refuses to disseminate the code, then it will become legal. - Aric
New trying to debug missing menubar
There's an old Windows 3.1 app I'm trying to use under wine, but it's
menubar is missing. It was used for in house development for a really
old game, but the programmer has asked me not to redistribute it so I
can't provide a link/download. The application otherwise looks and acts
exactly as it should -- but the File/About/etc. menubar is missing and
thus the ability to use any of those options (I don't think the app has
any accelerators).
Seeing as this is such a "simple" bug (watch me eat my words) I thought
it'd be a good chance to try some wine hacking. So I read the wine
developer guide and tried my best. But my unfamiliarity with the Windows
API / Wine has me stuck :P
I've included the results of me running with WINEDEBUG=+menu below. The
only thing that sticks out to me is this:
warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0
Which occurs multiple times. Looking at dlls/user/menu.c (function
starts on line 101), it looks like USER_HEAP_LIN_ADDR is returning a 0
pointer which causes the warning. Someone in #winehq said
USER_HEAP_LIN_ADDR is for 16<->32 bit conversion because 16bit apps use
segment:offset to address memory (I'm still not totally sure how a
segment differs from a memory address) while 32bit apps use flat
addresses. USER_HEAP_LIN_ADDR itself looks like a very magical macro
where to look based on it.
strings informs me it's a Borland C++ 1991 app, if that's important.
When I did a +relay all that showed up between the warn:menu's was
calls to ENABLEMENUITEM.
Hints for a newb? :)
trace:menu:CreateMenu return 0x50
trace:menu:MENU_GetSysMenu hWnd 0x10022 (hMenu 0x50)
trace:menu:LoadMenuIndirectW 0x7f9cea54, ver 0
trace:menu:CreateMenu return 0x94
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f120, str
L"&Restore"
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=0x7f9cea5c
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf120,
Text=L"&Restore" }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f010, str
L"&Move"
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=0x7f9cea72
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf010,
Text=L"&Move" }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f000, str
L"&Size"
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=0x7f9cea82
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf000,
Text=L"&Size" }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f020, str
L"Mi&nimize"
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=0x7f9cea92
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf020,
Text=L"Mi&nimize" }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f030, str
L"Ma&ximize"
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=0x7f9ceaaa
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf030,
Text=L"Ma&ximize" }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id , str
(nil) (not a string)
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=(nil)
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0,
Type=sep }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f060, str
L"&Close\tAlt-F4"
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=0x7f9ceac8
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf060,
Text=L"&Close\tAlt-F4" }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id , str
(nil) (not a string)
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=(nil)
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0,
Type=sep }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f130, str
L"&Switch to ...\tCtrl-Esc"
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=0x7f9ceaee
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf130,
Text=L"&Switch to ...\tCtrl-Esc" }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id , str
(nil) (not a string)
trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0,
Text=Null }
trace:menu:MENU_SetItemData flags=400 str=(nil)
trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0,
Type=sep }
trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 0400, id f141, str
L"&About WINE ..."
trace:menu:do_deb
Re: has the LGPL licence fell through ? (forw)
as a simple reply isn't sent to the list - Forwarded message from Joerg Mayer <[EMAIL PROTECTED]> - Date: Wed, 21 Dec 2005 09:22:11 +0100 From: Joerg Mayer <[EMAIL PROTECTED]> To: Aric Cyr <[EMAIL PROTECTED]> Subject: Re: has the LGPL licence fell through ? In-Reply-To: <[EMAIL PROTECTED]> On Wed, Dec 21, 2005 at 07:48:09AM +, Aric Cyr wrote: > Maybe I'll fire off an email to Turbolinux to see what they have to say, > although technically unless I purchase or receive their product I am not > directly entitled to the GPL/LGPL code from them. Anyone have a copy of Can you please let me know why you think that? 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. ... --- So I guess if they are using some code of yours that you provided to them under LGPL, you are entiteld to request the source. In case this goes to court you'll need a copy, but for now it is sufficient to be sure that they are distributing a product based on your code which is covered by the LGPL. Again: It is *you* who granted them the right to use your code, and by putting it under LGPL you made sure that you are entitled to any changes they make to *the* code once they start distributing your code (or derivatives) to thrid parties. That way you can reqeust the changes even when the new product costs $10M. Ciao Joerg -- Joerg Mayer <[EMAIL PROTECTED]> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. - End forwarded message - -- Joerg Mayer <[EMAIL PROTECTED]> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.
Re: Bug 3885
Tom Spear gmail.com> writes: > Louis also hard coded D3D_OK into wine in the right spot and managed to > get the program to go thru all benchmarks from 1-16, so wine is > mis-reporting something there. > > If someone could take a look and propose a fix, it would be appreciated, > seems to me that the 2 fixes should be fairly trivial to come up with > since those 1 line hacks worked to get around the aforementioned problems. > I took a look at the D3D_OK hack, and I believe the problem to be CheckDeviceFormat in wined3d/directx.c. This function should return an error if D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently it just returns OK for most formats though. This code is really just a stub as it stands, and needs to be converted to check if there are any visuals that meet the requested format's requirements, and if there is, return D3D_OK, otherwise D3D_NOTAVAILBLE. To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case (you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() and see if that fixes that issue or not. This would be just another hack though, so a real patch would still be necessary as I decribed above. - Aric
