Re: Winelib + Unicode
Hi, Use gcc 2.97 with -fshort-wchar. Well, this was for VWCL, and I wanted to make the price of entry as low as possible for the existing win programmers, so I've gone for another solution; since its a C++ framework its sufficient to use #define VTEXTW(str) wine_unicode_text(L##str) and give -fwritable-strings, which is working. I'll put CVS gcc on the ever increasing list of things to look at in the future :-) Thanks, Jon -- "Once you realise you're not _meant_ to fit in, it all makes sense..." [EMAIL PROTECTED] , [EMAIL PROTECTED]
MW4
Heya guys, Just a quick question has anyone gotten MechWarrior 4 to work in wine yet?? If so if you can could you tell me how? When i say "wine setup.exe" from the CD it doesnt build anything. Just wondering if anyone got the same problem or got it to work. Thx Nick Hudson
I've tried to change keyboard table.. No good...
Hi again. Well, I've looked up the keyboard code, searched for the problem and changed the keyboard table... Well... I can't get DeadKeys to work... Is it or not a "feature" at this point? (thanks Gerard, for your anwer ;-) ) I am asking this particulary to people in france or other that have dead keys ... do they work for you? The thing that bothers me the most is that I can't get my \ and | keys to work ... But I cant find anything wrong in the keyb table... SO what do you think? Maybe I should try to exchange my keyboard in Xfree settings first? I cant find out what I'm doing wrong... Thank you! Joao Pedro Clemente jpcl @ rnl.ist.utl.pt (when not working out) (when not sleeping) (when not surfing) (when not ... ;)
Problems with Ultima Online
Hi, I have some serious problems with Ultima Online. The last few weeks UO crashes with a divide by zero error: fixme:midi:OSS_MidiInit Synthetizer support MIDI in. Not supported yet (please report) fixme:midi:OSS_MidiInit Synthetizer support MIDI in. Not supported yet (please report) err:wave:DSDB_MapPrimary (0x403ae11c): Could not map sound device for direct access (errno=5) fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403ae1c0,01d8,3):stub fixme:pthread_kill_other_threads_np Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np xterm: unable to open font "vga", trying "fixed" The debugger says this: Unhandled exception: divide by zero in 32-bit code (0x409e1e59). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x409e1e59 (DSOUND_RecalcFormat+0x69 [dsound_main.c:955]): divl 0xfff4(%ebp),%eax 955 while (dsb-buflen % fraglen) fraglen -= sw; I am using SuSE 7.0. I think I have the problem since I upgraded from a single cpu to two cpus. But everything else is fine. System Specs: SuSE 7.0, kernel 2.2.16-SMP, alsa 0.5.10a XFree86 4.0.2 KDE 2.0.1 Dual PIII 500 256 MB Elsa TNT Vanta / Matrox Millenium II SB Live! / SB AWE 32 Bye -Josef Wegner
Re: Initial stubbing of shdocvw.dll (IWebBrowser)
[NOTE: I'm not subbed to wine-devel, I'm posting this from the WWN link] Just saw the bit in WWN about Mozilla and IWebBrowser, and thought I'd better tell you guys that a lot of this work's been done already: http://www.iol.ie/~locka/mozilla/mozilla.htm -- Yoz + Yoram (Yoz) Grahame [EMAIL PROTECTED] http://www.yoz.com + + Technical Architect Sparza.com, Bright Station plc + + W:44/0-20-7925-7745 H:8346-6062 M:44/0-7866-585287 + + all your base are belong to us +
Re: Winelib + Unicode
Jon Griffiths wrote:
Hi,
Use gcc 2.97 with -fshort-wchar.
Well, this was for VWCL, and I wanted to make the price of entry as low as
possible for the existing win programmers, so I've gone for another solution;
since its a C++ framework its sufficient to use
#define VTEXTW(str) wine_unicode_text(L##str)
and give -fwritable-strings, which is working. I'll put CVS gcc on the ever
increasing list of things to look at in the future :-)
Well, if you're willing to modify your code then you should probably
use WINE_UNICODE_TEXT. That's because:
* it supports both chars and strings, i.e. you can write:
WINE_UNICODE_TEXT('c') as well as WINE_UNICODE_TEXT("string")
I agree that it's a bit ugly but I had to do it because that's what
they do with OLESTR in the MFC! In C I believe you will have warnings
(but at least it will compile and do the right thing). You might want to
have two macros instead.
* it will do the right thing when you switch to g++ 2.97, i.e. it will
become L##x
Of course the name is a bit long (and it's WINE specific) so you
could do:
#define VTEXTW(x) WINE_UNICODE_TEXT(x)
--
Franois Gouget
[EMAIL PROTECTED]
Wine for LINUX on S390
Has anyone tried to port Wine to run on LINUX on an IBM mainframe? We are running several LINUX virtual servers of different distributions and would like to try running WINE. So far when I run the /tools/wineinstall I get the error that I must add my CPU CONTEXT to WINNT.H.
Re: Wine for LINUX on S390
On Wed, 17 Jan 2001, Jim wrote: Has anyone tried to port Wine to run on LINUX on an IBM mainframe? We are running several LINUX virtual servers of different distributions and would like to try running WINE. So far when I run the /tools/wineinstall I get the error that I must add my CPU CONTEXT to WINNT.H. AFAIK, no one has tried yet. Also you would not be able to run Intel Windows applications on an S390 because 'Wine Is Not an Emulator'. But you could use Winelib to recompile Windows applications for the S390. Go ahead and be the first on your block to run Windows (Winelib really) applications on an IBM mainframe! -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".
Winelib status
What's up with winelib these days? I found a windows app that runs great under Wine in emulation mode with out any windows dlls. I'd like to make an easy to distribute/setup/run version of it. Would porting with winelib or wint+libs+app be the easiest? smallest? best? I don't have the source code yet, but can probably get it from the author for the purpose of porting it. FWIW, it a shareware pinochle game. -Thomas
win16 printer driver discovery
Hi all, http://support.microsoft.com/support/kb/articles/Q133/0/90.asp A Windows 95 printer driver should only use thunks in calls to the ABORTDOC, ENDDOC, NEWFRAME, NEXTBAND and STARTDOC subfunctions of its Control() function. If a Windows 95 printer driver thunks in any call other than a ABORTDOC, ENDDOC, NEWFRAME, NEXTBAND or STARTDOC call, the Windows graphics device interface (GDI) may become reentrant. Because the GDI was never designed to be reentrant, the system may be left in an unstable state or errors may occur. If the printer driver thunks or yields, this causes the Win16Mutex system semaphore to be released and another thread may enter the GDI. I'm not sure whether this is related to our Win16 printer driver problem. Does this provide any clue as to how we're allowed to solve our win16 printer driver deadlocks ? This description smells to me as if Win95 doesn't have any form of GDI object locking... Andreas Mohr
Re: Wine for LINUX on S390
Francois Gouget wrote: On Wed, 17 Jan 2001, Jim wrote: Has anyone tried to port Wine to run on LINUX on an IBM mainframe? We are running several LINUX virtual servers of different distributions and would like to try running WINE. So far when I run the /tools/wineinstall I get the error that I must add my CPU CONTEXT to WINNT.H. AFAIK, no one has tried yet. Also you would not be able to run Intel Windows applications on an S390 because 'Wine Is Not an Emulator'. But you could use Winelib to recompile Windows applications for the S390. Go ahead and be the first on your block to run Windows (Winelib really) applications on an IBM mainframe! Well, actually I did try it some time back ... While I just did a quick hack, I got at least WineMine running. Now that Winelib is a bit cleaned up (Sparc runs out of the box), it would probably be not too difficult to properly implement S/390 support, or in fact support for any 32-bit architecture (64-bit is an entirely different story). I didn't pursue it further because I wasn't sure there's really anybody interested in running Wine on S/390. But if you'd like to try it, I could certainly contribute the arch-specific patches. [ B.t.w. I'm now working for IBM on the Linux for S/390 port. That's why I am quite familiar with the architecture ... ;-) ] Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: QUEUE_WaitBits race condition
Ulrich Weigand wrote: Ove, could you try whether this solves your deadlock? Bye, Ulrich ChangeLog: * include/queue.h windows/queue.c windows/message.c Protect queue-wakeBits/changeBits/wakeBits by critical section. Any reason this hasn't been checked into CVS yet? It seems to solve that deadlock issue, according to Ove. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com [EMAIL PROTECTED]
An icky inter-thread messaging deadlock
We've run into a bit of a nasty issue with the DDraw OWN_WINDOW code. This code exists to create a fake 'full screen' window for DDraw apps that ask for exclusive full-screen control. The window is created in dlls/ddraw/dsurface/user.c. It gets created in the DDraw update thread that is used to periodically refresh that window. As the thread starts, it creates the window and uses SetWindowPos to position it and show it. We have to create the window in the update thread, since there's no guarantee that the thread that puts DDraw into full-screen mode has a message loop. The problem arises here: in the call to SetWindowPos, we end up calling EVENT_Synchronize, which tries to send a focus-change message to a window in the main thread. The inter-thread SendMessage in the update thread then blocks, waiting for a reply. In the meantime, the main thread goes about it's merry way, and in the case below, tries to initialize Direct3D. For various reasons, this also requires us to do a SetWindowPos call on the full-screen window. Problem is, that the update thread is holding the SysLevel lock, but it can't release it until the main thread processes the focus-out message. A trace is included below We're at a bit of a loss for coming up with a reasonable solution here. We could peek for messages in the main thread immediately after creating the update thread, but this seems not quite right. Oddly enough, putting a sleep(1) immediately after creating the update thread allows the main thread to get past the deadlock and into 3d rendering (which doesn't actually require the update thread), but the update thread still sits there waiting for the focus message to be processed for some reason. Suggestions anyone? Update Thread #0 0x402df634 in () #1 0x400f3b74 in () #2 0x400bf187 in wine_server_call (req=REQ_SELECT) at client.c:243 #3 0x400c3ac4 in WaitForMultipleObjectsEx (count=1, handles=0x49f96b60, wait_all=0, timeout=4294967295, alertable=0) at ../include/server.h:1622 #4 0x400c3906 in WaitForSingleObject (handle=1414155695, timeout=4294967295) at synchro.c:110 #5 0x40708c47 in QUEUE_WaitBits (bits=32768, timeout=4294967295) at queue.c:729 #6 0x406fc0d5 in MSG_SendMessageInterThread (hDestQueue=583, hwnd=432, msg=31, wParam=0, lParam=0, timeout=4294967295, flags=4096, pRes=0x49f96c2c) at message.c:888 #7 0x406fd761 in MSG_SendMessage (hwnd=432, msg=31, wParam=0, lParam=0, timeout=4294967295, flags=4096, pRes=0x49f96c2c) at message.c:1795 #8 0x406fd8a3 in SendMessageA (hwnd=432, msg=31, wParam=0, lParam=0) at message.c:1845 #9 0x407ba02a in EVENT_FocusOut (hWnd=432, event=0x49f96d58) at event.c:851 #10 0x407b95c9 in EVENT_ProcessEvent (event=0x49f96d58) at event.c:413 #11 0x407b8f4a in EVENT_ProcessAllEvents (arg=0) at event.c:200 #12 0x407b8fa2 in X11DRV_Synchronize () at event.c:214 #13 0x406f2c5e in EVENT_Synchronize () at event.c:23 #14 0x40719bc0 in SetWindowPos (hwnd=792, hwndInsertAfter=0, x=0, y=0, cx=0, cy=0, flags=9563) at winpos.c:2943 #15 0x407772da in User_create_own_window (This=0x40362004) at dsurface/user.c:320 #16 0x40777370 in User_update_thread (arg=0x40362004) at dsurface/user.c:352 #17 0x400c4a90 in THREAD_Start () at thread.c:276 #18 0x400c3cbe in SYSDEPS_StartThread (teb=0x49fa7000) at sysdeps.c:134 === Main Thread (gdb) bt #0 0x402df634 in () #1 0x400f3b74 in () #2 0x400bf187 in wine_server_call (req=REQ_SELECT) at client.c:243 #3 0x400c3ac4 in WaitForMultipleObjectsEx (count=1, handles=0x40564a14, wait_all=0, timeout=4294967295, alertable=0) at ../include/server.h:1622 #4 0x400c3906 in WaitForSingleObject (handle=84, timeout=4294967295) at synchro.c:110 #5 0x40058b72 in RtlpWaitForCriticalSection (crit=0x40745928) at critsection.c:190 #6 0x40058d07 in RtlEnterCriticalSection (crit=0x40745928) at critsection.c:240 #7 0x400c4138 in _EnterSysLevel (lock=0x40745928) at syslevel.c:77 #8 0x40710d0c in WIN_LockWnds () at win.c:55 #9 0x40710df8 in WIN_FindWndPtr (hwnd=640) at win.c:108 #10 0x407193be in SetWindowPos (hwnd=640, hwndInsertAfter=0, x=0, y=0, cx=0, cy=0, flags=9499) at winpos.c:2625 #11 0x407771aa in get_display_window (This=0x403606d8, pt=0x40564bf4) at dsurface/user.c:260 #12 0x40777263 in User_DirectDrawSurface_get_display_window (This=0x403606d8) at dsurface/user.c:301 #13 0x4075d54b in common_inst_OpenGL (rguid=0x1014c4c, surface=0x4036095c, device=0x40360ab8, d3d=0x40363da0) at d3ddevice/mesa.c:667 #14 0x4075df35 in d3d7inst_OpenGL (rguid=0x1014c4c, surface=0x4036095c, device=0x49800c7c, d3d=0x40363da0, vtable=0x40786500) at d3ddevice/mesa.c:966 #15 0x4076c518 in MESA_IDirect3D7Impl_CreateDevice (iface=0x40363da0, rguid=0x1014c4c, surface=0x4036095c, device=0x49800c7c) at direct3d/mesa.c:396 -- Gavriel
Re: win16 printer driver discovery
Andreas Mohr [EMAIL PROTECTED] writes: If a Windows 95 printer driver thunks in any call other than a ABORTDOC, ENDDOC, NEWFRAME, NEXTBAND or STARTDOC call, the Windows graphics device interface (GDI) may become reentrant. Because the GDI was never designed to be reentrant, the system may be left in an unstable state or errors may occur. If the printer driver thunks or yields, this causes the Win16Mutex system semaphore to be released and another thread may enter the GDI. I'm not sure whether this is related to our Win16 printer driver problem. Does this provide any clue as to how we're allowed to solve our win16 printer driver deadlocks ? No; what this says is that under Win95 GDI holds the Win16Mutex (which is not surprising since GDI is still mostly 16-bit code). This is also the reason Win95 GDI can run 16-bit drivers. If you want to do the same thing in Wine you have to make all of GDI (and most of USER too) hold the Win16 mutex all the time, which is not very nice... -- Alexandre Julliard [EMAIL PROTECTED]
Re: I've tried to change keyboard table.. No good...
"Francois Gouget" [EMAIL PROTECTED] wrote: Well, I'm not in France but I do sometimes use my qwerty keyboard in 'US-International' mode so that I can get some of these French characters... via dead-keys. Of course it seems like half the Unix applications don't support dead keys and the other half don't support accents. Actually support for dead keys can be implemented now, since Alexandre added support for composite unicode characters. I even wrote several tests to prove the concept and do 2-1 and 1-2 character conversions in WideCharToMultiByte and MultiByteToWideChar. But I have some problems: 1. Actually I don't know how to generate dead key sequence that will modify next character, because cyrillic has no this "feature". 2. Accent characters in different code pages has different mappings to unicode characters. Perhaps we just have to create internal table with mapping [combining character in code page] - [combining character in unicode]? Then in x11drv.ToUnicode just do check: if previous pressed key was a dead key, then convert both characters to unicode and do WideCharToMultiByte to combine them into a single character and MultiByteToWideChar to convert combined character to unicode? P.S. It was my thoughts. It they are too messy for you, excuse me - I have no strong understanding of dead keys at all, just results of reading DDK and trial and error.
Re: Winelib + Unicode
Hi, Of course the name is a bit long (and it's WINE specific) so you could do: #define VTEXTW(x) WINE_UNICODE_TEXT(x) In this case the macro is only used in c++, so I used what WINE_UNICODE_TEXT expands to in this context; this works for single chars and strings. I think to be realistic by the time msvcrt is ready (headers and all) for really heavy use (like switching the default to native), gcc 3.0 will be out and developers will once again have a choice between ms and libc crts. For now if you use Unicode and call win32 wc functions with u/c strings, your only choice is to either suffer the in development msvcrt or use a cvs gcc :-( Actually, having said that, have you tested -fshort-wchar? does it require libc to be rebuilt? or just to build with a different set of headers (i.e. lib funcs still cannot be used)? My assumption is that it just changes the behaviour of L'foo', and doesn't address the crt issues at all. I'm working on wide char functions in msvcrt now since thats whats preventing VWCL from working, and forms the largest slice of unimplemented functionality. I have VCWL (using msvcrt) compiling with some hacked up headers but need to implement some more wc funcs in order to get the first test apps running. After this I'll clean up the headers for submission and document the crt choices for the Winelib user guide. Following that theres the issue of adding the ms crt startup calls to winebuild, but I didn't get any feedback on that, so I'm letting it sit for a while ;-) Thanks for the feedback though. If I get time I might scribble up some docs on using unicode. Its taking a little getting used to, so it might be useful for others working with Winelib in the future... Cheers, Jon -- "Once you realise you're not _meant_ to fit in, it all makes sense..." [EMAIL PROTECTED] , [EMAIL PROTECTED]
Re: Winelib + Unicode
Jon Griffiths wrote: Hi, Of course the name is a bit long (and it's WINE specific) so you could do: #define VTEXTW(x) WINE_UNICODE_TEXT(x) [...] Actually, having said that, have you tested -fshort-wchar? does it require libc to be rebuilt? or just to build with a different set of headers (i.e. lib funcs still cannot be used)? My assumption is that it just changes the behaviour of L'foo', and doesn't address the crt issues at all. That's right, it does not address the crt issues at all. Actually it helps a little in that you can use the standard C library headers (e.g. to get wcslen) and then link with crtdll or msvcrt. But the libc C still expect 4byte Unicode chars and I don't expect this to change anytime soon. It would require two implementations of each Unicode function which means two versions of the library. -- Franois Gouget [EMAIL PROTECTED]
Re: Winelib status
On Wed, 17 Jan 2001, Thomas Dodd wrote: What's up with winelib these days? Only good things :-) I found a windows app that runs great under Wine in emulation mode with out any windows dlls. I'd like to make an easy to distribute/setup/run version of it. Would porting with winelib or wint+libs+app be the easiest? smallest? best? Both can work. I don't think either has a big edge. I think I would try to compile it but that's just because of my Winelib slant. Then you could also distribute in for Solaris Sparc and soon Mac OS X :-) Since your application runs well in Wine and does not require any MS library you should be able to compile it relatively easily. You said it does not depend on any MS dll. I assume this means it's not MFC-based which is a good omen (because if it's MFC based you'll have a lot of work just recompiling the MFC first). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *^%$#@ thing ever since. Resume: design before you implement.
Re: Winelib + Unicode
Actually it helps a little in that you can use the standard C library headers (e.g. to get wcslen) and then link with crtdll or msvcrt. This is what I was wondering; given that they expect wchar_t* and Winelib uses WCHAR* I assumed the headers would be useless. But the libc C still expect 4byte Unicode chars and I don't expect this to change anytime soon. It would require two implementations of each Unicode function which means two versions of the library. I think this sounds the end of the idea of the 3 crt scenarios (ms/libc/mixed) that were discussed before, for all but the most trivial apps. What is left is ms and mixed, where mixed still uses modified headers but uses the ignore directive in the apps .spec file to link to the libc implementation where desired (and where not already specified in msvcrt.spec). Cheers, Jon -- "Once you realise you're not _meant_ to fit in, it all makes sense..." [EMAIL PROTECTED] , [EMAIL PROTECTED]
Re: Winelib + Unicode
On Thu, 18 Jan 2001, Jon Griffiths wrote: Actually it helps a little in that you can use the standard C library headers (e.g. to get wcslen) and then link with crtdll or msvcrt. This is what I was wondering; given that they expect wchar_t* and Winelib uses WCHAR* I assumed the headers would be useless. Not so. Because when you us -fshort-wchar you are supposed to also define WINE_UNICODE_NATIVE and then the definition of WCHAR is: #ifdef WINE_UNICODE_NATIVE typedef wchar_t WCHAR, *PWCHAR; #else ... Thus the definitions of the Unicode functions in the standard C headers are just fine (but their implementation of course is not). But the libc C still expect 4byte Unicode chars and I don't expect this to change anytime soon. It would require two implementations of each Unicode function which means two versions of the library. I think this sounds the end of the idea of the 3 crt scenarios (ms/libc/mixed) that were discussed before, for all but the most trivial apps. What is left is ms and mixed, where mixed still uses modified headers but uses the ignore directive in the apps .spec file to link to the libc implementation where desired (and where not already specified in msvcrt.spec). I think that there are many Windows applications that don't really care about Unicode. These should not have too much trouble with the native C headers. Concerning Unicode I'm not sure that the mixed headers should override the definition provided by the native headers. I don't know. But for larger programs (or the MFC), the way to go really is to provide 'msvcrt' headers. Mixing native headers (or mixed headers for that matter) and crtdll/msvcrt tends to create problems (same thing for socket.h and winsock.dll). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
