On Tuesday 17 February 2009 17:11:20 Martin Hinner wrote:
> Hi,
>
> I will start one more hot discussion. Sorry if it was discussed
> earlier, I am not regular reader of this mailing-list. I tried to
> search google, found several discussions, but no real result:
>
> http://www.linux.com/feature/
"Steven Edwards" wrote:
> Conversely maybe using windows.h usage should be fixed and used more
> often. Wine is an oddball when it comes to win32 program with the
> excessive lengths it goes to, to avoid using windows.h. I am starting
> to think even avoiding it internally like we do causes more
"Juan Lang" wrote:
> + hr = VarR8FromDec((DECIMAL *)pDecIn, &dbl);
According to PSDK VarR8FromDec() takes a const pointer to the 1st parameter,
to it should be fixed instead of casting const out.
Same for VarDecInt() patch.
--
Dmitry.
"Austin English" wrote:
> +/* create a temporary file */
> +uUnique = GetTempFileNameA(tempdir, "pfx", 0, source);
> +ok(uUnique != 0, "GetTempFileNameA error %d\n", GetLastError());
> +
> +/* get the same filename as above with upper case
> + prefix and without creating any
"Paul Bryan Roberts" wrote:
> I did reference the piclist web-page in the analysis I attached to bug
> 14334 but accept that no one is ever likely to read it.
The description of API parameters in your patch looks like directly copied
from that page, so you should either write it in your own wor
On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget wrote:
> ---
>
> I moved them after the windows.h include though in practice the needed
> winnt.h has already been included by the time we include winetest.h. So
> maybe windows.h should be nuked altogether...
Conversely maybe using windows.h usag
On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson wrote:
> On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
> > I had an interesting thought the other day, and that is to having some
> > built in support for forwarding windows dlls to linux .so's.
>
> IIRC, this kind of thing is generally
Am Dienstag, den 17.02.2009, 09:19 +0100 schrieb Michael Karcher:
> Should fix bug #17050
Doesn't do. Please ignore.
> The problems with this concept have already been discussed
> (such as calling conventions).
This is a problem for trying to expose a linux .so as a windows .dll,
as the interface is almost never identical. It's not a problem for a
program that is explicitly written to use a linux .so.
> I belie
2009/2/18 Marco Meijer :
> It is unfortunate that many discussions here on wine-devel to end this way.
> A new developer thinks he has solved a problem he has in wine, and wants to
> share the solution with the rest of the community.
> And 'the established' developers try to find as much issues th
2009/2/18 Martin Hinner :
> Hi,
>
> I will start one more hot discussion. Sorry if it was discussed
> earlier, I am not regular reader of this mailing-list. I tried to
> search google, found several discussions, but no real result:
It won't be very hot.
> http://www.linux.com/feature/42031
> htt
Dmitry Timoshkov wrote:
> "Paul Bryan Roberts" wrote:
>
>>> It appears that GetNamedSecurityInfoExA signature doesn't match
>>> the MSDN/PSDK one. Also it's a common practice to simultaneously
>>> add both A and W versions, and add prototypes to an appropriate
>>> .h file.
>>>
>> Ah, right you ar
> My biggest motivation for requiring weekly status updates is that in the past
> years I had a hard time following the GSoC projects I was not involved with
> directly. At WorldForge, we required weekly reports to the mentor at first
> and then decided that the weekly reports should go to the d
On Tue, 17 Feb 2009, James Mckenzie wrote:
[...]
> I think the phrase for this is 'dll hell'. That is Application A
> ships with and places a copy of xyz.dll in the program directory and
> uses it, exclusively.
No. Dll hell is when Application A 'upgrades' (replaces) a system dll
in c:\Window
On Tuesday 17 February 2009, Martin Hinner wrote:
> Hi,
>
> I will start one more hot discussion. Sorry if it was discussed
> earlier, I am not regular reader of this mailing-list. I tried to
> search google, found several discussions, but no real result:
>
> http://www.linux.com/feature/42031
>
On Tue, Feb 17, 2009 at 8:10 AM, Rosanne DiMesio wrote:
> I have both Office 2003 (which also installs the private dlls) and Office
> 2007 on my system. I regularly use Word, occasionally Powerpoint, and I can
> verify that it solves a number of other bugs besides the one Dan pointed to:
>
> htt
Hi,
I will start one more hot discussion. Sorry if it was discussed
earlier, I am not regular reader of this mailing-list. I tried to
search google, found several discussions, but no real result:
http://www.linux.com/feature/42031
http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-vir
>
> > See http://bugs.winehq.org/show_bug.cgi?id=14980
> >
> > Essentially, to run Office 2007, you have to set an override
> > for riched20. Since Office installs a new, spiffier version
> > of riched20 in its own private directory, and expects to
> > find it there, isn't it a bug that we don't
On Tue, Feb 17, 2009 at 3:56 PM, Dan Kegel wrote:
>> The above doesn't work ... LoadLibraryA fails (returns NULL).
>
> Aha, you're right. libwine is shipped as an .so, not as a .dll.so.
>
> But have a look at wine_dlopen and wine_dlsym,
> http://source.winehq.org/source/libs/wine/loader.c#L677
>
ok, written up as a specification -
http://lkcl.net/namedpipes/namedpipes-emulation.txt: please review and
provide feedback. kai, volker, you may wish to forward this to the
samba technical lists.
l.
On Tue, Feb 17, 2009 at 7:10 AM, Alexandre Julliard wrote:
>> Which version resources are you thinking of?
>
> The version of the native dll, compared to the builtin. I could imagine
> a heuristic where if the major version of native is higher than builtin
> you default to native or something like
On Tue, Feb 17, 2009 at 7:10 AM, Vincent Povirk
wrote:
> On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel wrote:
>> They really are very simple wrappers around Unix system
>> calls. There's no reason you can't write your own wrappers
>> in assembly inside your winegate, they would probably
>> only be
Dan Kegel writes:
> On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard
> wrote:
>> No. Find a better way.
>>
>> For instance, investigate the possibility of checking version
>> resources.
>
> Which version resources are you thinking of?
The version of the native dll, compared to the builtin.
On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel wrote:
> They really are very simple wrappers around Unix system
> calls. There's no reason you can't write your own wrappers
> in assembly inside your winegate, they would probably
> only be ten lines or so each.
According to the man page, dlopen() is
On Tue, Feb 17, 2009 at 6:47 AM, Alexandre Julliard wrote:
> No. Find a better way.
>
> For instance, investigate the possibility of checking version
> resources.
Which version resources are you thinking of?
On Tue, Feb 17, 2009 at 6:42 AM, Martin Hinner wrote:
>> hdll = LoadLibraryA("libwine.dll");
>> wine_dlopen = GetProcAdress(hdll, "wine_dlopen");
>> wine_dlsym = GetProcAdress(hdll, "wine_dlsym");
>> wine_dlclose = GetProcAdress(hdll, "wine_dlclose");
>
> The above doesn't work ... LoadLibraryA fa
Austin English wrote:
>Sent: Feb 17, 2009 7:27 AM
>To: Alexandre Julliard
>Cc: "wine-devel@winehq.org" , Dan Kegel
>Subject: Re: search path redux - if office 2007 always uses a private
>riched20, why does wine interpose its own global one?
>
>On Tue, Feb 17, 2009 at 6:07 AM, Alexandre Julliar
Dan Kegel writes:
> OK, but that leaves Office 2007 broken for the average user,
> which can't be good. A whitelist of apps for which specific
> private DLLs are needed would solve this particular case.
> That's a hack, and against winehq policy, but
> because of the overwhelming popularity of
On Tue, Feb 17, 2009 at 3:34 PM, Dan Kegel wrote:
> On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner wrote:
>> Just to add few comments at once, the problem is solved for us
>> (libwinegate.dll.so is shipped with the software, we'll have to
>> recompile it when libwine/libc changes...),
>
> Wait, w
On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner wrote:
> Just to add few comments at once, the problem is solved for us
> (libwinegate.dll.so is shipped with the software, we'll have to
> recompile it when libwine/libc changes...),
Wait, what can winegate do that
hdll = LoadLibraryA("libwine.dll"
On Tue, Feb 17, 2009 at 4:07 AM, Alexandre Julliard wrote:
>> Essentially, to run Office 2007, you have to set an override
>> for riched20. Since Office installs a new, spiffier version
>> of riched20 in its own private directory, and expects to
>> find it there, isn't it a bug that we don't let
Dan Kegel
>Sent: Feb 17, 2009 7:26 AM
>To: James Mckenzie
>Cc: Alexandre Julliard , "wine-devel@winehq.org"
>
>Subject: Re: search path redux - if office 2007 always uses a private
>riched20, why does wine interpose its own global one?
>
>On Tue, Feb 17, 2009 at 6:23 AM, James Mckenzie
> wrote
On Mon, 2009-02-16 at 00:16 +, Ricardo Filipe wrote:
>
>
> 2009/2/15 Stefan Dösinger
> Am Sonntag, 15. Februar 2009 23:03:27 schrieb Marcus Meissner:
> > Hi,
>
> > And my slides are here (feel free to reuse):
> >
> http://files.opensuse.org/op
André Hentschel wrote:
>
>
Changes the spacing of the entire file.
Also, if you are going to take this time, change indenting to two or four per
level.
James McKenzie
On Tue, Feb 17, 2009 at 6:07 AM, Alexandre Julliard wrote:
> Dan Kegel writes:
>
>> See http://bugs.winehq.org/show_bug.cgi?id=14980
>>
>> Essentially, to run Office 2007, you have to set an override
>> for riched20. Since Office installs a new, spiffier version
>> of riched20 in its own private
On Tue, Feb 17, 2009 at 6:23 AM, James Mckenzie
wrote:
> However, some programs will NOT function without their program specific
> dlls, and it appears that Office 2007 is one of them. Thus, it will be
> necessary to switch from built-in to native, built-in for this program until
> Wine incor
Alexandre Julliard wrote:
>Sent: Feb 17, 2009 5:07 AM
>To: Dan Kegel
>Cc: "wine-devel@winehq.org"
>Subject: Re: search path redux - if office 2007 always uses a private
>riched20,why does wine interpose its own global one?
>
>Dan Kegel writes:
>
>> See http://bugs.winehq.org/show_bug.c
Aric Stewart writes:
> +ptr = strchrW(ptr,';');
> +*ptr = 0;
> +ptr++;
> +while (*ptr == ' ') ptr++; /* whitespace */
> +/* FIXME use LOCALE_INVARIANT when implemented */
> +if (CompareStringW(MAKELCID(LANG_ENGLISH, SUBLANG_DEFAULT),
> +
Paul Bryan Roberts wrote:
>
>> You need to generate the patch from the top of the wine directory. You
>> also need to use your real name for copyright-tracking purposes.
>
>"copyright-tracking purposes"
>
That is a way of saying that we need, for legal reasons, to know the originator
of each and
Is a shame that a lot of discussions on wine-devel has to end like this.
A new people propose something that he things is the solution to a
problem he has in wine.
And all the 'established' developers try to find as much
It is unfortunate that many discussions here on wine-devel to end
2009/2/17 Vincent Povirk
>
>
> I'm curious what happens if you tell if you're looking for a file on
> C: that you know exists. If it doesn't bring up a dialog, that might
> allow you to create a few tests that succeed.
>
> Vincent Povirk
>
> i could do that, if i had implemented IDF_CHECKFIRST :p
2009/2/17 Alexandre Julliard
> Dan Kegel writes:
>
> > See http://bugs.winehq.org/show_bug.cgi?id=14980
> >
> > Essentially, to run Office 2007, you have to set an override
> > for riched20. Since Office installs a new, spiffier version
> > of riched20 in its own private directory, and expects
On Mon, Feb 16, 2009 at 12:14 PM, Francois Gouget wrote:
>> From what I understand, they're not accessible to full win32 apps.
>
> FWIW, it's kernel32.wine_get_unix_file_name(). So it's available to any
> Win32 application that knows about it. Just LoadLibrary()+GetProcAddress().
This is really n
Dan Kegel writes:
> See http://bugs.winehq.org/show_bug.cgi?id=14980
>
> Essentially, to run Office 2007, you have to set an override
> for riched20. Since Office installs a new, spiffier version
> of riched20 in its own private directory, and expects to
> find it there, isn't it a bug that we d
Hello Ricardo,
Ricardo Filipe wrote:
> i have took the endeavour of making my first dialog patch, managed to do it
> this weekend, to implement SetupPromptForDisk, which i stubbed but had some
> problems on the stub. gave me some big headaches to make this work x)
>
> so here is the patch, i've m
45 matches
Mail list logo
