Re: AppDB: Rating / Patching
On Wed, 7 Jan 2009 13:46:06 -0500 Sparr wrote: > I have not investigated the state of wine launchers in about a year > now. Do any of those handle multiple WINEPREFIXes? That is the most > important feature of Cedega's launcher that I was never able to find > in a wine launcher. Thank you and forgive me if things have improved. http://repo.or.cz/w/WineLauncher.git?a=shortlog
Re: New appdb checkbox: "officially supports wine"?
On Wed, 7 Jan 2009 07:52:46 -0800 "Dan Kegel" wrote: > http://wiki.winehq.org/AppsThatSupportWine is a nice > stopgap, but perhaps it should be a report in the > appdb, driven by a checkbox that maintainers can check. > What do folks think? You get my vote!
Re: Dates in Wine announcement
On Wed, 07 Jan 2009 12:33:21 +1100 Peter Urbanec wrote: > Speaking of dates... My pet peeve is seeing ambiguous dates such as > 2/1/08. To me (and most of the world), that looks like 2nd Jan 2008, but > it appears that millions of people in the USA see it as 1st Feb 2008. > So, in the interest of disambiguation, I'd like to see human readable > dates with the month either fully spelled out or using a three letter > abbreviation. Date formats that are intended to be parsed by machines > are best represented as 2008-01-23, so that they are collated correctly > when sorted by a simple lexicographical routine. > > Cheers. If we had the date please spell it out in full. Then we all are on the same page world over. Wednesday, 07 January 2009 Can you bring back the link to the newest version of wine. E.G. link http://www.winehq.org/?announce=latest to http://www.winehq.org/announce/1.1.12 This did work before the website had its make over.
Re: Proof the new site design is superior!
2009/1/8 Dan Kegel : > The new site design is already paying dividends. Look: > http://www.zmogo.com/gear/the-new-year-linux-resolution-day-5/ > says: > "... I chose Wine mainly because its site is more appealing looking > than VMware's, which has all the sleek design features and > well-considered organization of an expired domain name..." > > :-) > > > While I agree with you Dan that its nice that he commends the site (which is rather nice) I think there is another big takeaway here. I think the experience that is documented here is probably rather typical. Some success with annoying bugs and some utter failure. I'm pretty certain with a bit of effort and tweaking his applications could run nigh flawlessly. I dream of a day when it just works out of the box. Perhaps we should write to the author and have him try crossover on day 6? :)
Proof the new site design is superior!
The new site design is already paying dividends. Look: http://www.zmogo.com/gear/the-new-year-linux-resolution-day-5/ says: "... I chose Wine mainly because its site is more appealing looking than VMware's, which has all the sleek design features and well-considered organization of an expired domain name..." :-)
Re: Implementing b3DAccelerationExists and b3DAccelerationEnabled in dxdiagn
On Wednesday 07 January 2009 06:55:12 Detlef Riekenberg wrote: > > This value should > > return true if e.g. hardware accelerated T&L is available on the system, > > which is primarily a result of driver and hardware capabilities. > > This is for b3DAccelerationExists and native dxdiagn in Wine with some > d3d* debug channels might help a bit. What I have found so far is that the native dxdiagn.dll retrieves the device capabilities using IDirect3D9Impl_GetDeviceCaps. However, I was unable to find any values for the caps struct, where the native dll would determine that b3DAccelerationExists was supposed to be false. The only result I got in that regard was that by setting caps->DevCaps to 0, a human readable warning about missing D3d9+ hardware acceleration would be added to szNotesLocalized. Does anyone have an idea on what else could be the basis for this flag? -- Markus
Re: mshtml: Implement IHTMLStyle get/set Attribute
Hi,
Is there anything wrong with this patch?
Best Regards
Alistair Leslie-Hughes
> From dca7b396838e3367ad78144ccb07aed24cd5917f Mon Sep 17 00:00:00 2001
> From: Alistair Leslie-Hughes
> Date: Mon, 5 Jan 2009 21:22:35 +1100
> Subject: [PATCH] Implement IHTMLStyle get/set Attribute
> To: wine-patches
>
> ---
> dlls/mshtml/htmlstyle.c | 69
> ++
> dlls/mshtml/tests/dom.c | 36
> 2 files changed, 99 insertions(+), 6 deletions(-)
>
> diff --git a/dlls/mshtml/htmlstyle.c b/dlls/mshtml/htmlstyle.c
> index fa4ad51..3453f7b 100644
> --- a/dlls/mshtml/htmlstyle.c
> +++ b/dlls/mshtml/htmlstyle.c
> @@ -2048,18 +2048,75 @@ static HRESULT WINAPI
> HTMLStyle_setAttribute(IHTMLStyle *iface, BSTR strAttribut
> VARIANT AttributeValue, LONG lFlags)
> {
> HTMLStyle *This = HTMLSTYLE_THIS(iface);
> -FIXME("(%p)->(%s v%d %08x)\n", This, debugstr_w(strAttributeName),
> - V_VT(&AttributeValue), lFlags);
> -return E_NOTIMPL;
> +HRESULT hres;
> +DISPID dispid;
> +
> +TRACE("(%p)->(%s v%d %08x)\n", This, debugstr_w(strAttributeName),
> + V_VT(&AttributeValue), lFlags);
> +
> +if(!strAttributeName)
> +return E_INVALIDARG;
> +
> +if(lFlags == 1)
> +FIXME("Parameter lFlags ignored\n");
> +
> +hres = HTMLStyle_GetIDsOfNames(iface, &IID_NULL,
> (LPOLESTR*)&strAttributeName, 1,
> +LOCALE_USER_DEFAULT, &dispid);
> +if(hres == S_OK)
> +{
> +VARIANT ret;
> +DISPID dispidNamed = DISPID_PROPERTYPUT;
> +DISPPARAMS params;
> +
> +params.cArgs = 1;
> +params.rgvarg = &AttributeValue;
> +params.cNamedArgs = 1;
> +params.rgdispidNamedArgs = &dispidNamed;
> +
> +hres = HTMLStyle_Invoke(iface, dispid, &IID_NULL,
> LOCALE_SYSTEM_DEFAULT,
> +DISPATCH_PROPERTYPUT, ¶ms, &ret, NULL, NULL);
> +}
> +else
> +{
> +FIXME("Custom attributes not supported.\n");
> +}
> +
> +TRACE("ret: %08x\n", hres);
> +
> +return hres;
> }
>
> static HRESULT WINAPI HTMLStyle_getAttribute(IHTMLStyle *iface, BSTR
> strAttributeName,
> LONG lFlags, VARIANT *AttributeValue)
> {
> HTMLStyle *This = HTMLSTYLE_THIS(iface);
> -FIXME("(%p)->(%s %08x %p)\n", This, debugstr_w(strAttributeName),
> - lFlags, AttributeValue);
> -return E_NOTIMPL;
> +HRESULT hres;
> +DISPID dispid;
> +
> +TRACE("(%p)->(%s v%p %08x)\n", This, debugstr_w(strAttributeName),
> + AttributeValue, lFlags);
> +
> +if(!AttributeValue || !strAttributeName)
> +return E_INVALIDARG;
> +
> +if(lFlags == 1)
> +FIXME("Parameter lFlags ignored\n");
> +
> +hres = HTMLStyle_GetIDsOfNames(iface, &IID_NULL,
> (LPOLESTR*)&strAttributeName, 1,
> +LOCALE_USER_DEFAULT, &dispid);
> +if(hres == S_OK)
> +{
> +DISPPARAMS params = {NULL, NULL, 0, 0 };
> +
> +hres = HTMLStyle_Invoke(iface, dispid, &IID_NULL,
> LOCALE_SYSTEM_DEFAULT,
> +DISPATCH_PROPERTYGET, ¶ms, AttributeValue, NULL, NULL);
> +}
> +else
> +{
> +FIXME("Custom attributes not supported.\n");
> +}
> +
> +return hres;
> }
>
> static HRESULT WINAPI HTMLStyle_removeAttribute(IHTMLStyle *iface, BSTR
> strAttributeName,
> diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c
> index de363bb..516aa3e 100644
> --- a/dlls/mshtml/tests/dom.c
> +++ b/dlls/mshtml/tests/dom.c
> @@ -2745,6 +2745,42 @@ static void test_default_style(IHTMLStyle *style)
> ok(hres == S_OK, "put_overflow failed: %08x\n", hres);
> SysFreeString(sOverflowDefault);
>
> +/* Attribute Tests*/
> +hres = IHTMLStyle_getAttribute(style, NULL, 1, &v);
> +ok(hres == E_INVALIDARG, "getAttribute failed: %08x\n", hres);
> +
> +str = a2bstr("position");
> +hres = IHTMLStyle_getAttribute(style, str, 1, NULL);
> +ok(hres == E_INVALIDARG, "getAttribute failed: %08x\n", hres);
> +
> +hres = IHTMLStyle_getAttribute(style, str, 1, &v);
> +ok(hres == S_OK, "getAttribute failed: %08x\n", hres);
> +ok(V_VT(&v) == VT_BSTR, "type failed: %d\n", V_VT(&v));
> +VariantClear(&v);
> +
> +hres = IHTMLStyle_setAttribute(style, NULL, v, 1);
> +ok(hres == E_INVALIDARG, "getAttribute failed: %08x\n", hres);
> +
> +V_VT(&v) = VT_BSTR;
> +V_BSTR(&v) = a2bstr("absolute");
> +hres = IHTMLStyle_setAttribute(style, str, v, 1);
> +ok(hres == S_OK, "setAttribute failed: %08x\n", hres);
> +VariantClear(&v);
> +
> +hres = IHTMLStyle_getAttribute(style, str, 1, &v);
> +ok(hres == S_OK, "getAttribute failed: %08x\n", hres);
> +ok(V_VT(&v) == VT_BSTR, "type failed: %d\n", V_VT(&v));
> +ok(!strcmp_wa(V_BSTR(&v), "absolute"), "str=%s\n",
> dbgstr_w(V_BSTR(&v)));
> +VariantClear(&v);
> +
> +V_VT(&v) = VT_BSTR;
> +V_BSTR(&v) = NULL;
> +hres = IHTMLStyle_setAttribute(style, str, v, 1)
Re: Unused function in quartz
Hello Francois, Rob Shearman schreef: > 2009/1/6 Francois Gouget : > >> In the following commit you added the OutputPin_DeliverNewSegment() >> function to pin.c. However today it is unused. Is there any plan to use >> it? Is it still relevant? >> > > Not, it looks like it has been superseded by InputPin_NewSegment. If > Maarten agrees, then feel free to send a patch to remove it. > Even my win32 compatible dirac codec is not using it, so feel free to remove it :) Cheers, Maarten.
Re: compiling python2.5 on linux under wine
On Sat, Jan 3, 2009 at 9:22 PM, Luke Kenneth Casson Leighton
wrote:
> hey, has anyone investigated compiling python2.5 using winegcc, under wine?
some people might find this kind of thing amusing. it's considered in
very obtuse circles to be "progress"... :)
l...@gonzalez:/mnt/src/python2.5-2.5.2/Lib$ ../build/python -v
Could not find platform independent libraries
Could not find platform dependent libraries
Consider setting $PYTHONHOME to [:]
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
'import site' failed; traceback:
ImportError: No module named site
Python 2.5.2 (r252:60911, Jan 7 2009, 20:33:53) [gcc] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
[]
[]
[]
import sre_compile # from Z:\mnt\src\python2.5-2.5.2\Lib\sre_compile.py
fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
# wrote Z:\mnt\src\python2.5-2.5.2\Lib\sre_compile.pyc
import _sre # builtin
import sre_constants # from Z:\mnt\src\python2.5-2.5.2\Lib\sre_constants.py
# wrote Z:\mnt\src\python2.5-2.5.2\Lib\sre_constants.pyc
import sre_parse # from Z:\mnt\src\python2.5-2.5.2\Lib\sre_parse.py
# wrote Z:\mnt\src\python2.5-2.5.2\Lib\sre_parse.pyc
Traceback (most recent call last):
File "", line 1, in
File "site.py", line 415, in
main()
File "site.py", line 406, in main
aliasmbcs()
File "site.py", line 356, in aliasmbcs
import locale, codecs
File "Z:\mnt\src\python2.5-2.5.2\Lib\locale.py", line 167, in
import re, operator
File "Z:\mnt\src\python2.5-2.5.2\Lib\re.py", line 223, in
_pattern_type = type(sre_compile.compile("", 0))
File "Z:\mnt\src\python2.5-2.5.2\Lib\sre_compile.py", line 530, in compile
groupindex, indexgroup
OverflowError: signed integer is less than minimum
>>>
Re: AppDB: Rating / Patching
On Wed, Jan 7, 2009 at 12:46 PM, Sparr wrote: > On Wed, Jan 7, 2009 at 8:47 AM, Zachary Goldberg wrote: >> 2009/1/7 Sparr : >>> Re-compiling wine with patches is an extremely farfetched idea when no >>> one outside Cedega has ever tackled the far simpler tasks involved >>> with making a wine launcher. >> This statement is very untrue. >> http://wiki.winehq.org/ThirdPartyApplications > > I have not investigated the state of wine launchers in about a year > now. Do any of those handle multiple WINEPREFIXes? That is the most > important feature of Cedega's launcher that I was never able to find > in a wine launcher. Thank you and forgive me if things have improved. > > > Crossover/Bordeaux/PlayonLinux do. The others, I've never heard of. -- -Austin
Re: AppDB: Rating / Patching
On Wed, Jan 7, 2009 at 8:47 AM, Zachary Goldberg wrote: > 2009/1/7 Sparr : >> Re-compiling wine with patches is an extremely farfetched idea when no >> one outside Cedega has ever tackled the far simpler tasks involved >> with making a wine launcher. > This statement is very untrue. > http://wiki.winehq.org/ThirdPartyApplications I have not investigated the state of wine launchers in about a year now. Do any of those handle multiple WINEPREFIXes? That is the most important feature of Cedega's launcher that I was never able to find in a wine launcher. Thank you and forgive me if things have improved.
Re: New appdb checkbox: "officially supports wine"?
On Wed, 7 Jan 2009 07:52:46 -0800 "Dan Kegel" wrote: > http://wiki.winehq.org/AppsThatSupportWine is a nice > stopgap, but perhaps it should be a report in the > appdb, driven by a checkbox that maintainers can check. > What do folks think? > > Sounds good to me. -- Rosanne DiMesio
Re: winequartz.drv Mac OS X UI discontinued?
Le 3 janv. 09 à 04:14, James McKenzie a écrit : > Emmanuel Maillard wrote: >> Hi, >> >> Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit : >> >> >>> Hi Emmanuel, hello Wine developers, >>> >>> Latest WineQuartz.drv patch is 0.9.58. Is there any change for >>> more recent release? I tried this patch with 1.0-1 however it has >>> too many conflicts. >>> It would be most convenient if you had just update >>> http://repo.or.cz/w/wine/winequartzdrv.git >>> to match 1.1.0 somehow and include Quartz. >>> >> >> I resolved conflicts for wine-1.0, but didn't take a look yet for >> wine-1.1.0, i just know that's some changes in user32 and winex11.drv >> have to be update in winequartz.drv too. >> >> I will see this week end if i can find free time to make a new >> patch for winequartz.drv and send it to SourceForge. >> (OpenGL is broken in winequartz.drv actually, because of a lack of >> time to fix it) >> >> >> >>> Since Wine passed 1.0 (woohoo!) maybe someone from the direction >>> can revise Mac support? Even there're numerous Emmanuel efforts >>> to provide Mac UI driver instead of X11, it will be always >>> pushed aside, and sentenced to death, because it is not in >>> official sources. >>> >>> I know Alexandre Julliard's decision about NOT taking any >>> Objective- C sources (.m) into the Wine, but maybe this can be >>> revised, anyway all .m rules will be only present on Mac >>> platforms. Using Objective- C is only way to make fair support for >>> Mac OS GUI, as those whole GUI system is objective. >>> Moreover then what's the point of keeping winex11.drv and all GUI >>> driver infrastructure in Wine if nothing else but X11 is NOT >>> accepted into official source? >>> >>> Forgive me what I say now, but I just it would be more fair if >>> someone from Codeweavers just said that Wine's official support >>> for Mac OS X is against their business with CrossOver and this is >>> the real reason they reject winequartz.drv from Emmanuel Maillard. >>> Frankly I'd really pay for CrossOver or Wine, if it was what >>> 1.0-1 is but with native Mac UI, so each wine process has it's >>> own dock icon, and no X11 is needed and native Mac font system. >>> >>> Regards, >>> -- >>> Adam Strzelecki |: nanoant.com :| >>> >>> >> >> >> Cheers >> Emmanuel >> >> > Emmanuel: > > What is the status of winequartz.drv? It looks like your last patch > was for 1.1.2. > > James McKenzie > Hi, I didn't really work on winequartz.drv since this patch, start a new version at the beginning of October, but more or less waiting for DIB engine. Emmanuel
Re: New appdb checkbox: "officially supports wine"?
On Wed, Jan 7, 2009 at 9:52 AM, Dan Kegel wrote: > http://wiki.winehq.org/AppsThatSupportWine is a nice > stopgap, but perhaps it should be a report in the > appdb, driven by a checkbox that maintainers can check. > What do folks think? > > > +1 -- -Austin
Re: WIDL and Windows rpcrt4
Am Mittwoch, den 07.01.2009, 16:03 + schrieb Rob Shearman: > > So it appears Windows RPCRT4.dll is not happy with FC_ULONG entries within a > > complex structure. I added a bunch of other primitive types to my complex_t > > structure to see how they are treated by MIDL. See attached complex.idl file > > and the MIDL-generated midl_complex_c.c file (also attached WIDL-generated > > widl_complex_c.c for completeness). It appears that MIDL simply drops the > > "unsigned" from any base type, at least within complex structures. "unsigned > > long" gets encoded as FC_LONG, "unsigned short" as FC_SHORT and "unsigned > > small" as FC_SMALL. > > > > Like I said, I'm no IDL expert. Does the stuff above make sense to you? Do > > you think it would be a good idea to change WIDL to generate the same > > encodings as MIDL? > > Yes, and in fact Michael Karcher has already sent in a pair of patches > to do this: > http://www.winehq.org/pipermail/wine-patches/2009-January/067032.html > http://www.winehq.org/pipermail/wine-patches/2009-January/067031.html > > However, they probably won't apply cleanly after my recent changes. > Michael, do you plan to rebase and resend these? If not, I can do > this. I will rebase them today in the evening (and send them in). I hope Alexandre doesn't put me back in the queue because some of my last patches were a bit quick-shot and flawed. I really believe that these two are not doing any colleteral damage. Regards, Michael Karcher
Re: WIDL and Windows rpcrt4
2009/1/7 Ge van Geldorp :
> Hi Rob,
>
> Is WIDL supposed to generate code that's compatible with Windows RPCRT4.DLL?
> Because it appears this is currently not the case. When you look at
> http://test.winehq.org you'll see that the rpcrt4:server test fails on
> pretty much any Windows version.
>
> I investigated a bit more, the failures are caused by an exception 0x6e6
> ("An internal error occurred in a remote procedure call (RPC)" thrown from
> NdrPointerBufferSize() in server_c.c function get_name(). The
> mingw-crosscompiled executable doesn't handle that exception which causes
> the process to crash. Since this is in WIDL-generated code, I decided to
> take a look at what MIDL generates for the same IDL file.
>
> It turns out that MIDL treats the name_t struct as a simple structure, while
> WIDL treats it as a complex structure. That made comparison a bit difficult.
> Since WIDL never seems to generate simple structures, I tried to convince
> MIDL to generate a complex structure too. After a bit of fiddling around
> (I'm no IDL expert...) I came up with the following type, a mix of name_t
> and sun_t:
>
> typedef struct
> {
> [string, size_is(size)] char *name;
> unsigned int size;
>
> [switch_is(s)] union
> {
>[case(SUN_I)] int i;
>[case(SUN_F1, SUN_F2)] float f;
>[case(SUN_PI)] int *pi;
> } u;
>
> int s;
> } complex_t;
>
> After staring at the WIDL-generated and MIDL-generated code for a while
> (which still differed quite a bit), I noticed something interesting: in the
> type format string, "unsigned int size" gets encoded as FC_ULONG by WIDL,
> but as FC_LONG by MIDL. I then went back to the server_c.c and server_s.c
> files generated by WIDL for the tests and changed the type format strings
> there (replaced the "unsigned int size" encoding from FC_ULONG by FC_LONG).
> With this change, the get_name() test passes :-). It then crashes later on
> with an access violation inside NdrVaryingArrayUnmarshall() in
> get_5numbers(), but let's take the problems one at a time...
>
> So it appears Windows RPCRT4.dll is not happy with FC_ULONG entries within a
> complex structure. I added a bunch of other primitive types to my complex_t
> structure to see how they are treated by MIDL. See attached complex.idl file
> and the MIDL-generated midl_complex_c.c file (also attached WIDL-generated
> widl_complex_c.c for completeness). It appears that MIDL simply drops the
> "unsigned" from any base type, at least within complex structures. "unsigned
> long" gets encoded as FC_LONG, "unsigned short" as FC_SHORT and "unsigned
> small" as FC_SMALL.
>
> Like I said, I'm no IDL expert. Does the stuff above make sense to you? Do
> you think it would be a good idea to change WIDL to generate the same
> encodings as MIDL?
Yes, and in fact Michael Karcher has already sent in a pair of patches
to do this:
http://www.winehq.org/pipermail/wine-patches/2009-January/067032.html
http://www.winehq.org/pipermail/wine-patches/2009-January/067031.html
However, they probably won't apply cleanly after my recent changes.
Michael, do you plan to rebase and resend these? If not, I can do
this.
--
Rob Shearman
New appdb checkbox: "officially supports wine"?
http://wiki.winehq.org/AppsThatSupportWine is a nice stopgap, but perhaps it should be a report in the appdb, driven by a checkbox that maintainers can check. What do folks think?
Re: readme: add a note about UNIX paths
On Wed, Jan 7, 2009 at 7:31 AM, Alexandre Julliard wrote: > Vitaliy Margolen writes: > >> Alexandre Julliard wrote: >>> The problem is not Unix paths, it's usually that the app expects the >>> current directory to be the app directory. You have the same issue if >>> you use a Windows path. If there are really issues caused by argv[0] >>> being a Unix path and not just the wrong directory that can be fixed. >>> >> For years Borland been stating in their documents that argv[0] always >> contains full path to the executable. And many programs written in Boarland >> C++ / Delphi relay on that. > > Their documents are wrong since argv[0] is determined by the parent > process. Anyway, do you have a specific bug report for this? > > -- > Alexandre Julliard > julli...@winehq.org > I'll have to look around for some. I doubt it was an UNIX path issue, but rather 'current directory != app directory', which shows up pretty often in the forums. Would you rather a note saying something like: + Note: This method is not recommended, since many Win32 applications + depend on the current directory being the application directory, and may + crash or have other buggy behavior otherwise. -- -Austin
WIDL and Windows rpcrt4
Hi Rob,
Is WIDL supposed to generate code that's compatible with Windows RPCRT4.DLL?
Because it appears this is currently not the case. When you look at
http://test.winehq.org you'll see that the rpcrt4:server test fails on
pretty much any Windows version.
I investigated a bit more, the failures are caused by an exception 0x6e6
("An internal error occurred in a remote procedure call (RPC)" thrown from
NdrPointerBufferSize() in server_c.c function get_name(). The
mingw-crosscompiled executable doesn't handle that exception which causes
the process to crash. Since this is in WIDL-generated code, I decided to
take a look at what MIDL generates for the same IDL file.
It turns out that MIDL treats the name_t struct as a simple structure, while
WIDL treats it as a complex structure. That made comparison a bit difficult.
Since WIDL never seems to generate simple structures, I tried to convince
MIDL to generate a complex structure too. After a bit of fiddling around
(I'm no IDL expert...) I came up with the following type, a mix of name_t
and sun_t:
typedef struct
{
[string, size_is(size)] char *name;
unsigned int size;
[switch_is(s)] union
{
[case(SUN_I)] int i;
[case(SUN_F1, SUN_F2)] float f;
[case(SUN_PI)] int *pi;
} u;
int s;
} complex_t;
After staring at the WIDL-generated and MIDL-generated code for a while
(which still differed quite a bit), I noticed something interesting: in the
type format string, "unsigned int size" gets encoded as FC_ULONG by WIDL,
but as FC_LONG by MIDL. I then went back to the server_c.c and server_s.c
files generated by WIDL for the tests and changed the type format strings
there (replaced the "unsigned int size" encoding from FC_ULONG by FC_LONG).
With this change, the get_name() test passes :-). It then crashes later on
with an access violation inside NdrVaryingArrayUnmarshall() in
get_5numbers(), but let's take the problems one at a time...
So it appears Windows RPCRT4.dll is not happy with FC_ULONG entries within a
complex structure. I added a bunch of other primitive types to my complex_t
structure to see how they are treated by MIDL. See attached complex.idl file
and the MIDL-generated midl_complex_c.c file (also attached WIDL-generated
widl_complex_c.c for completeness). It appears that MIDL simply drops the
"unsigned" from any base type, at least within complex structures. "unsigned
long" gets encoded as FC_LONG, "unsigned short" as FC_SHORT and "unsigned
small" as FC_SMALL.
Like I said, I'm no IDL expert. Does the stuff above make sense to you? Do
you think it would be a good idea to change WIDL to generate the same
encodings as MIDL?
Thanks, Gé.
/*** Autogenerated by WIDL 1.1.12 from complex.idl - Do not edit ***/
#include
#ifdef _ALPHA_
#include
#endif
#include "complex.h"
#ifndef DECLSPEC_HIDDEN
#define DECLSPEC_HIDDEN
#endif
#ifndef USE_COMPILER_EXCEPTIONS
#include "wine/exception.h"
#undef RpcTryExcept
#undef RpcExcept
#undef RpcEndExcept
#undef RpcTryFinally
#undef RpcFinally
#undef RpcEndFinally
#undef RpcExceptionCode
#undef RpcAbnormalTermination
struct __exception_frame;
typedef int (*__filter_func)(EXCEPTION_RECORD *, struct __exception_frame *);
typedef void (*__finally_func)(struct __exception_frame *);
#define __DECL_EXCEPTION_FRAME \
EXCEPTION_REGISTRATION_RECORD frame; \
__filter_func filter; \
__finally_funcfinally; \
sigjmp_bufjmp; \
DWORD code; \
unsigned char abnormal_termination; \
unsigned char filter_level; \
unsigned char finally_level;
struct __exception_frame
{
__DECL_EXCEPTION_FRAME
};
static DWORD __widl_exception_handler( EXCEPTION_RECORD *record,
EXCEPTION_REGISTRATION_RECORD *frame,
CONTEXT *context,
EXCEPTION_REGISTRATION_RECORD
**pdispatcher )
{
struct __exception_frame *exc_frame = (struct __exception_frame *)frame;
if (record->ExceptionFlags & (EH_UNWINDING | EH_EXIT_UNWIND |
EH_NESTED_CALL))
{
if (exc_frame->finally_level && (record->ExceptionFlags & (EH_UNWINDING
| EH_EXIT_UNWIND)))
{
exc_frame->abnormal_termination = 1;
exc_frame->finally( exc_frame );
}
return ExceptionContinueSearch;
}
exc_frame->code = record->ExceptionCode;
if (exc_frame->filter_level && exc_frame->filter( record, exc_frame ) ==
EXCEPTION_EXECUTE_HANDLER)
{
__wine_rtl_unwind( frame, record );
if (exc_frame->finally_level > exc_frame->filter_level)
{
exc_frame->abnormal_termination = 1;
exc_frame->finally( exc_frame );
__wine_pop_frame( frame );
}
exc_frame->filter_level = 0;
siglongjmp( exc_frame->jmp, 1 );
}
return ExceptionContinueSearch;
}
#define RpcTryExcept \
if
Re: AppDB: Rating / Patching
On Wed, Jan 7, 2009 at 3:47 AM, Chris Howe wrote: > Forgive me for bringing this up again, but could this be another > argument for some kind of WineTricks-like Wine application launcher > that would exist as a separate project to Wine, but would apply patches, > particular settings, &c in order to get particular applications to work > better with the current latest version of Wine? > > Users would presumably be happy because they download Wine, download > the launcher, and have great user experience "out of the box" with less > complication. > > Devs would also presumably be happy as: > - they would be able to use it as a source of inspiration for ongoing work > - it makes concerns like this moot when it comes to appdb > > Might even be a good way of gently reminding users when new versions of > Wine are released... > > -- > Chris > > > > You're free to do that if you'd like, but I don't see how that would help. The effort is better spent getting those patches put into Wine itself. -- -Austin
Re: AppDB: Rating / Patching
Sparr wrote: >On Wed, Jan 7, 2009 at 4:47 AM, Chris Howe wrote: >> argument for some kind of WineTricks-like Wine application launcher >> that would exist as a separate project to Wine, but would apply patches, > >Re-compiling wine with patches is an extremely farfetched idea when no >one outside Cedega has ever tackled the far simpler tasks involved >with making a wine launcher. > I take offesense to that comment. Darwine does have a wine launcher and it does work. James McKenzie
Re: AppDB: Rating / Patching
Sparr wrote: >On Wed, Jan 7, 2009 at 4:47 AM, Chris Howe wrote: >> argument for some kind of WineTricks-like Wine application launcher >> that would exist as a separate project to Wine, but would apply patches, > >Re-compiling wine with patches is an extremely farfetched idea when no >one outside Cedega has ever tackled the far simpler tasks involved >with making a wine launcher. > I take offesense to that comment. Darwine does have a wine launcher and it does work. James McKenzie
Re: AppDB: Rating / Patching
2009/1/7 Sparr : > Re-compiling wine with patches is an extremely farfetched idea when no > one outside Cedega has ever tackled the far simpler tasks involved > with making a wine launcher. This statement is very untrue. http://wiki.winehq.org/ThirdPartyApplications
Re: readme: add a note about UNIX paths
Alexandre Julliard wrote: > "Austin English" writes: > >> On Tue, Jan 6, 2009 at 9:07 PM, James Hawkins wrote: >>> On Tue, Jan 6, 2009 at 7:04 PM, Austin English >>> wrote: Adds a note discouraging use of UNIX paths, since there's seems to have been a rash of it in recent bug reports. >>> If we don't recommend it, and usually advise against it, why not just >>> remove that line from the README? >> I sent a patch for that a while back, and it was not accepted. I'm >> assuming Alexandre wants to keep it for some reason... > > The problem is not Unix paths, it's usually that the app expects the > current directory to be the app directory. You have the same issue if > you use a Windows path. If there are really issues caused by argv[0] > being a Unix path and not just the wrong directory that can be fixed. > For years Borland been stating in their documents that argv[0] always contains full path to the executable. And many programs written in Boarland C++ / Delphi relay on that. Vitaliy.
Re: readme: add a note about UNIX paths
Vitaliy Margolen writes: > Alexandre Julliard wrote: >> The problem is not Unix paths, it's usually that the app expects the >> current directory to be the app directory. You have the same issue if >> you use a Windows path. If there are really issues caused by argv[0] >> being a Unix path and not just the wrong directory that can be fixed. >> > For years Borland been stating in their documents that argv[0] always > contains full path to the executable. And many programs written in Boarland > C++ / Delphi relay on that. Their documents are wrong since argv[0] is determined by the parent process. Anyway, do you have a specific bug report for this? -- Alexandre Julliard julli...@winehq.org
Re: Implementing b3DAccelerationExists and b3DAccelerationEnabled in dxdiagn
On Di, 2009-01-06 at 22:47 -0500, Markus wrote: > > > can anyone tell me where to find information about the > > > b3DAccelerationExists and b3DAccelerationEnabled properties in the > > > display container returned by > > > > I suggest to use dxdiag and regmon on Windows. > > In dxdiag, you can disable DirectDraw / Direct3D Acceleration. > > Regmon will tell you, where the settings are saved. > > I do not think the registry is the correct place to look. For sure, the settings for enable/disable Acceleration must be in the registry. This is for b3DAccelerationEnabled and the primary requirement for that flag is a TRUE in b3DAccelerationExists > This value should > return true if e.g. hardware accelerated T&L is available on the system, > which > is primarily a result of driver and hardware capabilities. This is for b3DAccelerationExists and native dxdiagn in Wine with some d3d* debug channels might help a bit. I have an ATI Radeon 7500 Mobility (R100) here for testing. W98 with DDraw/D3D support (old driver) W2K without DDraw/D3D support (i use a new driver, that droped DirectX support for R100) Using regedit on W98: HKLM\Software\Microsoft\Direct3D\Drivers SoftwareOnly DWORD 1 HKLM\Software\Microsoft\DirectDraw EmulationOnly DWORD 1 When DDraw is set to EmulationOnly, D3D is marked (in dxdiag) as "not available" (d3d needs ddraw on Windows), independent of SoftwareOnly. (Using the GUI to set EmulationOnly to 1 also sets SoftwareOnly to 1) -- By by ... Detlef
Re: AppDB: Rating / Patching
On Wed, Jan 7, 2009 at 4:47 AM, Chris Howe wrote: > argument for some kind of WineTricks-like Wine application launcher > that would exist as a separate project to Wine, but would apply patches, Re-compiling wine with patches is an extremely farfetched idea when no one outside Cedega has ever tackled the far simpler tasks involved with making a wine launcher.
Re: why are we not using pkg-config in configure
Danny Rawlins writes: > I would like to know if there is any issues as to why we are not using > pkg-config to check for needed library's with the m4 macros. We use it in a few places where we have no choice, but in general it's doing more harm than good. The whole concept is broken. -- Alexandre Julliard julli...@winehq.org
Re: readme: add a note about UNIX paths
"Austin English" writes: > On Tue, Jan 6, 2009 at 9:07 PM, James Hawkins wrote: >> On Tue, Jan 6, 2009 at 7:04 PM, Austin English >> wrote: >>> Adds a note discouraging use of UNIX paths, since there's seems to >>> have been a rash of it in recent bug reports. >> >> If we don't recommend it, and usually advise against it, why not just >> remove that line from the README? > > I sent a patch for that a while back, and it was not accepted. I'm > assuming Alexandre wants to keep it for some reason... The problem is not Unix paths, it's usually that the app expects the current directory to be the app directory. You have the same issue if you use a Windows path. If there are really issues caused by argv[0] being a Unix path and not just the wrong directory that can be fixed. -- Alexandre Julliard julli...@winehq.org
Re: AppDB: Rating / Patching
Forgive me for bringing this up again, but could this be another argument for some kind of WineTricks-like Wine application launcher that would exist as a separate project to Wine, but would apply patches, particular settings, &c in order to get particular applications to work better with the current latest version of Wine? Users would presumably be happy because they download Wine, download the launcher, and have great user experience "out of the box" with less complication. Devs would also presumably be happy as: - they would be able to use it as a source of inspiration for ongoing work - it makes concerns like this moot when it comes to appdb Might even be a good way of gently reminding users when new versions of Wine are released... -- Chris
Re: [PATCH 1/2] Add definitions used by reparse points
On Wed, Jan 07, 2009 at 08:58:47AM +0100, Paul Vriens wrote: > Paul TBBle Hampson wrote: >> Not much to say about this. It's needed for the unit tests coming up. > Hi Paul, > Part of your signature says: > License: http://creativecommons.org/licenses/by/2.5/au/ > Does this mean your patches come under this license (or is it just the > signature > ;))? Anything in the email that isn't otherwise licensed, I'd think. However, I should hook in my other (shorter) signature for wine-patches. Conveniently, I'm already resending these two patches. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpceu07n3ayY.pgp Description: PGP signature
