This certainly looks useful, thanks! I suspect it'll need at least
CoTreatAsClass to be implemented to work on Wine, but that isn't too
hard (it may even be done by now, been a while since I checked).
Saulius Krasuckas wrote:
Am not sure would it be of any use for list members, but just some min
Actually nearly all critical sections in Wine are initialized
statically. This improves performance, and avoids having lots of
"init" functions called all over the place. I'm not convinced it's
worth changing that just to be able to build a list of sections.
It also lets you name them more easily w
Check out the NEW! IMPROVED! Wine developer cheatsheet here:
http://navi.cx/~mike/wine/developer-cheatsheet.html
Everything you always wanted to know but were too afraid to ask,
in ONE convenient document!!
In particular, it explains how to work with unicode strings in Wine.
Look for
My other concern is if I start doing it and have to give up due to work or
other pressures, I could leave a half migrated setup. I assume its
relavitevly easy with cvs to back out changes if this occurs, and I hope it
wont, but it is a concern.
I'd appreciate thoughts before I start (especially Lio
It appears that Mike has been doing a lot of work on this.
http://www.winehq.org/hypermail/wine-devel/2004/09/0221.html
So you probably first want to coordinate with him.
Yes. I'm aware that I'm holding people up right now due to my
non-connectedness. I'm actually living in a bed&breakfast with no
This is interesting information, but where did it come from? Is this
structure described in some MS documentation? If so, does it have the
full layout of the TEB as well?
Log message:
Robert Reif <[EMAIL PROTECTED]>
Document all the structure members up to SessionId in the PEB.
Robert Shearman wrote:
Hi,
You can call InternetSetStatusCallback on a HTTP handle, not just a
InternetOpen handle, so we should search up through the parents to
find it.
Oops, I just checked on MSDN and this patch is wrong. We should copy and
store the status callback in every handle, not jus
On Mon, Sep 13, 2004 at 11:38:32AM +0100, Robert Shearman wrote:
> Hi,
>
> I have seen one server that likes to return "ICY" instead of "HTTP/1.x".
> This patch allows the connection to the server continue, as native does.
This would be "icecast" I suspect ;)
Ciao, Marcus
pgp4VgjdKu2qm.pgp
De
> This is the sort of thing we wanted arch for. Unfortunately, the way we
> use CVS means that we can't really do branching as only AJ commits. So,
> if it's not possible to do the migration without breaking things
> temporarily, there are three ways forward:
Well, why could we not live with DX
> I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm
> only just getting back into wine programming again hence my interest.
I would be for solution 1) even if it means breaking somewhat D3D8 for some
time. Note that this was Raphael's plan (although his was even more
ambi
Well, why could we not live with DX8 / DX9 breakage for some time ? At the
time D3D was resurected, it was broken for most of the time (and probably
still is :-) ).
And if someone disappears from development, it's just more motivations for
others to pick up the work and continue (which would be mor
Hi James,
> Can this patch be broken up into smaller, independent parts? It's
> more likely to be committed if that is the case.
Aside from the tests, what constitutes independent? These are all new
functions so there is no possibility of regressions, which is the
main reason to split up patches
> If we as a project are committed to doing 0.9, 1.0+ releases it means we
> can't simply break code people are using to play their games for months
> at a time and shrug it off
After 1.0 there will be a stable and a development branch, the stable one for
users, and the development one for new st
Ivan Leo Puoti wrote:
> if things are broken for a while. A bit like the kernel with 2.4 stable
> and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least
> that's how most projects work.
It's also true that the kernel is not going to branch 2.7 anytime soon.
I don't think that
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote:
> At *some* point we have to stop simply releasing CVS snapshots which may
> or may not work/run important apps/eat your hard disk and actually do
> proper releases that are, you know, tested'n'stuff.
Yes, but what should I care about t
> For example, if DirectX is broken for 3 consecutive releases, I would expect
> the people doing the release to label the old 'working' version and branch
> from there if any bugs fixes are needed.
Things in wine break all the time, users know it and are used to it, if d3d8
breaks for 3 releases,
> I don't think that a breakage in d3d can be an option now. Wine is an 'old'
> project also if not stable or mature, and breaking stuff now is a big
> problem to users.
Well, if that is the case, we need to recruit someone to do 'proper'
releases as there are no guarantees for now of any stabilit
Hi all,
It seems that OutputDebugString is defined in the Win32 API as a set of
client side operations. In wine, however, it is a server request.
I have not traced it into the server to see whether they carry out the
same operations or not. However, even if they do, I am wondering why we
need t
Hi,
I am looking in a display problem in the electronic declaration programs
of the Dutch tax office.
Here is a schematic of the windows involved:
+--10022---+
| |
| +--100c6-+
| |
so that debuggers can intercept it (especially ones with GUI) and do what they want with it.A+
> Message du 13/09/04 17:50> De : "Shachar Shemesh" <[EMAIL PROTECTED]>> A : "Wine Development" <[EMAIL PROTECTED]>> Copie à : > Objet : Why is our OutputDebugString a server request?>
Pouech Eric DMI AEI CAEN wrote:
so that debuggers can intercept it (especially ones with GUI) and do
what they want with it.
A+
> Message du 13/09/04 17:50
> De : "Shachar Shemesh"
> A : "Wine Development"
> Copie à :
> Objet : Why is our OutputDebugString a server request?
Title: RE: Why is our OutputDebugString a server request?
I agree - I got stumped on this very issue when I got into Wine last year. I was used to relying on these trace messages and it took me a while to understand where the messages were actually being sent!
//raghavan
-Original Mess
On Mon, 13 Sep 2004 17:21:51 +0200, Ivan Leo Puoti <[EMAIL PROTECTED]> wrote:
> Things in wine break all the time, users know it and are used to it, if d3d8
> breaks for 3 releases, people will just use an old version until things are
> fixed. Many people stayed at wine-20031212 for months because
Please hold this patch and don't commit it yet.
I've been told that it contains things to be checked first.
/J
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jens Collin
Sent: den 11 september 2004 21:47
To: [EMAIL PROTECTED]
Subject: patch: shell32.dll
Jon Griffiths <[EMAIL PROTECTED]> writes:
> Aside from the tests, what constitutes independent? These are all new
> functions so there is no possibility of regressions, which is the
> main reason to split up patches. Ease of understanding/reviewing the
> patches is the other main reason, but each
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> ChangeLog:
> Roderick Colenbrander <[EMAIL PROTECTED]>
> Gerald Pfeifer <[EMAIL PROTECTED]>
> Make WS2_Send(), WS_getsockopt(), and WS_setsockopt() work on FreeBSD.
You shouldn't use #ifdef __FreeBSD__ for that, you should check for
the actual features
> Aside from the tests, what constitutes independent?
If the functions do not rely on each other, then they are independent
of each other. You can leave it the way it is, but it was a
suggestion to help from the case where say one of the functions has an
error in it. If that is the case then non
On Mon, Sep 13, 2004 at 09:44:12AM +0100, Mike Hearn wrote:
>
>
>Check out the NEW! IMPROVED! Wine developer cheatsheet here:
>
>http://navi.cx/~mike/wine/developer-cheatsheet.html
>
>Everything you always wanted to know but were too afraid to ask,
>in ONE convenient document!!
>Anyway, that wasn't really what I was getting at.. last spring Lionel
>had this to say about a wined3d library:
It does make sense to have common code all in the same place...
Ivan.
Andreas Mohr <[EMAIL PROTECTED]> writes:
> Hi,
>
> "template" is a keyword on c++, so better rename it to menu_template.
We've been through this before; there's absolutely no reason to do
that.
--
Alexandre Julliard
[EMAIL PROTECTED]
On Mon, Sep 13, 2004 at 01:55:19PM +0100, Mike Hearn wrote:
> At *some* point we have to stop simply releasing CVS snapshots which may
> or may not work/run important apps/eat your hard disk and actually do
> proper releases that are, you know, tested'n'stuff.
While this point will come eventual
On Mon, 13 Sep 2004, Alexandre Julliard wrote:
You shouldn't use #ifdef __FreeBSD__ for that, you should check for
the actual features (for instance #ifdef SOL_IPX etc.), possibly
adding configure checks if needed.
You're right. Tested on FreeBSD 4.10 as well as SUSE Linux 9.1.
Gerald
ChangeLog:
> At *some* point we have to stop simply releasing CVS snapshots which may
> or may not work/run important apps/eat your hard disk and actually do
> proper releases that are, you know, tested'n'stuff.
Also consider that the time wasted on testing/releasing/branching will slow up
wine development,
Juan Lang <[EMAIL PROTECTED]> writes:
> @@ -2230,13 +2232,23 @@
>
> sz = 14 + pisid->SubAuthorityCount * 11;
> str = LocalAlloc( 0, sz*sizeof(WCHAR) );
> -sprintfW( str, fmt, pisid->Revision,
> - pisid->IdentifierAuthority.Value[2],
> - pisid->IdentifierAuthority.Va
"Alexander Yaworsky" <[EMAIL PROTECTED]> writes:
> +if( WAIT_FAILED == r )
> +{
> +last_error = GetLastError();
> +CloseHandle( procinfo.hProcess );
> +goto done;
> +}
>
> -ReleaseSemaphore(data, 1, NULL);
> -
> -if( r == WAIT_FAILED)
> -return
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> But as far as I can see, this means that Windows debuggers won't get
> it. Wouldn't it be better to implement it the Win32 way? At the very
> least, implement it ALSO as the Win32 way?
It will generate an output string debug event, so Windows debugger
Juan Lang <[EMAIL PROTECTED]> writes:
> +static void loadShell32(void)
> +{
> +if (hShell32)
> +{
> +if (pMalloc)
> +{
> +pMalloc->lpVtbl->Release(pMalloc);
> +pMalloc = NULL;
> +}
> +/* until it's really unloaded: */
> +while
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > +static void loadShell32(void)
> > +{
> > +if (hShell32)
> > +{
> > +if (pMalloc)
> > +{
> > +pMalloc->lpVtbl->Release(pMalloc);
> > +pMalloc = NULL;
> > +}
> > +/* until it's reall
Hi Dimi,
Thanks for the offer but I have had the project pulled. Unfortunately I
couldnt get a working model in time and the hardware has been recycled to
another project ;-(. Basically I needed to compile STLport so I could use
iostreams in a project I was converting to wine. I'm going to keep
I'm trying to write a Direct Input regression test and I ran into a
problem I can't resolve (and the linker too). dinput.h defines an
extern variable:
extern const DIDATAFORMAT c_dfDIJoystick;
I can't find this variable in dinput.dll but it is in dinput.lib on
windows. It looks like I need to gen
[EMAIL PROTECTED] wrote:
I'm trying to write a Direct Input regression test and I ran into a
problem I can't resolve (and the linker too). dinput.h defines an
extern variable:
extern const DIDATAFORMAT c_dfDIJoystick;
I can't find this variable in dinput.dll ...
It looks like it was added about te
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
But as far as I can see, this means that Windows debuggers won't get
it. Wouldn't it be better to implement it the Win32 way? At the very
least, implement it ALSO as the Win32 way?
It will generate an output string debug
42 matches
Mail list logo
