On Thu, Oct 16, 2003 at 12:33:29AM -0400, Dimitrie O. Paun wrote:
> Agreed. Also, once we have the dynamic check, we should drop the
> UseXRandR config option, and just use it unconditionally. Let's
> be lazy, and wait until someone comes with a good enough reason
> to disable it. BTW, any conceiva
On October 15, 2003 08:09 pm, Kevin Koltzau wrote:
> One possible solution would be to call the PROFILE_* functions (which are
> located in kernel/profile.c) directly which seem to work in a way that
> would make this very easy, but overall sounds like a very bad idea...
Well, it is, it breaks DLL
On October 16, 2003 12:02 am, Alexandre Julliard wrote:
> Actually it's my version that is too old, it's one from XFree86 4.2
> and the Xrender call has been added after that, so it seems we don't
> have much choice. I'll put it back in the configure check for now, but
> we'll need to load libXrand
On October 15, 2003 11:21 am, Jason Filby wrote:
> This sounds good to me. As you said, it seems like headers are the
> big blocker here.
For my info, what's the problem with the headers? What headers are
you using? If not Wine's, why not? It seems we have better headers
than then w32api guys...
Alex Pasadyn <[EMAIL PROTECTED]> writes:
> I'm not really sure why that would be needed. What version are you
> using? Maybe I'm out of date? My system is RedHat 9 and I haven't
> done anything to upgrade the XFree86 (it's all version 4.3.0).
Actually it's my version that is too old, it's one
Alexandre Julliard wrote:
My version of Xrandr doesn't need Xrender so I hoped it wouldn't be
needed, guess I was wrong what does it need Xrender for?
The problem with the dependency is that currently we deliberately
don't link to libXrender but load it dynamically so that it works on
all platf
Alex Pasadyn <[EMAIL PROTECTED]> writes:
> But the version that made it into CVS did not include the -lXrender.
> At least on my system, the check fails without that because the Xrandr
> library itself calls functions in Xrender. Is there a better way to
> specify that dependency or was this unin
"Steven Edwards" <[EMAIL PROTECTED]> wrote:
> Wines user32 depends on a few direct Wineserver calls and has quite a
> bit of old design issues from the Win16 days that will need to be fixed
> first. Not to mention Unixisms in a few places and of course ReactOS
> Win32k-User32 commuincation system
Hi all,
I have just sent a post to the openssl list trying to solicit any
developers of openssl-based win32 programs to try their programs under
Wine. Eric Pouech helped me recently by fixing the one or two glitches in
Wine that the openssl libs and utilities were stumbling on, and so
openssl
When I originally submitted the patch to check for RandR during
configuration, part of it looked like this:
+AC_CHECK_HEADERS(X11/extensions/Xrandr.h,
+[ dnl *** If X11/extensions/Xrandr.h exists...
+AC_CHECK_LIB(Xrandr, XRRSetScreenConfigAndRate,
+
Within an msstyles file the primary specification is basically a unicode INI
file within one of the resources (well, there are a few ini files for
different parts of the theme)
Currently I'm extracting the ini file from resources into a temp file, and
then using GetPrivateProfile* to retrieve v
On Wed, 2003-10-15 at 10:57, Eric Kohl wrote:
> "Jason Filby" <[EMAIL PROTECTED]> wrote:
>
> > User32 and gdi32 are likely to be a problem as the bulk of our
> > implementation is in kernel mode win32k.sys.
>
> More problems will be caused by advapi32 and rpcrt4 because ReactOS will use
> LPC ins
Jon Griffiths <[EMAIL PROTECTED]> writes:
> Jon Griffiths <[EMAIL PROTECTED]>
> +include/wine/unicode.h libs/unicode/fold.c
> libs/unicode/Makefile.in libs/unicode/wine_unicode.def
> Add A/W string folding functions
I put the Unicode version in, but the Ascii one is wrong, you cannot
On Wed, 2003-10-15 at 13:45, Steven Edwards wrote:
> Hello All,
> Jason is right I think. I spoke with Alexandre the other night about
> implementing a Win32k.sys driver for WINE so we could use GDI32/User32
> and it might be do-able it wont be somthing that is possible for at
> least another year
--- "Gregory M. Turner" <[EMAIL PROTECTED]> wrote:
> There is a certain logic to this arrangement imo... who wants some
> wacky
> "explorer.exe" if they are simply thumbing through the kde or gnome
> menus?
> Not that I disapprove of ros explorer, quite the contrary! ros
> explorer
> approxima
Vincent Béron <[EMAIL PROTECTED]> writes:
> This caused rpm generation to fail because false returns 1.
>
> Changelog:
> Change the command to true rather than false if docbook is not
> installed.
If docbook is not installed then generating the doc should definitely
yield an error. You are free t
Le mer 15/10/2003 à 15:29, Gerhard W. Gruber a écrit :
> On Wed, 15 Oct 2003 19:14:28 +0200, Marcus Meissner <[EMAIL PROTECTED]>
> wrote:
>
> >I experience the same, this is due to a too old freetype2 library.
>
> Should I download a newer version instead of applying this patch?
The patch should
On Wed, 15 Oct 2003 19:14:28 +0200, Marcus Meissner <[EMAIL PROTECTED]>
wrote:
>I experience the same, this is due to a too old freetype2 library.
Should I download a newer version instead of applying this patch?
--
Gerhard Gruber
Für jedes menschliche Problem gibt es immer eine einfache Lösun
Hello All,
Jason is right I think. I spoke with Alexandre the other night about
implementing a Win32k.sys driver for WINE so we could use GDI32/User32
and it might be do-able it wont be somthing that is possible for at
least another year at the rate we are sharing code.
Wines user32 depends on a f
[EMAIL PROTECTED] writes:
> It looks to me like LPtoDP is just doing a linear transform, so the area should
> be preserved - the rectangle should be empty after the transform if and only if
> it is empty before the transform.
>
> Or am I missing something? Is there another reason to move the IsRe
On Wed, Oct 15, 2003 at 07:01:17PM +0200, Gerhard W. Gruber wrote:
> I downloaded a fresh CVS version from WineHQ and when I tried to compile it I
> got the following errors:
>
> freetype.c: In function `WineEngCreateFontInstance':
> freetype.c:1254: `FT_ENCODING_MS_SYMBOL' undeclared (first use i
I downloaded a fresh CVS version from WineHQ and when I tried to compile it I
got the following errors:
freetype.c: In function `WineEngCreateFontInstance':
freetype.c:1254: `FT_ENCODING_MS_SYMBOL' undeclared (first use in this
function)
freetype.c:1254: (Each undeclared identifier is reported onl
> That looks better yes; it's still a bit complex IMO, but I'm not sure
> it's possible to do much better with that glyph index thing. Still I'm
> wondering if you shouldn't do the IsRectEmpty check after the LPtoDP
> and coordinates swap.
It looks to me like LPtoDP is just doing a linear trans
Hi Vizzini
This sounds good to me. As you said, it seems like headers are the
big blocker here.
Regards
Jason
--- Vizzini <[EMAIL PROTECTED]> wrote:
> Steven and I spoke about this the other day, and I am in agreement
> with
> you, Dimitrie. I don't want to fork. We can use CVS to manage the
>
On Mon, 2003-10-13 at 10:03, Dimitrie O. Paun wrote:
> On October 12, 2003 03:03 pm, Steven Edwards wrote:
> > Well yes in the "should" work out of the box under ReactOS but most
> > dont work perfectly atm due to bugs in our Win32k/GDI/User32
> > implementaion. I agree it would be nice to keep bet
On Wed, 15 Oct 2003, Mike Hearn wrote:
> I might as well point out (as I didn't find this intuitive when I was
> learning) that you do that like this:
>
> 1) Open up a new terminal window
> 2) Run winedbg
> 3) "walk process"
> 4) Locate the win32 process id of the program that has deadlocked
> 5) "
Hi Dimitrie
User32 and gdi32 are likely to be a problem as the bulk of our
implementation is in kernel mode win32k.sys.
Regards
Jason
--- "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote:
> On October 14, 2003 03:11 pm, Jason Filby wrote:
>
> > I agree that forking should be avoided at all costs. O
"Jason Filby" <[EMAIL PROTECTED]> wrote:
> User32 and gdi32 are likely to be a problem as the bulk of our
> implementation is in kernel mode win32k.sys.
More problems will be caused by advapi32 and rpcrt4 because ReactOS will use
LPC instead of Unix-Sockets for local IPC.
Regards
Eric
On Tue, 14 Oct 2003 12:12:13 -0700, you wrote:
> Rein Klazes <[EMAIL PROTECTED]> writes:
>
> > The wine.conf man page says that in Snoop Include/Exclude specifiying
> > .* includes the whole dll.
> > This does not work: you have to specify without the ".*", at
> > least that is the code.
> >
>
On Tue, 2003-10-14 at 14:07, Dimitrie O. Paun wrote:
> Yes, winecfg still needs a lot of work. I think the version in the tree
> is fairly up-to-date.
That is correct, I have no outstanding patches as far as I'm aware. I'll
get back to it soon enough, still settling down and finding the best
hacki
On Wed, 2003-10-15 at 01:38, Alexandre Julliard wrote:
> > So, i cannot find the specific position, what to do now?
>
> Once it is deadlocked, you should attach to the various threads with
> gdb or winedbg and do a backtrace.
I might as well point out (as I didn't find this intuitive when I was
l
31 matches
Mail list logo
