wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

Microsoft's version of "WINE"
by Sander Wichers 23 Jan '02

23 Jan '02

Hi, Maybe you guys already seen this, and it's old news for you... but i'll post this anyway in case you didn't know. It can be a good thing to learn from. I do not own a SUN or a HP-UX system. But I was just interested how microsoft implemented IE 4 / IE 5 on HP-UX and SUN. So I extracted their installation files to disk. It seems that microsoft made their own version of wine. It's amazing that they didn't modified IE to run on unix. Instead they made the choice to emulate all the windows functionality. And compile IE on that. Microsoft is ready to run their applications on linux. They have a complete "system" libary full of ported functionality to SUN and HP-UX... all the libaries are there, libkernel32.so etc.... It's also nice to see how they seperated the resources from the binaries. and let the kernel deal with these resource files. Has any one of you looked into these system libaries? Is this information relevant to anyone? bye, Sander Wichers

1 0

Verbose tests ?
by Sylvain Petreolle 23 Jan '02

23 Jan '02

Hi, running programs/winetest/runtest -v -v -v -v -v tests/wine.pl or programs/winetest/runtest -vvvvv only reports : tests/wine.pl: 22 tests executed, 2 marked as todo, 0 failures. Is this the normal behavior or have I made something wrong ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

2 1

Open Letter to DOJ re Microsoft Settlement
by Dan Kegel 22 Jan '02

22 Jan '02

The proposed settlement in the Microsoft antitrust trial will probably be accepted by the judge unless a lot of people complain soon, even though it lacks any useful enforcement provisions and fails to prohibit many of Microsoft's anticompetitive practices. I've drafted an open letter to the Department of Justice to explain why the proposed settlement should not be accepted; it's at http://www.kegel.com/remedy/letter.html I'd be honored if you would read it, and consider signing it with me, or submitting your own comment to the DOJ. Either way, the federal deadline for public comment is Monday the 28th. For more information, see http://www.kegel.com/remedy/ See also Jeremy White's page http://www.codeweavers.com/~jwhite/tunney.html Sincerely, Dan Kegel

2 2

sparc solaris build
by Srdjan Matovina -- Customer Engineering 22 Jan '02

22 Jan '02

Hi, I've built wine-20011226 on sparc with the only one issue left open: The resource compiler wrc core dumps when hit the bitmap (BINRES) part of .rc file. There is an alignment problem inside convert_bitmap() in newstruc.c file. The alignment problem came out from BITMAPINFOHEADER struct. But this was just the beginning! I've commented out body of convert_bitmap() just to see what will happen when run libtest/hello test case. After running wineserver, the libtest/hello core with the same problem: Program terminated by signal BUS (invalid address alignment). This time at different place: RtlSecondsSince1970ToTime from ntdll.so (time.c) struct FILETIME. Obviously I'll have an alignment problem with every structure in general. Is there any guideline for this kind of problem? Thanks Srdjan

2 1

Re: [PATCH] Overlapped recv(), WSARecv()
by Martin Wilck 22 Jan '02

22 Jan '02

As you may see from the different email address, I am currently off work - I'll look deeper into your traces next week. Many thanks for generating them, anyway. >From a first glance, it seems that the app doesn't do overlapped recv(). (lpOverlapped & completion_func are always NULL), so there should actually be no difference (well I'm now using recvmsg() instead of recv(), and the overhead for 16 bit Winsock apps is definitely larger, but I cannot see why that should slow everything down that much). Perhaps I screwed up the blocking semantics of non-overlapped IO. Have you generated the traces under exactly the same conditions? Can you explain what exactly you did? Martin

3 7

Article about WINE on DesktopLinux.com
by Roland 22 Jan '02

22 Jan '02

Hello, I found a very interesting article about WINE there: http://www.desktoplinux.com/articles/AT5502857506.html I have to fully agree with that author, I think he is a real genius! :))) Roland

1 0

Re: Decorationless managed windows again
by Alexandre Julliard 21 Jan '02

21 Jan '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The logic in this patch is now somewhat revised according to Alexandre's > comments. I did not make this configurable, though, thinking that if the > user's WM really is too old to support them, then he probably wouldn't > mind getting more top-level windows managed anyway... Top-level windows maybe not, but menus and tooltips with wm decorations are pretty annoying... so I applied it, but without the is_window_managed changes, we will need a better algorithm there. -- Alexandre Julliard julliard(a)winehq.com

2 4

Re: Some fixes for dumb X errors :-)
by Alexandre Julliard 21 Jan '02

21 Jan '02

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > PS for Alexandre: we once discussed how we could 'streamline' this X error > handling (ie to prevent doing the same kind of code at three different > locations in the Wine code). Did you progress on this issue or not ? Yes, here's what I came up with. Basically you have to wrap the call that might fail with X11DRV_expect_error/X11DRV_check_error. Would this work for what you need to do? Index: dlls/x11drv/x11drv_main.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.47 diff -u -r1.47 x11drv_main.c --- dlls/x11drv/x11drv_main.c 2001/11/30 23:15:32 1.47 +++ dlls/x11drv/x11drv_main.c 2002/01/21 18:58:48 @@ -63,6 +63,12 @@ static char *desktop_geometry; static XVisualInfo *desktop_vi; +static x11drv_error_callback err_callback; /* current callback for error */ +static Display *err_callback_display; /* display callback is set for */ +static void *err_callback_arg; /* error callback argument */ +static int err_callback_result; /* error callback result */ +static int (*old_error_handler)( Display *, XErrorEvent * ); + #define IS_OPTION_TRUE(ch) \ ((ch) == 'y' || (ch) == 'Y' || (ch) == 't' || (ch) == 'T' || (ch) == '1') #define IS_OPTION_FALSE(ch) \ @@ -97,12 +103,57 @@ } #endif /* NO_REENTRANT_X11 */ + +/*********************************************************************** + * X11DRV_expect_error + * + * Setup a callback function that will be called on an X error. The + * callback must return non-zero if the error is the one it expected. + * This function acquires the x11 lock; X11DRV_check_error must be + * called in all cases to release it. + */ +void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ) +{ + wine_tsx11_lock(); + XSync( display, False ); + err_callback = callback; + err_callback_display = display; + err_callback_arg = arg; + err_callback_result = 0; +} + + +/*********************************************************************** + * X11DRV_check_error + * + * Check if an expected X11 error occurred; return non-zero if yes. + * Also release the x11 lock obtained in X11DRV_expect_error. + */ +int X11DRV_check_error(void) +{ + int ret = err_callback_result; + XSync( err_callback_display, False ); + err_callback = NULL; + wine_tsx11_unlock(); + return ret; +} + + /*********************************************************************** * error_handler */ -static int error_handler(Display *display, XErrorEvent *error_evt) +static int error_handler( Display *display, XErrorEvent *error_evt ) { - DebugBreak(); /* force an entry in the debugger */ + if (err_callback && display == err_callback_display) + { + if ((err_callback_result = err_callback( display, error_evt, err_callback_arg ))) + { + TRACE( "got expected error\n" ); + return 0; + } + } + if (synchronous) DebugBreak(); /* force an entry in the debugger */ + old_error_handler( display, error_evt ); return 0; } @@ -297,6 +348,7 @@ screen = DefaultScreenOfDisplay( display ); visual = DefaultVisual( display, DefaultScreen(display) ); root_window = DefaultRootWindow( display ); + old_error_handler = XSetErrorHandler( error_handler ); /* Initialize screen depth */ @@ -328,11 +380,7 @@ */ TSXOpenIM( display, NULL, NULL, NULL); - if (synchronous) - { - XSetErrorHandler( error_handler ); - XSynchronize( display, True ); - } + if (synchronous) XSynchronize( display, True ); screen_width = WidthOfScreen( screen ); screen_height = HeightOfScreen( screen ); Index: include/x11drv.h =================================================================== RCS file: /opt/cvs-commit/wine/include/x11drv.h,v retrieving revision 1.95 diff -u -r1.95 x11drv.h --- include/x11drv.h 2002/01/04 18:27:45 1.95 +++ include/x11drv.h 2002/01/21 18:59:08 @@ -391,7 +391,9 @@ extern void X11DRV_SetFocus( HWND hwnd ); extern Cursor X11DRV_GetCursor( Display *display, struct tagCURSORICONINFO *ptr ); -extern void X11DRV_expect_error( unsigned char request, unsigned char error, XID id ); +typedef int (*x11drv_error_callback)( Display *display, XErrorEvent *event, void *arg ); + +extern void X11DRV_expect_error( Display *display, x11drv_error_callback callback, void *arg ); extern int X11DRV_check_error(void); extern void X11DRV_register_window( Display *display, HWND hwnd, struct x11drv_win_data *data ); extern void X11DRV_set_iconic_state( WND *win ); -- Alexandre Julliard julliard(a)winehq.com

1 0

Some musings about DGA2 support in Wine...
by Lionel Ulmer 21 Jan '02

21 Jan '02

Hi all, After being prodded by people on #WineHQ to look at the current DGA2 problem in Wine (it it works fine for graphics, but does not accept any user input at all and needs to either kill Wine remotely or do the three finger salute to the X server), I found the following things : - the DGA2 code (in dlls/x11drv/dga2.c) used the gdi_display connection to open the framebuffer and setting-up all the input handling. But it was the thread->display connection that was used to process the events. This is a no-go as when DGA2 is entered, there is only one connection that receives the event, the one which has grabbed the frame buffer (thanks to Ove to remind me of the 'one connection per thread' thingy). - so I removed all the mentions to 'gdi_display' in dga2.c and replaced them by the current thread display and still no go (although I checked that the event processing in WaitForMultipleEvents and subsequent process_events was done on the correct display). Still no go. So I investigated a bit with a little test program : = I did first try setting up DGA2 in a separate display and then doing all the 'standard' processing on another display (that is Wine does with DGA2 set-up in the init function to test if DGA2 is available and then really use it in another thread). As my test application still was working fine, this was not the problem... = then, I saw in the logs some calls to X11DRV functions after we have entered DGA2 (some due to the DDraw stuff creating DIB sections and so on, some due to the application I think). After adding the same stuff in my test program (ie I created a window just after entering DGA2), I found that it perturbed the event processing (I still had motion events, but neither key presses nor button presses). - so, finally, just to try, I backed off my changes in dga2.c (ie I used again the gdi_display for all the set-up) and had the process_events function in windows/x11drv/event.c use gdi_display instead of data->display when DGA was used (by testing the DGAUsed variable). And now it seems to work just fine.... All this leads now to the 10 � (an Euro sign for all the people not having an iso8859-15 font :-) ) question : how to fix this 'properly' and not with the hack I just did ? The only somewhat 'clean' solution I found would be to create a display connection specifically used for DGA2 (thus we would be sure that no X calls would 'pollute' the link). And in process_events, if DGA2 is used, use this connection instead of the thread connection (we already have some DGA specific variables there, what would be one more :-)) ). After, the question would be how we are sure that it's the 'good' WaitForMultipleEvents that receives the events (if the application is multi-threaded and has multiple threads calling this function). Anyway, if people want just to play some games using DGA2, they can always use my hacky solutions I just described up there :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: _UNICODE vs UNICODE
by Andriy Palamarchuk 21 Jan '02

21 Jan '02

Francois Gouget wrote: > On Fri, 18 Jan 2002, Andriy Palamarchuk wrote: > > Using macro name "UNICODE" instead of "_UNICODE" is a > > typo, right? > > No, not necessarily. Windows has both and dinput.h, > for instance, > uses UNICODE, not _UNICODE. > > But I have no idea why they have two. I did a little research and found in a few places information that UNICODE is used by Windows headers, _UNICODE is used by C-runtime/MFC headers. However I did not find official explanation of this. Some examples, including a few MSDN ones, define both. E.g. see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_e… Can you tell now where we need to use which one? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel