Re: Retiring...for now

[Tom Wickline]

Dustin Navea wrote:

Anyways, It's been fun; anyone that wants to take over my bugs on 
bugs.winehq.com may do so, anyone that wants to take over any of my 
other tasks (User's Guide, etc) may do so as well, but save a spot for 
in case I ever find a way to get back here..  May you all have much luck 
in your journeys and I hope to see you all again someday...

I would like to say that I wish you the best of luck in the future.
And we all have obstacles that get in are way from time to time.
And all that we can ask for is the strenth to over come them.
Take care and be safe...

Tom



Regards,

 

Dustin

Re: x11drv, ntdll separation

[David Fraser]

David Hammerton wrote:

On Tue, 25 Feb 2003 01:49, David Fraser wrote:

 

Seems to make sense except that I still have one question: the MSDN docs
seem to indicate that you need to call GDIFlush() before performing any
drawing operations to the bitmap yourself (at least for Windows NT).
Would it be possible to keep a list of DIBSections and flush them all in
GDIFlush, or is this not adequate?
   

I'm not familiar with GDIFlush(), but I just had a quick glance at the msdn 
docu for it, and it appears this is only relevent when using GDI in batch 
mode, (eg, do a bunch of GDI calls and then go 'render this') - and even then 
it still isn't required. Even if this function did what you wanted, it still 
wouldn't be possible to use properly because of speed issues (eg, we only 
coerce when we have to), and so on. (the same could be said for doing a 
coerce after each GDI call).

David
 

Right, but the MSDN documentation for CreateDIBSection says:

*Windows NT/2000/XP:* You need to guarantee that the GDI subsystem has 
completed any drawing to a bitmap created by *CreateDIBSection* before 
you draw to the bitmap yourself. Access to the bitmap must be 
synchronized. Do this by calling the *GdiFlush* 
 
function. This applies to any use of the pointer to the bitmap bit 
values, including passing the pointer in calls to functions such as 
*SetDIBits*.

So internally, at least on Win NT/2000/XP, Microsoft themselves are 
doing this in a batched
way and expecting to receive a GDIFlush before they have to update it.
Speed-wise, I guess this may not be feasible because of the difference 
of using X, but actually,
the user should call GDIFlush at exactly the points where we are picking 
up the page faults -
when they're going to write to a bitmap that they've called GDI 
functions on. This might even
therefore end up being quicker because there isn't the page fault 
handling overhead.

Am I way off track?

David

PS The above doc is at 
http://msdn.microsoft.com/library/en-us/gdi/bitmaps_233i.asp

further information from 
http://msdn.microsoft.com/library/en-us/tools/improve_77ar.asp below


If you are writing an application that draws on the display, then the 
**CreateDIBSection** 
 function 
can improve performance. This function allows you to share a memory 
section directly with the system, and thus avoid having it copied from 
your process to the system each time there is a change. Previously, a 
common practice was to call the *GetDIBits* 
 function, 
make the required changes, then call the *SetDIBits* 
 function. 
These steps were often repeated on different scan lines of the bitmap 
before the image was ready for updating. Using **CreateDIBSection** is 
much simpler.

One word of caution if you decide to use **CreateDIBSection**. You need 
to be sure that any calls that might affect your bitmap have completed 
before you start to draw in it. This is because the batching of GDI 
calls may cause their delayed execution. For example, suppose you make a 
*PatBlt*  
call to clear your bitmap, then you start to change the bits in your DIB 
section. If the *PatBlt* call was batched, it might not actually execute 
until after you start to make the bitmap changes. So, before you make 
changes to your DIB section, be sure to call **GdiFlush** 
 if you 
have made changes to the bitmap with earlier GDI calls.

Re: Spam/Bounce-Mail

[Dan Kegel]

Joerg Frings-Fuerst wrote:
first I say sorry for your trouble with my bounce-mails.

This weekend I setup my new Mail-Backupserver. After this work I test a new 
version of my Spamcheck-script. In this script I call "rblcheck". My mistake 
was the test via list.dsbl.org. 
I don't mind -- it revealed a bug in my email setup!
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: x11drv, ntdll separation

[David Hammerton]

On Tue, 25 Feb 2003 01:49, David Fraser wrote:

>
> Seems to make sense except that I still have one question: the MSDN docs
> seem to indicate that you need to call GDIFlush() before performing any
> drawing operations to the bitmap yourself (at least for Windows NT).
> Would it be possible to keep a list of DIBSections and flush them all in
> GDIFlush, or is this not adequate?

I'm not familiar with GDIFlush(), but I just had a quick glance at the msdn 
docu for it, and it appears this is only relevent when using GDI in batch 
mode, (eg, do a bunch of GDI calls and then go 'render this') - and even then 
it still isn't required. Even if this function did what you wanted, it still 
wouldn't be possible to use properly because of speed issues (eg, we only 
coerce when we have to), and so on. (the same could be said for doing a 
coerce after each GDI call).

David


-- 
David Hammerton
Programmer
TransGaming Technologies Inc.
[EMAIL PROTECTED]

Re: using-ms-vcpp-with-gnu-win article

[Dan Kegel]

Eric Pouech wrote:
- the console creation at wcmd startup should we removed when run under 
wineconsole (but, this would be rather annoying for some users). I have 
a patch for this, but it would mean that there are two ways of running 
wcmd: 'wineconsole wcmd /switch_for_no_new_console' or 'wcmd' (for using 
a brand new console)
Shall I scream again?  We *really* need a way of running wcmd
in an existing terminal, with *no* X stuff going on at all
until the app requests it.   Windows doesn't pop up a new
window for wcmd by default, and we shouldn't either.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: Don't use -Wpointer-arith if it produces excessive warnings

[Dmitry Timoshkov]

"Mike McCormack" <[EMAIL PROTECTED]> wrote:

> Wine works around other problems on the build platform (eg. 
> strength-reduce bug, detected a few lines after my patch in 
> configure.ac).  I don't see how broken headers are any different from a 
> broken compiler or broken libraries, which we already detect and deal 
> with in the configure script.

Compiler optimization bugs and bugs in the system headers are two very
different things. The former can be easily and without any harm disabled,
while the latter is completely unavoidable at all without a replacement.

-- 
Dmitry.

[OT] Re: Gentoo -> Re: gcc 3.2.2?

[Gregory M. Turner]

On Monday 24 February 2003 11:02 am, Steven Tower wrote:
> > because my ac kernel is crashing, i was gonna try redhat 2.4.20-2.48
> > (which is what gentoo gives me for "redhat-kernel").  but while i'm at
> > it, i'll try bootstrap gentoo (which recompiles a bunch of core stuff,
> > some of it twice, incl. glibc & gcc), compile wine, and see what happens.
> >  guess i have to get the new kernel running first though.  maybe, this is
> > too early a redhat kernel to trigger it... ?

heh, typical.  Red Hat's kernel won't compile ALSA, so no RedHat kernel for 
me.  too bad...  This won't stop me from testing the bleeding-edge one from 
Rawhide, however, not that I expect to learn anything that isn't already 
known from this, but I'd like to see it for myself.

S back to vanilla kernels again... my Radeon 9700 is just a fast PCI 
card in this thing and my KT400 mobo doesn't let me drop it down to 
AGP2.0 mode to fix it blech... maybe I should just accept my fate and 
take the 2.5.x plunge.

-- 
gmt

Re: [OT] Gentoo -> Re: gcc 3.2.2?

[Gregory M. Turner]

On Monday 24 February 2003 11:02 am, Steven Tower wrote:
> I was unaware that you could bootstrap gentoo long after an install, but
> low and behold it looks like you can.  I actually upgraded one of my remote
> boxes (was Mandrake 7.0) to Gentoo 100% from remote and booted into gentoo,
> scary 2 1/3 minutes waiting for the server to come back up. :)
>
> Thanks for (inadvertently) bringing this to my attention.
>
> Steven
>

No matter how screwed up your linux box is, so long as gcc still works, you 
can rescue it by installing gentoo on it!   Now, if only portage worked on 
cygwin, maybe I could fix MS Windows  :)  :)  :)

-- 
gmt

Retiring...for now

[Dustin Navea]

Hey guys, I know its been a while..  Things have changed a lot since my last contact with you guys, just thought I would give you a heads up..  I couldnt afford the phone/dsl and let that go, lucky my email is still in tact..  Then I lost my job and couldn't afford rent, so I sold my PC :'-(  Now, Im gettin ready to start a new job as a telemarketer, and will hopefully be able to make rent this month..  I think everything will be O.K. I just need time to get my priorities straight..  I will probably be leaving to go into the U.S. Army toward the end of the year this year or beginning of next year...
 
Anyways, It's been fun; anyone that wants to take over my bugs on bugs.winehq.com may do so, anyone that wants to take over any of my other tasks (User's Guide, etc) may do so as well, but save a spot for in case I ever find a way to get back here..  May you all have much luck in your journeys and I hope to see you all again someday...
 
Regards,
 
Dustin

Re: annoyance running mingw

[Gregory M. Turner]

On Monday 24 February 2003 11:23 am, Steven Edwards wrote:
> Now all someone needs to do is build WINE on mingw running under WINE 

Then we can say wine is "self hosting" ;)

-- 
gmt

Re: gcc 3.2.2?

[Marcus Meissner]

> Gregory M. Turner wrote:
> >So, what can I expect from wine and gcc322?  Any known interestingnesses?
> >Anyone even tried it? Presumably, since the threading magic needs to be in 
> >the
> >kernel (I run a modified linux-2.4.21-pre4-ac5 atm), I will not get the 
> >pthread bug...

Wine even compiles and works fine with the gcc 3.3 branch. It also
compiles with 3.4 branch, but I have not tested it with it yet (I think
it will also work).

So gcc version is not a problem.

Ciao, Marcus

Re: WCMD AutoExec patch

[davep]

On Monday 24 Feb 2003 20:10, Eric Pouech wrote:
> > As discussed on Wine-devel recently this patch allows wcmd to execute a
> > file "autoexec.wine" if it exists in the root directory of the default
> > drive.
>
> I think we'd better shouldn't we look in
> <%sysdir%>\system32\autoexec.wine instead (that's where NT puts the
> autoexec.nt files that cmd.exe loads on startup) ?

I didn't know about that...

But then maybe other people won't know either. Ideally there should be a 
per-user file, but I don't think any Windoze version can do that (other than 
setting environment variables via registry parameters).

Dave

Re: XIM support patch 3rd

[Alexandre Julliard]

liu spider <[EMAIL PROTECTED]> writes:

> I use the "old method" to implement XIM support using
> the newly added functions in wine. It works in some
> cases, but don't in other. 
> And should I submit the patch or just wait for you to
> work on it later?

It never hurts to submit a patch. Even if I don't apply it as is, it
can still be a useful reference for further work.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: using-ms-vcpp-with-gnu-win article

[Eric Pouech]

Dan Kegel wrote:
http://codingstyle.com/articles/using-ms-vcpp-with-gnu-wine.html
was just mentioned at
http://developers.slashdot.org/developers/03/02/23/1939225.shtml?tid=156
Yup, I've been doing this, and the author is right: the
commandline tools show off a few rough edges of Wine.
As more people start using them, maybe we'll get them
smoothed off (e.g. my fix to wcmd the other day to keep
it from stripping off switches too zealously)...
if I look at the issues:
- filename conversion (including #include to lowercase) => wine maker 
handles this
- passing file names on command line (DOS vs UNIX paths) => wine 
requires DOS paths to work in all cases
- inheriting in wine environment vars from DOS => either convert them as 
Unix vars, or use the yet to be committed autoexec.wine in wcmd
- compilation time: maybe linked to process startup (I don't see a need 
of lots of synchronization issues in cl.exe, but who knows)
- complaints on wcmd (which in fact apply to wineconsole) are mostly 
fixed (patches are committed, need to be applied) (=> size modification, 
clipboard corruptions)
- the console creation at wcmd startup should we removed when run under 
wineconsole (but, this would be rather annoying for some users). I have 
a patch for this, but it would mean that there are two ways of running 
wcmd: 'wineconsole wcmd /switch_for_no_new_console' or 'wcmd' (for using 
a brand new console)
- TRACE messages while running cl => does someone have a copy of those ?
- msvcrt lookup (native/builtin) => fixed in CVS

so, I don't think the situation is so bad:
- a bunch of real bugs, which have been mostly fixed
- a need for a bit more of documentation for this type of needs
A+
--
Eric Pouech

Re: Crashes in OSSs audio.c on FreeBSD

[Eric Pouech]

BSD is probably doing the same thing, but nevertheless, -STABLE (i.e.
FreeBSD 4.x) has a bug in the pcm-driver (I think) which makes mapping
the buffer write-only impossible (at least for me).
FreeBSD 5.x does not have that problem and sadly the pcm-code between
4.x and 5.x is virtually the same.
I think I remember BSD folks speaking of mmap changes... can someone 
confirm ?

+#ifndef __FreeBSD__
	/* for some reason, es1371 and sblive! sometimes have junk in here.
	 * clear it, or we get junk noise */
	/* some libc implementations are buggy: their memset reads from the 
	buffer...
@@ -1826,6 +1832,9 @@
	/* in all cases, fill the remaining bytes */
	while (len-- != 0) *p1++ = 0;
	}
+#else
+memset(wwo->mapping,0, wwo->maplen);
+#endif
you shouldn't need this chunk


I know, this has nothing to do with mmap()ing the buffer, but it looks
like FreeBSDs libc doesn't have the bug with memset(), so I just used
that instead.
sure, not all Linux distros have this bug, but it creates a new code 
path, which is bad for maintenance... so leaving the code as it is, is a 
 better option

A+

--
Eric Pouech

Re: WCMD AutoExec patch

[Eric Pouech]

Dave Pickles wrote:
As discussed on Wine-devel recently this patch allows wcmd to execute a file 
"autoexec.wine" if it exists in the root directory of the default drive.
I think we'd better shouldn't we look in 
<%sysdir%>\system32\autoexec.wine instead (that's where NT puts the 
autoexec.nt files that cmd.exe loads on startup) ?

A+

--
Eric Pouech

Re: Rebuilding font retrics each time Wine starts.

[Duane Clark]

J. Grant wrote:
Hi,

Is there a reason the "font metrics" are rebuilt every day or so? (when 
I start to run a program with wine)
See the thread:
http://www.winehq.com/hypermail/wine-users/2003/02/0073.html

Rebuilding font retrics each time Wine starts.

[J. Grant]

Hi,

Is there a reason the "font metrics" are rebuilt every day or so? (when 
I start to run a program with wine)

I am using cvs 20030115

Regards

JG

Re: Don't use -Wpointer-arith if it produces excessive warnings

[Mike McCormack]

Wine works around other problems on the build platform (eg. 
strength-reduce bug, detected a few lines after my patch in 
configure.ac).  I don't see how broken headers are any different from a 
broken compiler or broken libraries, which we already detect and deal 
with in the configure script.

Mike

Dmitry Timoshkov wrote:

I.e. are you proposing to build a potentially broken Wine binaries instead
of fixing a probable source of bug? Is there a point in turning warnings
on if nobody pays attention to them or even tries to get rid of them if
they annoy enough?

Re: Fast thread-local storage for OpenGL drivers

[Jakub Jelinek]

On Sun, Feb 23, 2003 at 06:44:10PM -0800, Gareth Hughes wrote:
> > In fact, we put this feature there with GL in mind...
> 
> Did you inform the OpenGL vendors who were interested in this issue of this
> fact?  Have you documented it anywhere, particularly in Ulrich Drepper's
> "ELF Handling For Thread-Local Storage" document?  The current version of
> this document clearly states that the Local Exec TLS model "can only be used
> for code in the executable itself and to access variables in the executable
> itself".  Perhaps you can see why I was still under the impression that it
> would not work for a dynamically loadable shared library.

I believe all this was said during the huge OpenGL thread in May 2002.
Certainly the idea to support dlopening of limited number of IE/LE model
using libs came at that time.

For the dispatch tables I even remember suggesting to:
a) do the normal "awx" section entries with LE model, ie.
.section openGL_wtext, "awx"
.globl Foo
Foo:
   movl %gs:[EMAIL PROTECTED], %eax
   jmpl *offset_Foo(%eax)
b) in addition to that, you can build an .a library with the above 5 lines
   per .o file's source plus .hidden Foo which would make apps/libraries
   using openGL even faster (as they wouldn't hop through PLT, which is
   one memory load and indirect jump through the loaded value) at the expense
   of making offset_Foo part of the openGL ABI (which as far as I understood
   already is anyway because of the binary modules).
c) or you could inline the calls

In the May thread, I'm pretty sure you mentioned __indirect* routines
which are the biggest part of libGL.so are rarely used, which means the
definitely should be compiled with -fpic, the rest if it is really
performance critical can be put into awx sections using
__attribute__((section("..."))).

Jakub

Re: Don't use -Wpointer-arith if it produces excessive warnings

[Mike McCormack]

Dmitry Timoshkov wrote:

Same on RH 6.2. But it's actually bug(s) in string.h and a better way IMHO
is just fix it, instead of silencing warnings if a user is *really* annoyed
by that avalanche of warnings.
I agree that it is a bug in string.h, and that it would be better if it 
were fixed, but I think most people will not go to the hastle of 
modifying their string.h or upgrading their headers... IMO it is cleaner 
to not make the warnings.  People who have good headers will have wine 
compiled with -Wpointer-arith, and can fix and warnings that they see.

Personally I'd rather not mess with the default header files on my 
system, as I'd problem screw them up, and thus screw up every program I 
built ;)

Mike

interestig link

[Igor]

http://codingstyle.com/articles/using-ms-vcpp-with-gnu-wine.html

Re: Fast thread-local storage for OpenGL drivers

[Gareth Hughes]

Roland McGrath wrote:
> 
> In glibc, we actually allocate some excess space in the thread-local
> storage area layout determined at startup time.  This lets a dynamically
> loaded module use static TLS if its PT_TLS segment fits in the available
> surplus.  (In sysdeps/generic/dl-tls.c, see TLS_STATIC_SURPLUS.)  If there
> is insufficient space preallocated, then loading the module will fail.  In
> fact, we put this feature there with GL in mind and can adjust the
> preallocated surplus for what is most useful in practice.

The last time we discussed this issue, I had the distinct impression that an
OpenGL library would essentially be forced into using one of the dynamic
access models (GD or LD) for __thread variables, hence requiring at least
one function call to access a thread-local variable.  I also had the
distinct impression that the glibc maintainers were unwilling to modify
their implementation so that we could use the LE access model, which would
allow a 2 instruction thread-safe dispatcher among other things.

It looks like I was wrong, and you've gone and addressed all the concerns I
originally had with __thread variables.  For that, I'm grateful.

> In fact, we put this feature there with GL in mind...

Did you inform the OpenGL vendors who were interested in this issue of this
fact?  Have you documented it anywhere, particularly in Ulrich Drepper's
"ELF Handling For Thread-Local Storage" document?  The current version of
this document clearly states that the Local Exec TLS model "can only be used
for code in the executable itself and to access variables in the executable
itself".  Perhaps you can see why I was still under the impression that it
would not work for a dynamically loadable shared library.

-- 
Gareth Hughes ([EMAIL PROTECTED])
OpenGL Developer, NVIDIA Corporation

[OT] Gentoo -> Re: gcc 3.2.2?

[Steven Tower]

I was unaware that you could bootstrap gentoo long after an install, but low 
and behold it looks like you can.  I actually upgraded one of my remote boxes 
(was Mandrake 7.0) to Gentoo 100% from remote and booted into gentoo, scary 2 
1/3 minutes waiting for the server to come back up. :)

Thanks for (inadvertently) bringing this to my attention.

Steven

On Monday 24 February 2003 09:51 am, Gregory M. Turner wrote:
> On Monday 24 February 2003 03:24 am, Michael Stefaniuc wrote:
> > On Mon, Feb 24, 2003 at 01:44:27AM -0600, Gregory M. Turner wrote:
> > > from that or not?  Is there a test that is known to reliably break
> > > against the new threading model (or perhaps I can presume I "got it" if
> > > i can't run notepad?1)
> >
> > If you can run notepad you aren't affected by the bug because the bug is
> > merciless: the wineserver wont even start because it fails to create the
> > needed socket in /tmp/.wine-$user/server-XX/ (this stuff gets
> > deleted on wine shutdown). If by any chance the socket is still present,
> > wine will still crash pretty fast.
>
> 10-4.
>
> because my ac kernel is crashing, i was gonna try redhat 2.4.20-2.48 (which
> is what gentoo gives me for "redhat-kernel").  but while i'm at it, i'll
> try bootstrap gentoo (which recompiles a bunch of core stuff, some of it
> twice, incl. glibc & gcc), compile wine, and see what happens.  guess i
> have to get the new kernel running first though.  maybe, this is too early
> a redhat kernel to trigger it... ?

Was reading through the newest news and wondered about Transgaming's fix.

[Joe Millenbach]

Did I read that correctly, in that they fixed whatever issues Wine has with 
glibc 2.3?  So that issue with threads being different would be fixed with 
this?

And if the above is true then are they planning to submit this to the Wine 
project or is this only for thier version?

Thanks for your time,
Joe Millenbach
_
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

Re: annoyance running mingw

[Steven Edwards]

Now all someone needs to do is build WINE on mingw running under WINE 


__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: Users Guide - added basic usage section

[Mike Hearn]

> Either we need to fix that doc, or we need to add
> a controllet for wine itself, so the list is never empty,
> or we need to make control.exe put up a dialog box
> saying "no control panel thingies installed".

Well, I think the plan is for Wine 0.9 to ship with pre-installed
control panel applets, so that bug won't appear, but you're right, it's
a silly bug if that's what it is and it should be fixed.

-- 
Mike Hearn <[EMAIL PROTECTED]>
QinetiQ - Malvern Technology Center

Re: Users Guide - added basic usage section

[Dan Kegel]

Mike Hearn wrote:
+  
+Some programs install associated control panel applets, examples of this 
would be
+Internet Explorer and QuickTime. You can access the Wine control panel by 
running:
+  
+
+  
+$ wine control
+  
+
+  
+   which will open a window with the installed control panel applets in it, as in 
Windows.
+  
Um, I tried running
  wine control
and it started running, then exited silently, presumably
because no apps have installed any controllet.
Either we need to fix that doc, or we need to add
a controllet for wine itself, so the list is never empty,
or we need to make control.exe put up a dialog box
saying "no control panel thingies installed".
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: gcc 3.2.2?

[Dan Kegel]

Gregory M. Turner wrote:
So, what can I expect from wine and gcc322?  Any known interestingnesses?
Anyone even tried it? Presumably, since the threading magic needs to be in the
kernel (I run a modified linux-2.4.21-pre4-ac5 atm), I will not get the pthread bug...
To get the new pthreads stuff, you need a new glibc and kernel.
gcc isn't really involved (except for new programs that use
the new style of thread-local storage).
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: annoyance running mingw

[Dan Kegel]

David Fraser wrote:
Seems to me the problem here is that mingw is passing these paths into
Wine at all. The only apparent way to get to DOSFS_GetPathDrive is
through DOSFS_GetFullName or DOSFS_GetShortPathName so either
mingw is calling one of those functions with Unix path names or its calling
some other Win32 API function with Unix path names which then calls
one of those functions.
But how would that work on Windows? Surely mingw should always convert
unix paths to Windows paths *before* giving them to any Win32 function?
These are 100% windows paths.  No conversion is needed.
Wine is just confused because Mingw is using the / path
separator instead of the \ path separator.
It may be a surprise to some, but that works A-OK in
Windows.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: x11drv, ntdll separation

[David Fraser]

Mike Hearn wrote:

What stage is the implementation currently at? According to the 
TransGaming docs, there are still a number of functions to fill in...
I would be interested in seeing a patch no matter how much/little is 
implemented ... because my main aim in getting rid of the fault handler 
is so that the x11drv can be ported to Windows...
   

Would that actually let you drop a file into MS Windows and suddenly
allow any windows app to be export via X11 at the API level?
If so, then all I can say is "whoa". If not, then, well, that'd be a
cool hack some day :)
 

Yup, that's the point ... will take quite a bit of work but until the 
x11drv and gdi32 dlls are separated out it's not even feasible ... if 
you're interested see http://sources.redhat.com/XOpenWin/ which is a 
currently quite dormant project to try do this. The relevant bugs for 
dll separation are:

http://bugs.winehq.com/show_bug.cgi?id=538  DLL Separation: x11drv from 
gdi32
http://bugs.winehq.com/show_bug.cgi?id=540  DLL Separation: x11drv from 
user32 (clipboard)
http://bugs.winehq.com/show_bug.cgi?id=542  DLL Separation: x11drv from 
user32 (misc)
http://bugs.winehq.com/show_bug.cgi?id=543  DLL Separation: x11drv from 
ntdll (FILE_DupUnixHandle)
http://bugs.winehq.com/show_bug.cgi?id=545  DLL Separation: x11drv from 
ntdll (VIRTUAL_SetFaultHandler)

David

Re: x11drv, ntdll separation

[Mike Hearn]

> What stage is the implementation currently at? According to the 
> TransGaming docs, there are still a number of functions to fill in...
> I would be interested in seeing a patch no matter how much/little is 
> implemented ... because my main aim in getting rid of the fault handler 
> is so that the x11drv can be ported to Windows...

Would that actually let you drop a file into MS Windows and suddenly
allow any windows app to be export via X11 at the API level?

If so, then all I can say is "whoa". If not, then, well, that'd be a
cool hack some day :)

-- 
Mike Hearn <[EMAIL PROTECTED]>
QinetiQ - Malvern Technology Center

Re: gcc 3.2.2?

[Michael Stefaniuc]

On Mon, Feb 24, 2003 at 08:51:43AM -0600, Gregory M. Turner wrote:
> On Monday 24 February 2003 03:24 am, Michael Stefaniuc wrote:
> > On Mon, Feb 24, 2003 at 01:44:27AM -0600, Gregory M. Turner wrote:
> > > from that or not?  Is there a test that is known to reliably break
> > > against the new threading model (or perhaps I can presume I "got it" if i
> > > can't run notepad?1)
> >
> > If you can run notepad you aren't affected by the bug because the bug is
> > merciless: the wineserver wont even start because it fails to create the
> > needed socket in /tmp/.wine-$user/server-XX/ (this stuff gets
> > deleted on wine shutdown). If by any chance the socket is still present,
> > wine will still crash pretty fast.
> 
> 10-4.
> 
> because my ac kernel is crashing, i was gonna try redhat 2.4.20-2.48 (which is
> what gentoo gives me for "redhat-kernel").  but while i'm at it, i'll try 
> bootstrap gentoo (which recompiles a bunch of core stuff, some of it twice, 
> incl. glibc & gcc), compile wine, and see what happens.  guess i have to get 
> the new kernel running first though.  maybe, this is too early a redhat 
> kernel to trigger it... ?
There should be a newer Red Hat kernel available in rawhide, at least
i'm running a newer one.

bye
michael
-- 
Michael Stefaniuc   Tel.: +49-711-96437-199
System Administration   Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart


pgp0.pgp
Description: PGP signature

Re: x11drv, ntdll separation

[David Fraser]

Johan Gill wrote:

Mike Hearn wrote:

And I have it in my tree :) It should be ready for submission in a 
few months from now.
  


Hvae you checked that it wouldn't be easier to merge in the TransGaming
implementation? It seems daft to duplicate work if that's the case...
 

It is their work, but I'm doing heavy changes.
What stage is the implementation currently at? According to the 
TransGaming docs, there are still a number of functions to fill in...
I would be interested in seeing a patch no matter how much/little is 
implemented ... because my main aim in getting rid of the fault handler 
is so that the x11drv can be ported to Windows...

David

Re: gcc 3.2.2?

[Gregory M. Turner]

On Monday 24 February 2003 03:24 am, Michael Stefaniuc wrote:
> On Mon, Feb 24, 2003 at 01:44:27AM -0600, Gregory M. Turner wrote:
> > from that or not?  Is there a test that is known to reliably break
> > against the new threading model (or perhaps I can presume I "got it" if i
> > can't run notepad?1)
>
> If you can run notepad you aren't affected by the bug because the bug is
> merciless: the wineserver wont even start because it fails to create the
> needed socket in /tmp/.wine-$user/server-XX/ (this stuff gets
> deleted on wine shutdown). If by any chance the socket is still present,
> wine will still crash pretty fast.

10-4.

because my ac kernel is crashing, i was gonna try redhat 2.4.20-2.48 (which is
what gentoo gives me for "redhat-kernel").  but while i'm at it, i'll try 
bootstrap gentoo (which recompiles a bunch of core stuff, some of it twice, 
incl. glibc & gcc), compile wine, and see what happens.  guess i have to get 
the new kernel running first though.  maybe, this is too early a redhat 
kernel to trigger it... ?

-- 
gmt
 

Re: x11drv, ntdll separation

[David Fraser]

David Hammerton wrote:

Hi,

I wrote some documentation a while back on this when we (TransGaming) 
submitted our dibengine to rewind/winehq.

You can read the docu at:
http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html
Hi

Thanks very much, this was very clear and I understand it now...

Basically its beacuse a DIBSection is like a mixture of a DIB and a HBITMAP, 
in that it has properties of both: The app can write directly to the pixel 
data while also being able to perform GDI operations on it, which we do 
through X. Because of the way X works we therefor have to have two copies of 
the DIBSection hanging around, and be able to sync them when required (eg, if 
the most 'up to date' version is in X, we need to know when the app tries to 
write to / read from the DIB so as we can sync them).

Seems to make sense except that I still have one question: the MSDN docs 
seem to indicate that you need to call GDIFlush() before performing any 
drawing operations to the bitmap yourself (at least for Windows NT). 
Would it be possible to keep a list of DIBSections and flush them all in 
GDIFlush, or is this not adequate?

And really - the best way to get rid of it is to finish the DIB engine :)
 

OK, that makes sense now that I understand what it does :-)

David

David

On Sat, 22 Feb 2003 22:36, David Fraser wrote:
 

Hi

I was wanting to do some work on x11drv dll separation.
The last remaining dll separation between x11drv and ntdll is
VIRTUAL_SetFaultHandler.
This is called from X11DRV_DIB_CreateDIBSection, where it tries to set
the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and
arg=res.
From reading the code it seems that this is done because it is not
known whether the calling app requires read or write access to the data
in bmp.  If the app then tries to read or write and doesn't have the
appropriate access, this will generate an exception which will then
raise the X11DRV_DIB_FaultHandler which would then set the appropriate
access, in a way that ensures data gets handled correctly.
I presume I'm misunderstanding this, because looking at MSDN for
CreateDIBSection, it says:
The CreateDIBSection function creates a device-independent bitmap (DIB)
that applications can write to directly.
and further down...
Windows NT: You need to guarantee that the GDI subsystem has completed
any drawing to a bitmap created by CreateDIBSection before you draw to
the bitmap yourself. Access to the bitmap must be synchronized. Do this
by calling the GdiFlush function.
So it would seem apps could always be given read-write access to this
bitmap.
Why is the special fault handler needed? What is the best way to
approach getting rid of it?
David
   

Re: Users Guide - added basic usage section

[Keith Matthews]

On Mon, 24 Feb 2003 14:17:41 +0100
Andreas Mohr <[EMAIL PROTECTED]> wrote:


> And BTW: why is it that once you decide to do some major work,
> EVERYBODY suddenly happens to come out of the eternally dark and dangerous
> and forgotten woods?? ;-)
> 


Looks like murphy wins again.

Re: Users Guide - added basic usage section

[Mike Hearn]

> Again, I'm currently working on a MAJOR update of the Guides.
> I'll incorporate these parts into my version.
> And BTW: why is it that once you decide to do some major work,
> EVERYBODY suddenly happens to come out of the eternally dark and dangerous
> and forgotten woods?? ;-)

Oops, sorry :) Well, just take it to mean that you chose a worthwhile
thing to work on. I look forward to the new guides :)

-- 
Mike Hearn <[EMAIL PROTECTED]>
QinetiQ - Malvern Technology Center

Re: (resend) tests for GetPrivateProfileInt

[Dmitry Timoshkov]

"Stefan Leichter" <[EMAIL PROTECTED]> wrote:

> > 2. Unicode and Ansi versions of GetPrivateProfileInt (as all other APIs)
> > should be tested separately.
> > 
> 
> Ok, but i did not understand what this statement means for my patch.

There is no such an API as GetPrivateProfileInt. Instead, there is a unicode
version GetPrivateProfileIntW and ANSI version GetPrivateProfileIntA. Your
patch should add tests for each (or at least for one) of them.

-- 
Dmitry.

Re: (resend) tests for GetPrivateProfileInt

[Stefan Leichter]

Dmitry Timoshkov wrote:
"Stefan Leichter" <[EMAIL PROTECTED]> wrote:


here are some tests for the function GetPrivateProfileInt. The expected 
results are the one from NT4. Hopefully the will match for Win 9x also.
Before i convert GetPrivateProfileInt from ascii to unicode i like to 
see some test result from Win9x/ME.

ChangeLog
-
Added test for GetPrivateProfileInt


1. The patch got wrapped by your mailer.
I will resend the patch when i'm back home.

2. Unicode and Ansi versions of GetPrivateProfileInt (as all other APIs)
should be tested separately.
Ok, but i did not understand what this statement means for my patch.

Bye Stefan

Re: (resend) tests for GetPrivateProfileInt

[Dmitry Timoshkov]

"Stefan Leichter" <[EMAIL PROTECTED]> wrote:

> here are some tests for the function GetPrivateProfileInt. The expected 
> results are the one from NT4. Hopefully the will match for Win 9x also.
> Before i convert GetPrivateProfileInt from ascii to unicode i like to 
> see some test result from Win9x/ME.
> 
> ChangeLog
> -
> Added test for GetPrivateProfileInt

1. The patch got wrapped by your mailer.
2. Unicode and Ansi versions of GetPrivateProfileInt (as all other APIs)
should be tested separately.

-- 
Dmitry.

Re: gcc 3.2.2?

[Michael Stefaniuc]

On Mon, Feb 24, 2003 at 01:44:27AM -0600, Gregory M. Turner wrote:
> 
> To my surprise, Gentoo (ACCEPT_KEYWORDS="", iow "stable" Gentoo) is
> ready to give me gcc 3.2.2 (in fact it compiles as I type).
> 
> So, what can I expect from wine and gcc322?  Any known interestingnesses?
> Anyone even tried it? Presumably, since the threading magic needs to be in the
> kernel (I run a modified linux-2.4.21-pre4-ac5 atm), I will not get the pthread 
> bug...
> but then again, how do I know for sure if I suffer from that or not?  Is there a test
> that is known to reliably break against the new threading model (or perhaps I
> can presume I "got it" if i can't run notepad?1)
If you can run notepad you aren't affected by the bug because the bug is
merciless: the wineserver wont even start because it fails to create the
needed socket in /tmp/.wine-$user/server-XX/ (this stuff gets
deleted on wine shutdown). If by any chance the socket is still present,
wine will still crash pretty fast.

bye
michael
-- 
Michael Stefaniuc   Tel.: +49-711-96437-199
System Administration   Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart


pgp0.pgp
Description: PGP signature

Re: annoyance running mingw

[Mike Hearn]

> Seems to me the problem here is that mingw is passing these paths into
> Wine at all. The only apparent way to get to DOSFS_GetPathDrive is
> through DOSFS_GetFullName or DOSFS_GetShortPathName so either
> mingw is calling one of those functions with Unix path names or its calling
> some other Win32 API function with Unix path names which then calls
> one of those functions.
> But how would that work on Windows? Surely mingw should always convert
> unix paths to Windows paths *before* giving them to any Win32 function?

I have a feeling the Windows path handling routines are very flexible,
and will accept unix style paths, I know you can use / instead of \ in
paths and things usually still work. I guess some test cases would be
needed.

> David
> 
-- 
Mike Hearn <[EMAIL PROTECTED]>
QinetiQ - Malvern Technology Center