On Tue, Sep 9, 2008 at 5:03 AM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
> I started narrowing down some information in debugging a winemm issue
> and noticed the following in my logs...
>
> trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags
> 0, from 0x33f67c, fromlen 16, ovl (
On Mon, Sep 8, 2008 at 6:06 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> Interesting.One of my goals is to support Solaris and BSD;
> have you tried your stuff there?
>
What about OS X?
James Hawkins wrote:
> On Mon, Sep 8, 2008 at 10:03 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
>> I started narrowing down some information in debugging a winemm issue
>> and noticed the following in my logs...
>>
>> trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags
>> 0, fro
On Mon, Sep 8, 2008 at 10:03 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
> I started narrowing down some information in debugging a winemm issue
> and noticed the following in my logs...
>
> trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags
> 0, from 0x33f67c, fromlen 16, ovl
I started narrowing down some information in debugging a winemm issue
and noticed the following in my logs...
trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags
0, from 0x33f67c, fromlen 16, ovl (nil), func (nil)
trace:winsock:WSARecvFrom fd=51, options=0
warn:winsock:WSARecv
Kevin K wrote:
> Is winedbg the only method of debugging applications being
> developed for Windows on Wine?
>
> For instance, assume a program developed with Visual Studio
> in C or C++, and I needed to debug it on Linux?
If winedbg doesn't work for you, we should fix it. Same
goes for other de
Is winedbg the only method of debugging applications being developed for
Windows on Wine?
For instance, assume a program developed with Visual Studio in C or C++, and
I needed to debug it on Linux?
Thanks,
Kevin
> Also, it's possible some of your changes won't be needed
> after the refactoring... I plan to run wine-slave as a different
> user anyway...
That doesn't solve much; although in may look clean, it is not secure. The
user should have a limited amount of resources to work with. Your way, for
exam
> Interesting.One of my goals is to support Solaris and BSD;
> have you tried your stuff there?
Not yet, but that stuff is pretty generic, so it shouldn't be hard to get
it to work.
> I'm surprised you had to give up on the chroot...
> I was planning on trying to run just wine-slave.sh in
> a
> If its easier with gnutls, please use it.
+1
I also agree that nss is likely to replace openssl as the toolkit
of choice. But if depending
on gnutls is the easiest path to a working schannel, that's
the right thing to do. We can always change later if a
compelling reason arises.
- Dan
Interesting.One of my goals is to support Solaris and BSD;
have you tried your stuff there?
I'm currently refactoring patchwatcher.sh; I've pulled
the generic stuff out into libpatchwatcher.sh and
the wine-specific stuff into wine-slave.sh.
Your changes will fit nicely into wine-slave.sh, I ho
On Mon, Sep 8, 2008 at 2:32 PM, Paul Chitescu <[EMAIL PROTECTED]> wrote:
> Changelog:
>user32.dll: Stub for LockWorkStation()
>
> Not sure if user_main.c is the right place but I put it together with
> ExitWindowsEx.
Would you mind taking a shot at implementing this properly? It was on
my
2008/9/8 Paul Chitescu <[EMAIL PROTECTED]>:
> /***
>+ *LockWorkStation (USER32.@)
>+ */
>+BOOL WINAPI LockWorkStation()
This is the right place to put it be the above should be
"LockWorkStation(void)" not "LockWorkStat
On Mon, Sep 8, 2008 at 5:01 PM, Rotem Zach <[EMAIL PROTECTED]> wrote:
>
> +
> +
> internetQWCheckOption(NULL,INTERNET_OPTION_MAX_CONNS_PER_SERVER,(WCHAR*)"Open:
> INTERNET_OPTION_MAX_CONNS_PER_SERVER Got wrong length %d instead of
> %d\n",sizeof(ULONG));
> + internetQWCheckErr(ERROR_INSUFFICIE
Hi Hans,
Tests you added to the file dlls/winhttp/tests/notification.c are
causing several test failures across all platforms. Can you please
have a look at this?
Thanks,
James Hawkins
On Mon, Sep 08, 2008 at 11:37:39PM +0200, Henri Verbeet wrote:
> 2008/9/8 Marcus Meissner <[EMAIL PROTECTED]>:
> > Hmm,
> >
> > I really do not think gnutls will have a long feature,
> > NSS seems to be the future choice of crypto frameworks :/
> >
> > Ciao, Marcus
> >
> I did have a look at NSS, b
On Mon, Sep 08, 2008 at 02:36:36PM -0700, Lei Zhang wrote:
> On Mon, Sep 8, 2008 at 2:26 PM, Marcus Meissner
> <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote:
> >>
> >
> >> From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001
> >> From
2008/9/8 Marcus Meissner <[EMAIL PROTECTED]>:
> Hmm,
>
> I really do not think gnutls will have a long feature,
> NSS seems to be the future choice of crypto frameworks :/
>
> Ciao, Marcus
>
I did have a look at NSS, but didn't see a way to make it work with a
simple buffer, which makes in impracti
On Mon, Sep 8, 2008 at 2:26 PM, Marcus Meissner
<[EMAIL PROTECTED]> wrote:
> On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote:
>>
>
>> From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001
>> From: Henri Verbeet <[EMAIL PROTECTED]>
>> Date: Mon, 8 Sep 2008 22:39:11 +02
On Mon, Sep 08, 2008 at 11:10:11PM +0200, Henri Verbeet wrote:
>
> From cb10664e7d7526951d97f6d9ba2f7429d20b69d4 Mon Sep 17 00:00:00 2001
> From: Henri Verbeet <[EMAIL PROTECTED]>
> Date: Mon, 8 Sep 2008 22:39:11 +0200
> Subject: secur32: Require gnutls for schannel
> +AC_ARG_WITH(gnutls,AS_
Hi,
I've abandoned my chroot aproach to improving security in patchwatcher.
Instead I've implemented the ability to run untrusted code as a user
different than the one running patchwatcher. This is because creating a
chroot where Wine could be compiled and tested proved to be too difficult
and pla
Hi all,
Today Peter Hutterer posted a preliminary feature list of Xinput 2. I have
forwarded the email to here so that Vitaly and others can check it out and see
if it offers what we need in Wine. If you have comments I would send them to
the xorg list.
Regards,
Roderick Colenbrander
--- Xor
2008/9/6 Christof Sigel <[EMAIL PROTECTED]>:
> Thanks for the input, I really should have realised my approach was
> incorrect as soon as I saw that DXT textures are in blocks.
> I'm not quite sure how to go about writing a test case, would I just
> have to create and update surface(s) and check th
Thanks for the input, I really should have realised my approach was
incorrect as soon as I saw that DXT textures are in blocks.
I'm not quite sure how to go about writing a test case, would I just
have to create and update surface(s) and check that the resulting
surface(s) have been updated corr
Hello all,
after wrestling severals days with Wine's debugging capabilities I
think I need some advice.
First, regardless wether my app (Catia) is launched with wine or
winedbg, Peb->BeingDebugged is always False. To the best of my
efforts I can't find the code snippet which sets this var
So I have been banging my head against this test for a few weeks now.
There are just so many variables, what IME is on the windows box, what
locale is set, and such. This all changes the behavior in a way that it
is a headache to write a test that will demonstrate the behavior this
fixes and als
On Mon, Sep 8, 2008 at 5:22 PM, Paul Vriens <[EMAIL PROTECTED]> wrote:
> Jeff Zaroyko wrote:
>>
>>
>>
>>
> I found more or less the same thing for Vista a few days ago. Doing a
> IDirectSoundBuffer_Release sets the reference c
Francois Gouget <[EMAIL PROTECTED]> writes:
> What is the rational for eliminating wineshelllink?
>
> It seems to me that by eliminating it we are losing a lot of flexibility
> for handling special setups (and there are a lot of these in menuing
> systems).
We don't gain much flexibility by spl
On Mon, Sep 8, 2008 at 4:41 AM, James Hawkins <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 4:38 AM, Markus Hitter <[EMAIL PROTECTED]> wrote:
>>
>> Am 08.09.2008 um 01:30 schrieb James Hawkins:
>>
>>> For example, the following is significantly easier to read:
>>>
>>>ok(result == ERROR_BU
Dmitry Timoshkov wrote:
>> +if (pData == NULL)
>> +{
>> +if (cbData == (DWORD)-1)
>> +pConv->instance->lastError = DMLERR_INVALIDPARAMETER;
>> +else
>> +pConv->instance->lastError = DMLERR_MEMORY_ERROR;
>> +return NULL;
>> +}
>
> Alexandre
On Mon, Sep 8, 2008 at 4:38 AM, Markus Hitter <[EMAIL PROTECTED]> wrote:
>
> Am 08.09.2008 um 01:30 schrieb James Hawkins:
>
>> For example, the following is significantly easier to read:
>>
>>ok(result == ERROR_BUFFER_TOO_SMALL ||
>>result == ERROR_INVALID_USER_BUFFER || /* win98 */
>>
Am 08.09.2008 um 01:30 schrieb James Hawkins:
> For example, the following is significantly easier to read:
>
> ok(result == ERROR_BUFFER_TOO_SMALL ||
> result == ERROR_INVALID_USER_BUFFER || /* win98 */
> result == ERROR_INVALID_DATA, /* Vista */
> "Expected ERROR_BUF
On Saturday 06 September 2008 22:21:15 James Hawkins wrote:
> > Tests that fail on Windows and succeed on Wine
> > ==
> > - ws2_32:sock has 1 consistent failure on all Windows boxes but not on
> > Wine
>
> Last attempt got no comments:
>
> http://winehq.
Jeff Zaroyko wrote:
>
>
>
>
I found more or less the same thing for Vista a few days ago. Doing a
IDirectSoundBuffer_Release sets the reference counter to zero but doesn't clear
secondary. Is this something worthwhile to
34 matches
Mail list logo
