Luke Kenneth Casson Leighton wrote:
On Tue, Jan 18, 2005 at 03:34:22PM -0600, Robert Shearman wrote:
Luke Kenneth Casson Leighton wrote:
On Tue, Jan 18, 2005 at 01:51:34PM -0600, Robert Shearman wrote:
so - the DCOM code is in the ole32 directory, yes?
Pretty much. We don't really ha
Joachim von Thadden wrote:
Since the first release one December 20, 2004 there have been more than
20.000 downloads. So I think there are many people interested in running
Windows apps in Wine, but so many don't know how to do it. And yes,
there are many who can not follow a HowTo or get proper re
Bill Medland wrote:
On January 18, 2005 02:04 pm, Robert Shearman wrote:
I have also fixed (kinda) the issue Bill
Medland was reporting where doing a CreateInstance for an IUnknown
interface was a bit messed up (this is bad programming anyway as it
doubles the number of RPC calls required).
On January 18, 2005 03:00 pm, Huw D M Davies wrote:
> On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
> > (Huw?)
> >
> > Do I need to dig deeper to understand this or is there a defect in the
> > logic. If there are ttf fonts available does that mean a poor ttf match
> > will be selec
On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
> (Huw?)
>
> Do I need to dig deeper to understand this or is there a defect in the logic.
> If there are ttf fonts available does that mean a poor ttf match will be
> selected even when a better x11drv font is available?
Yes that's r
Joris Huizer wrote:
>That line can be removed as
>nFileOp = *(lpFileOp)
>on the first line - the variable is never changed after that (yeah, if
>we really like, we could get rid of it)
>I hadn't removed it just like that, yet - but as it is useless, it can
>be removed.
I wouldn't do that! This
On January 18, 2005 02:04 pm, Robert Shearman wrote:
> Hi,
>
> I have also fixed (kinda) the issue Bill
> Medland was reporting where doing a CreateInstance for an IUnknown
> interface was a bit messed up (this is bad programming anyway as it
> doubles the number of RPC calls required).
Maybe. (
On Tue, Jan 18, 2005 at 03:34:22PM -0600, Robert Shearman wrote:
> Luke Kenneth Casson Leighton wrote:
>
> >On Tue, Jan 18, 2005 at 01:51:34PM -0600, Robert Shearman wrote:
> >
> >
> >so - the DCOM code is in the ole32 directory, yes?
> >
> >
>
> Pretty much. We don't really have any code using
Luke Kenneth Casson Leighton wrote:
On Tue, Jan 18, 2005 at 01:51:34PM -0600, Robert Shearman wrote:
so - the DCOM code is in the ole32 directory, yes?
Pretty much. We don't really have any code using the DCOM interfaces
yet, but we will probably have to soon.
so, can i ask you - where are
On Tue, Jan 18, 2005 at 01:51:34PM -0600, Robert Shearman wrote:
> Luke Kenneth Casson Leighton wrote:
>
> >On Tue, Jan 18, 2005 at 10:09:44AM -0600, Rob Shearman wrote:
> >
> >
> >>Luke Kenneth Casson Leighton wrote:
> >>
> >>
> >>
> >>>as i mentioned about the sharp requirement for "interope
Hi Oleh,
> --- wine-20050111/libs/unicode/cpmap.pl.orig 2004-01-21
00:39:06.0 +0200
> +++ wine-20050111/libs/unicode/cpmap.pl 2005-01-14 15:22:12.0
+0200
> @@ -82,6 +82,7 @@
> [ 10081, "VENDORS/MICSFT/MAC/TURKISH.TXT","Mac Turkish" ],
> [ 20866, "VENDORS/MISC/K
(Huw?)
Do I need to dig deeper to understand this or is there a defect in the logic.
If there are ttf fonts available does that mean a poor ttf match will be
selected even when a better x11drv font is available?
Note that my font knowledge is quite minimal
Context
When I installed our product o
Luke Kenneth Casson Leighton wrote:
On Tue, Jan 18, 2005 at 10:09:44AM -0600, Rob Shearman wrote:
Luke Kenneth Casson Leighton wrote:
as i mentioned about the sharp requirement for "interoperability", if
you have stuck to the _exact_ letter of the IDL file format, and other
areas, making it
On Tue, Jan 18, 2005 at 10:09:44AM -0600, Rob Shearman wrote:
> Luke Kenneth Casson Leighton wrote:
>
> >as i mentioned about the sharp requirement for "interoperability", if
> >you have stuck to the _exact_ letter of the IDL file format, and other
> >areas, making it possible to use either your h
On Mon, 2005-01-17 at 23:33, Mike Hearn wrote:
> On Mon, 17 Jan 2005 23:05:59 +0100, Paul Vriens wrote:
> > Wine and Win98 leave the buffer intact (the contents and thus size
> > differ however)
> > WinXPProf and W2KProf clear (so it seems) the buffer.
>
> That's why it's tested - MSDN is useful b
On Tue, 18 Jan 2005 12:57:15 +, Luke Kenneth Casson Leighton wrote:
> ? uhn??
>
> sorry, are you saying that no data goes out over-the-wire over
> a network, in your implementation?
Yes.
> as i understand it, the only way for DCOM to not use RPC is
> for you to implement COM, not DCOM
Juan Lang wrote:
Hi Joris,
pFromFile and pToFile are treated oddly. Pass them as WCHAR pointers to
file_operation_on_data, not as pointers to WCHAR pointers. The
implementation of file_operation_on_data does not behave the same way as
the code it replaced.
You want something like:
+static int fil
Hi Joris,
pFromFile and pToFile are treated oddly. Pass them as WCHAR pointers to
file_operation_on_data, not as pointers to WCHAR pointers. The
implementation of file_operation_on_data does not behave the same way as
the code it replaced.
You want something like:
+static int file_operation_on_
DOH!
Wrong list, ignore that. :-D
On Tue, 2005-01-18 at 10:39 -0600, Jeremy Newman wrote:
> Crap, I thought I queued up these downloads a week or so ago. Someone
> must have rebooted taz and killed my downloads. Argh, if it didn't take
> so long to dl these ISO's.
>
> Anyway, I restarted the dow
Crap, I thought I queued up these downloads a week or so ago. Someone
must have rebooted taz and killed my downloads. Argh, if it didn't take
so long to dl these ISO's.
Anyway, I restarted the downloads again, I hopefully should have them by
the end of today. I'll move them into /home/public/iso w
Hi,
As you can see in the attached patch file, I wrote a function
file_operation_on_data() which uses a WIN32_FIND_DATAW to do a file
operation; however, for some reason, tests start to fire when using the
function:
../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p
shell32_test.e
Luke Kenneth Casson Leighton wrote:
as i mentioned about the sharp requirement for "interoperability", if
you have stuck to the _exact_ letter of the IDL file format, and other
areas, making it possible to use either your home-grown IDL compiler or
dceidl _should_ be a trivial task.
I don't thin
Am Tue, Jan 18, 2005 at 02:44:09AM -0500 schrieb Tom:
> You will see in the patch that I sent:
> http://www.winehq.org/hypermail/wine-patches/2005/01/att-0477/01-press-download.diff
>
> I removed "under Linux written by Joachim von Thadden"
>
> As I had the exact same thoughts!
Thanks. On the Wi
Am Mon, Jan 17, 2005 at 09:06:54PM -0500 schrieb Vincent Béron:
> "Written by" or "maintained by"? I thought Frank wrote it in the
> beginning...
Yes, it's about 10% from Frank. So it must read: started by Frank and
continued by me or something like that.
> Some of the config files included in th
Here too, using 6.5.3 fr...
Stefan Zechmeister a écrit :
On Wed, 29 Dec 2004 00:35:48 -0500, Paul R Streitman wrote:
same here with notes 6.5.1.
Mike,
Sorry about that, I edited away the notes level at some point! This is
with notes 6.5.3. I can easily reproduce it if you would like me to try
an
i have entered i defect report in bugzilla: see
http://bugs.winehq.org/show_bug.cgi?id=2660
bye
stefan
On Fri, 14 Jan 2005 13:22:55 +0100, Stefan Zechmeister wrote:
> On Wed, 29 Dec 2004 00:35:48 -0500, Paul R Streitman wrote:
>
> same here with notes 6.5.1.
>
>> Mike,
>>
>> Sorry about that
mike, hi,
thank you for responding. your message contains misunderstandings that
i do not at present have time (actually money) to correct.
in brief:
1) yes FreeDCE, as wez has kindly
pointed out and added, provides code that results wire-compatibility
with MSRPC, has most of the compiler-comp
> If we need to extend it later using code from FreeDCE may be
> possible, but right now we :
> a) Don't know of *any* pure DCE-RPC applications people want to run
you _are_ aware that REGEDT32, USRMGR.EXE, SRVMGR.EXE and
most of the NT 4.0 Control Panel components are actually
DCE/RPC program
> As it is, the DCE-RPC code already in Wine CVS is more than
> enough for now. If we need to extend it later using code from
> FreeDCE may be possible, but right now we :
> b) Have a DCOM implementation that does not use RPC
? uhn??
sorry, are you saying that no data goes out over-the-wire
On Tue, Jan 18, 2005 at 11:18:29AM +, Luke Kenneth Casson Leighton wrote:
> > I do thank you for your concern, but I don't think you appreciate the
> > effort in ripping code kicking and screaming and integrating it in into
> > another project.
there is one major advantage that, i believes
On Mon, Jan 17, 2005 at 09:27:52PM -0600, Rob Shearman wrote:
> >the expression format of what you refer to as "type format strings"
> >that wez picked was for practicality purposes not for compatibility or
> >interoperability with NT.
> >
> >
>
> This is the point.
what??
i take it that y
Michael Stefaniuc <[EMAIL PROTECTED]> writes:
> Hi Alexandre,
>
> this patch introduced a regression with FreeSolitaire (free download
> at www.freesolitaire.com). After switching virtual desktops the
> program windows gets blanked (see attached image). The program dosn't
> lockThis seems to be t
32 matches
Mail list logo
