Re: When will Wine integrate an x86 CPU emulator?
Lionel Ulmer wrote: Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net. Well, I looked at the site and did not see much there... Is there any design diocuments / roadmaps on how you plan to go forward that we could read so as to know how you plan to actually tackle the issues raised by all the people here ? ... The most useful part of the web site is the email list archive: http://sourceforge.net/mailarchive/forum.php?forum_id=26200 As you note, the substantive work to date has been that Pierre has made progress (to the point of running WinMine) in porting Winelib to OS X. My personal roadmap for Darwine-related activity is to try out the Winelib stuff myself and make a suitable Freshmeat announcement. Updating the web site a bit with some current status and some of this discussion is also a to do. I don't expect to be a development leader for any of this Wine-related stuff as I don't have much interest in running or porting Windows applications. I certainly have no interest in debating anybody on what or how to do anything. I do like communicating with others with whom I have a common interest. The most interesting activity on Wine with x86 emulation is QEMU. If that had existed last year then there wouldn't have been a Darwine. QEMU now has a mailing list: http://mail.gnu.org/archive/html/qemu-devel/ Jim -- I love deadlines. I love the whooshing sound they make as they fly by. -- Douglas Adams
Re: When will Wine integrate an x86 CPU emulator?
Francois Gouget wrote: On Wed, 20 Aug 2003, Ulrich Weigand wrote: [...] The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries. [...] Not only it would be extremely complex but I am not even sure it would be more efficient. ... How does that apply to the emulator case? Well, let's take InflateRect: ... I don't understand why you put effort into shooting down strawmen. If you are not interested in a version of Wine incorporating an x86 emulator then that's just dandy. The point of integrating the x86 emulation is not necessarily to get into the interface between Wine and the Windows applications. The point is to avoid a whole layer of OS emulation. I have no problem even with the idea that some of Wine's code remains x86 in order to avoid switching modes excessively. Consider Mac OS X. Using Wine for x86/Linux means running a second OS under emulation and an attendant extra file/device mapping layer. Also while it is obvious that an intermediate stage will be to use X, a futher improvement could be to use the native toolkit. And especially attractive from the x86 emulator's standpoint is the ability to identify read-only code resources with defined entry points that can be JIT compiled to native code rather than simply interpreting. The opportunities for doing that at the machine level for hosting an OS are much more limited. So while integrating x86 emulation with Wine certainly adds another whole set of complexity, the performance gains are easily attained because of the reduction in emulation layers which can readily run into order-of-magnitude performance penalities in all kinds of places as you illustrated. Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net. And there is no conflict here. Wine has more than a big enough chunk of work carved out for itself, and it is it's sucess there that brings the attention from other perspectives with interests in leveraging that value into other areas. We have a strong common interest in free and open software. Otherwise we'ld just buy Windows (and for Mac OS X, Virtual PC). Jim -- I love deadlines. I love the whooshing sound they make as they fly by. -- Douglas Adams
Re: When will Wine integrate an x86 CPU emulator?
Kelly Leahy wrote: Not sure I agree with paragraph two of the answer... ... I don't care for the answer much myself. Certainly never is not reasonable as Wine for non-x86 systems is desireable and eventually enough effort will be expended to get the job done. Now the time frame might be rather long, and for many folks the answer to When will Wine be finished? is effectively never because it is more than a year and the integrated emulation business is well beyond that. It would be nice to mention Darwine in connection with these Wine-for-other-systems FAQs as progress has been demonstrated with Winelib for Mac OS X and the stated goal is an eventual integrated x86 emulator. http://darwine.sourceforge.net/ That said, I do agree that before the integrated solution appears we will see Wine running on emulated X86/Linux. I'm particularly interested in seeing Linux on Darwin's Mach kernel which should benefit from the prior work of MkLinux. Jim -- I love deadlines. I love the whooshing sound they make as they fly by. -- Douglas Adams
Re: Mac OS X/Darwin port of Wine
Mike Hearn wrote: I'm suggesting you use it as a place to start the port. If you decide to make things hard for yourself due to some bizarre hatred of desktop Linux, then you're just increasing the amount of work you'd need to do. You don't even have to dual boot or anything, just stick it on an old PC and ssh into it if you absolutely must have glowing buttons. Old PC? All my old PCs have X86 processors and they're running Linux. Are you saying there are sources of extremely cheap PPC motherboards to stick in a PC chasis? (I don't think anybody has attempted Bochs integration before), it makes sense to get it out the way. But - if you want to leave it until later, you do it how you think is best. Bochs has full support for Mac OS X including a .dmg binary on their download page, so the port for that package is done already by the Bochs team. The tricky bit will be going from Bochs virtual machine approach to an in-process extension sort of deal. Mac OS X has had lots of attention from folks doing source level porting, notably the Fink group which has a Debian-based apt-get for a large number of the most used package. Even OpenOffice can launch and do a few things. But as I've said, I'm not really keen on making large changes in two directions at once. Hopefully some more folks with ideas and skills will get interested in Wine for Mac OS X. I think I will investigate the Linux compatible angle for a bit. I've already had some interest from some hard core Linux kernel hackers (although they seem pretty convinced Mach was the wrong solution, it is here to stay and at least the microkernel approach means we can neatly have multiple environments). Jim
Re: Mac OS X/Darwin port of Wine
Mike Hearn wrote: Do you have any references for those statistics? The figures came from this: ... You're mixing installed base numbers with new shipments (market share). Worthwile to note in this vein is Apple released their version of the XFree86 X11 server (rootless for Aqua) beta for Jaguar today. It includes direct GL support under 10.2.3. So while Apple's official position remains that Aqua is the right GUI, they're gonna have top notch X11 support too. I'm quite unlikely to set up a Linux/PPC box myself, although I am *very* interested in hearing from folks working on Wine for *any* PPC OS. Hmm, is there any reason for that? Linux/PPC would seem the logical place to start... Yes, of course there are reasons. If I wanted to use Linux for my desktop I would do so. I find Mac OS X to be the best desktop OS in the world. I do run Linux servers and find that an excellent way to put cheap x86 hardware to good use. I have been interested in ways to have Linux compatibility on Mac OS X (it is a microkernel system after all), so I will spend a little time investigating that. For Linux binary support you'd have to do a FreeBSD style ABI export. I'm thinking in terms of updating the MkLinux (Apple/OSF) port to the Darwin Mach kernel. Seems like there should be a way to do that as an addition to the Darwin OS and not run a separate system. What I'ld really like to see is Red Hat binary compatibility (the duplication necessary in source porting is largely a wasted in my view). The next logical step being an X86 personality too. Jim
Re: Mac OS X/Darwin port of Wine
Mike Hearn wrote: Supposedly Mac OS X already has the largest installed base of any single *nix distribution... Actually, according to figures from Apple and IDC (guess which is more neutral) desktop Linux has at least double and possibly quadruple the installed userbase of MacOS X. I have pointed this out several times when people make statements such as that, and have yet to be refuted, ... Do you have any references for those statistics? The thing that IDC just said is that they expect new Linux desktop shipments to pass new Mac OS X shipments within the next year or two. Even if that comes to pass (which I very much doubt), that doesn't directly address the installed base size. http://www.macobserver.com/columns/thebackpage/2003/20030103.shtml As CPU emulation would be one of the trickier parts, I'd definately go with the advice to start by making x86 binaries work on Linux/PPC, as that keeps the number of things that could interfere to a minimum. I'm reconsidering how to get started now. I spent a fair bit of the weekend trying to get Darwin/X86 running and it doesn't look promising. Not only do I need to get a different motherboard but it sounds like there are siginificant issues with bugs and performance. I'm quite unlikely to set up a Linux/PPC box myself, although I am *very* interested in hearing from folks working on Wine for *any* PPC OS. And this does seem like a promising area for Linux/PPC folk as I'm sure there would a fair bit of interest in being able to run Linux/X86 binaries (which would be cool with miscellaneous binary support). I have been interested in ways to have Linux compatibility on Mac OS X (it is a microkernel system after all), so I will spend a little time investigating that. But now (unless Darwin/X86 things improve quickly, which I doubt) the most likely way forward for me will be to tackle the problem directly with Mac OS X. Jim
Mac OS X/Darwin port of Wine
Hi Gang. A few weeks ago when I thought how cool it would be to marry Wine and Bochs to run Windows progams on Mac OS X Darwin, I checked around, including this list, and didn't find any activity. So I opened a SourceForge project to focus on just that goal: http://darwine.sf.net After I uploaded the home page tonight, I checked here again and found this topic had just come up last week! I don't know yet whether it makes sense to maintain a separate discussion and/or repository for this purpose. Seems like it would at least be useful during active initial work and then perhaps phase out. In any case, the resource is ready-to-use and I'ld like to hear from others interested in this port. Jim
Re: Mac OS X/Darwin port of Wine
Dan Kegel wrote: Lionel Ulmer wrote: We agreed that before starting with Wine, one could start with running, for example, Linux/x86 binaries on Linux/PPC. That would already validate the fact that you can draw the line at one point and from there run such an heterogenous environment. Hey, that's a good idea. Then you could install and run x86 linux packages, if you were really lucky. Might be useful for running proprietary packages where they don't bother to rebuild for linux/ppc. Yes, it would be terrific if someone were to do some porting for Linux/PPC. Wine and Bochs certainly work quite well with Linux. For my part, I plan to start with a trial port to Darwin/x86. If those two things happened in parallel, that would save a lot of time and definitely bring more expertise to bear on the many issues. Jim
Re: Mac OS X/Darwin port of Wine
Brian Vincent wrote: This issue comes up a few times a year (isn't it in a FAQ somewhere?) Anyway, take a look at these threads: Yes it is a bit of a FAQ, and the answers have mostly been along the lines of just use Winelib for non-Intel machines. Now it can be ... and checkout the Darwine BOF. Thanks for the links! Lionel Ulmer wrote: It's a very nice subject... A pitty it has such a low importance (seeing how X86 dominates the desktop market). Supposedly Mac OS X already has the largest installed base of any single *nix distribution and certainly is ahead of Linux on the desktop. So there are easily as many potential users of Wine for Mac OS X as Wine for X86-whatever. And Virtual PC has been popular successful. Dan Kegel wrote: Sounds like a plan to me. Hopefully your Wine tree won't drift out of sync with the main one like so many Linux kernel port trees do. Yep, keeping things in sync will be important. In checking out Winehq distrbution, I see that updates revolve arond the monthly tarballs. So that's where we'll start and try to keep up-to-date with that. Thanks for the encouragment! Jim
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: lstrlenA exception handling
Marcus Meissner wrote: server_call_noerr 279810 93.573 4025559 94.120 4049100 TryEnterCriticalSection 39993165 2.421104148 5.724246233 CRITSECTION_EnterCriticalSection 36801339 1.984 85331 11.492494402 CRITSECTION_LeaveCriticalSection 36801338 1.922 82694 5.577239904 __get_teb119747280 1.855 79819 1.855 79819 Why isn't it inlined? Its the same assembly code, just wrappered. send_request280074 0.539 23205 0.543 23378 lstrlenA 8145374 0.451 19381 0.690 29690 Why is it called so often? Excellent question, worth quantifing. I took a stab at it, but I haven't come up with anything. Could be coming from the app side, perhaps related to the registry. -Jim -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: Debugging question for MathType
Eric Pouech wrote: In the debugger, I used "x /d 0x409168bc" to find the lpType. The output is 0, the default, which I understand is a string. well, the type is REG_NONE... so not in every case a string Looking back at the Microsoft win32 api page that references the RegQueryValueEx function, I see where I mistakenly interpreted that the type defaults to string (It was referring to the default type when the value of LpValueName is null). Anyway, the registry key in question, "AppLang", has a value in the registry of "0x0409,enu" (at least in the ~/.wine/user.reg file). debugger's command sounds ok. be sure you use them at the right place (eg after the server's call has returned) (silly question I know) Yep, even double checked after receiving this email. Before the debugger gives a prompt the log file shows the following line (this line actuall occurs twice, identically): trace:reg:RegSetValueExA (0x28,"AppLang",0,1,0x405e7e3e,10) Here, the type is being set to 1 (string). As soon as the debugger prompt is available, x /s 0x405e7e3e gives _IP_EBP_28 Searching for references to this string in the log gives the following lines: 597 000118d0 0x4070c8d0 SMapLS_IP_EBP_28 ... 607 00011970 0x4070c970 SUnMapLS_IP_EBP_28 ... 597 000118d0 0x405f08d0 SMapLS_IP_EBP_28 ... 607 00011970 0x405f0970 SUnMapLS_IP_EBP_28 Once again, at the debugger prompt: x 0x4070c8d0 - x 0x4070c970 - x 0x405f08d0 - b9d6b7e8 x /s 0x405f08d0 - è·Ö¹ÿÃ (this is the same value returned by RegQueryValueEx in the LpData buffer later in the program) x 0x405f0970 - b9d617e8 x /s 0x405f0970 - èvÖ¹ÿÃ Looking at the memory/selector.c file, it seems that the SMapLS lines map a pointer (linear) to another pointer (segmented). I'm not sure exactly what this means (I'll have to research this later), but is it possible that this is where the registry key value is changed; or does everything look as expected? Looking again at the register value query call: Call advapi32.235: RegQueryValueExA(0040,004ac7c4 "AppLang",,409168bc,4091686c,409168b8) ret=00468b3f fs=008f The LpData is now 41012ec0 (x 0x4091686c). Assuming that this value is memory reference: x /s 0x41012ec0 - AppName I'm not sure I understand where this came from, unless there is a misdirected pointer or something. from the rest of the log, it may well be that the app is looking for the "good" DLLs, even if the names sound wrong to you, but it's hard to tell Any ideas on how I can try to find out how the filename string for the dll was created? I tried to enable the string debugmsg to look for relevant calls by looking for functions that addressed any memory locations occupied by the string, but was unsuccessful. Thanks for your help, Jim Shepherd [EMAIL PROTECTED]
Re: Debugging question for MathType
I am still trying to solve the infinite loop problem I reported earlier, but I am running into some difficulty debugging it further. Note: I am new to debugging and could be making a lot of mistakes. To compile, I disbaled optimizations by removing the -O2 parameters from the configure file and used: ./configure --disable-lib make depend make Then "make install" as root. I used the following command to launch the app: winedbg -managed -debugmsg +reg,+relay,+module,+win32,+advapi "/dos/Program Files/MathType/MathType.exe" mathtype.log The entire log file can be found at: ftp://ftp.mindspring.com/users/jimshep/mathtype.log.gz Here are what I believe to be the relevant lines: Call advapi32.227: RegOpenKeyExA(8001,41012d90 "Software\\Design Science\\DSMT4\\Config",,00020019,409168cc) ret=00468b11 fs=008f trace:reg:RegOpenKeyExA (0x8001,"Software\\Design Science\\DSMT4\\Config",0,20019,0x409168cc) Ret advapi32.227: RegOpenKeyExA() retval= ret=00468b11 fs=008f Call advapi32.235: RegQueryValueExA(003c,004ac7c4 "AppLang",,409168bc,4091686c,409168b8) ret=00468b3f fs=008f trace:reg:RegQueryValueExA (0x3c,"AppLang",(nil),0x409168bc,0x4091686c,0x409168b8=50) In the debugger, I used "x /d 0x409168bc" to find the lpType. The output is 0, the default, which I understand is a string. I then used "x /s 0x4091686c" to find lpData. The output was à*`A#(@ (It should read "0x040,enu". I used the same debug commands on previous RegQueryValueExA calls and was able to see the appropriate keys. Are these commands incorrect in this case, or is the function returning the wrong data? Ret advapi32.235: RegQueryValueExA() retval= ret=00468b3f fs=008f Call advapi32.204: RegCloseKey(003c) ret=00468b57 fs=008f trace:reg:RegCloseKey (0x3c) Ret advapi32.204: RegCloseKey() retval= ret=00468b57 fs=008f Call kernel32.425: GetUserDefaultLCID() ret=00468f66 fs=008f Ret kernel32.425: GetUserDefaultLCID() retval=0409 ret=00468f66 fs=008f Call kernel32.342: GetLocaleInfoA(0409,0003,4091677c,00ff) ret=004281c2 fs=008f Ret kernel32.342: GetLocaleInfoA() retval=0004 ret=004281c2 fs=008f Call kernel32.534: MultiByteToWideChar(,,4091677c "ENU",,41012e10,0004) ret=004026bd fs=008f Ret kernel32.534: MultiByteToWideChar() retval=0004 ret=004026bd fs=008f Call kernel32.727: WideCharToMultiByte(,,40916898 L"ENU",,41012ea0,0007,,) ret=004026dc fs=008f Ret kernel32.727: WideCharToMultiByte() retval=0004 ret=004026dc fs=008f Call kernel32.250: FindFirstFileA(41012190 "C:\\Program Files\\MathType\\Language\\MT4ENU.DLL",40916618) ret=0048c8c9 fs=008f Ret kernel32.250: FindFirstFileA() retval= ret=0048c8c9 fs=008f I believe that this call should be looking for mswenu.dll or *enu.dll instead of MT4ENU.DLL since there are no files beginning with MT4 in that directory and the file mswenu.dll is the only one with the enu suffix. I tried to find any calls in the log file that have written anything to the addresses between 0x41012190 and the end of the string, but was notable to find any. How do I find out how the string that starts at 0x41012190 was created? The rest of the log shows the looping problem. I also noticed that a couple of the links on the website, under the References page need to be updated: Microsoft link to win32 api: http://msdn.microsoft.com/library/psdk/portals/win32start_1n6t.htm Overview: http://msdn.microsoft.com/library/psdk/buildapp/win32api_7f8p.htm Reference: http://msdn.microsoft.com/library/psdk/psdkref/alphafunc_3bjm.htm Thanks for the help, Jim Shepherd [EMAIL PROTECTED]
Re: Corel WINE team at Ottawa Linux Symposium
Traditionally there is a party each night hosted by a local Linux company(Corel's is Thursday). Free food and open bar is part of the tradition. I suggest it would be a good place to start. Though it might be difficult to do any damage to the party fund. ;-\ They are also centered in the Market area of Ottawa, within 5 minutes walking distance to 100 bars/pubs/restaurants. So might be a convenient place to start/depart from. Restaurants: Hard Rock, Heart Crown: Pub food, but good beer. Westin Hotel: 3* Blue Cactus: mexican Nickles: diner food Italian? other?... -Jim Jeremy White wrote: Alexandre and I will be there starting Wednesday. Being a strong backer of Wine, I feel it's important to support Wine and all of its traditions. For some reason, helping to spend the Wine party fund is one I seem to feel especially strongly about...g I think we should have a Wine developers gathering. Dinner? Wednesday night? I've never been to Ottawa; anyone have any suggestions for where/when? Jeremy Jeff Tranter wrote: Just a note that the Corel WINE team will be at the Ottawa Linux Symposium coming up next week on July 19th to 22nd. There are no formal WINE presentations scheduled, and apparently they aren't accomodating BOF sessions, but we could set up some informal discussions with other WINE developers who are there. It was a great event last year. Unfortunately, if you haven't already registered for the conference then you are out of luck as it is sold out. For more details see http://www.ottawalinuxsymposium.org/2000 -- Jeff Tranter Project Leader, Linux Development (Wine team), Corel Corporation The free download of Corel PHOTO-PAINT for Linux is now available. Check it out at http://linux.corel.com/products/pp9 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]". -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
BorCon Trip Report (long)
George Boutwell wrote: I was wondering if someone from Code Weavers good give a blurb about how they felt things at BorCon went. I was at BorCon, stopped by their booth (was glad to see them there), and wasn't able to make it to the Birds of a Feather Session they had and would like to know how that did (or didn't) go. Thanks. I was at BorCon for CodeWeavers. I hosted the BOF on "Using Wine to Port Application Software to Linux" and also gave a talk on "Porting Windows Application Software To Linux" (which really covered all of the tools, technologies, and techniques). I also worked in the booth all day Tuesday and Wednesday. CodeWeavers also had a BOF on porting Delphi code to Linux using Wine, but I missed that one, so can't talk about how it did. Overall impression: good show, lot's of interest and enthusiasm in both Linux and Wine. --- The BOF --- The BOF was surprisingly well attended, especially since it started at 7:00am on the last day of the conference. We had about 30 people in all, mostly windows application developers using C/C++ | Delphi. I spent about 30 minutes simply talking about what Wine is, what it does, it's history, and status. It turned out to be a great forum for educating the audience about Wine, since many of them were highly pessimistic about it (complaints about it not being able to run Word or Excel are all too common - argh). Most of the questions that came in related to winelib, which I was glad to talk about (beats having to discuss why Quicken won't work!). Most of the audience had never heard of it, and even those that had misunderstood its purpose. The only complaints that came in were in regard to it not being perfect (duh) and the "poor" documentation. Other than that, it was really well received. I really blew them away at the end when I showed them MS PowerPoint2000 running on Wine (thanks to all of you!). They were also excited about the future of Wine. In fact, when I discussed the objectives/goals of Wine 1.0, it generated a lot of discussion, and certainly a lot of enthusiasm. What surprised me though, is that the 1.0 discussion was not about "cool, it'll work with all of my windows apps," but instead, "cool, it'll work well with some of my windows apps," and "cool, it will be better documented and easier to install/configure." The Talk The talk focused on tools and technologies that are available for deploying windows software on linux. I covered everything from VMWare to (what I call) "pure porting" (using Xlib/Xaw/Xm/libc, etc.). I focused on teaching the differences between the technologies, and showing what's good and bad about each. I emphasized Wine and winelib quite a bit, but again had to educate the audience about what it is. I think most of the audience agreed that, even if it's not your final solution, using winelib to get to Linux was the best starting point. The Exhibits According to some of the other exhibitors, this year's exhibit floor was the biggest one yet. Personally, I thought it looked small. It certainly wasn't LinuxWorld. Heck, it wasn't even as big as The Bazaar. But it was intimate, and we were able to meet a lot of great people. We were also able to talk to quite a few people for a longer period of time, which was a nice change. Traffic through the booth was near zero during the day (while sessions were running), but during lunch, and after the sessions ended, it was always busy. Again, a lot of interest in moving to Linux. I think the Borland development community is suddenly taking Linux very seriously, and as Kylix becomes available, we'll start to see more and more interest (at least from the business world). That interest will drive additional enthusiasm, and Wine is becoming an obvious consideration for everyone from users to developers and ISV's. That's about it for now. Feel free to ping me if you need/want more details. I'll be posting the talk on www.codeweavers.com, and for anyone that was at the show, it'll be on the post-conference CD. Hope to see more of you at LinuxWorld in August! Jim Graham CTO - CodeWeavers, Inc. [EMAIL PROTECTED]
WINE fix needed - $ paid
Anyone available/willing to do little snippets of quick-turnaround WINE contract work? Initially, I'd like to pay someone $US300 to write a technical analysis of what WINE lacks that keeps http://www.ldscatalog.com/sggifs/download/PafSetup.exe (both the setup program and the program it installs) from running under WINE, and what would be involved in getting the necessary pieces into the source that would make it run (without Windows having to be installed). The analysis should enumerate the steps taken to make the determinations (so I can vicariously dip my toe into WINE internals and tools). This would form the basis of a statement of work for getting PAF to run under Linux/WINE, and creating a Debian package for it. If you know of anyone that can/will do this work, please let me know. == Jim Freeman [EMAIL PROTECTED] Sovereign Software
Debugging question for MathType
27: WideCharToMultiByte() retval=0004 ret=004026dc fs=008f Call kernel32.250: FindFirstFileA(40f42860 "C:\\Program Files\\MathType\\Language\\MT4ENU.DLL",40856618) ret=0048c8c9 fs=008f Ret kernel32.250: FindFirstFileA() retval= ret=0048c8c9 fs=008f Call kernel32.333: GetFullPathNameA(40f42860 "C:\\Program Files\\MathType\\Language\\MT4ENU.DLL",0104,40856758,408565dc) ret=00491049 fs=008f Ret kernel32.333: GetFullPathNameA() retval=002d ret=00491049 fs=008f The last 10 lines continue to repeat with the following changes: the first argument in GetLocaleInfoA (LCID lcid) the fifth argument in MultiByteToWideChar (LPWSTR dst - destination buffer) the first argument in FindFirstFileA (LPCSTR path) the first argument in GetFullPathNameA (LPCSTR name) It seems that the program is querying the registry for the value of "AppLang", which is "0x040,enu". Then it gets the locale (should also be enu). Then it does some byte-char conversions. Next it tries to load a file that does not exist. I believe that it is supposed to open mswenu.dll or mswuienu.dll (at least those are the only dll files ending in "enu" in the referenced directory). I am new to debugging and don't quite know what to do next. How do I verify that the correct registry entry was retrieved and what strings the MultiByteToWideChar and WideCharToMultiByte functions are manipulating? Also, If wine is modified to run MathType, will I be able to use it to display/edit Math Type equations embedded in a document created with WordPerfect 9 for Windows using WordPerfect 9 for Linux and the updated wine? Thanks for your help. Jim Shepherd
Feedback request...
One of the goals of Wine 1.0 is "improved installation and configuration." Basically make it possible for just about anyone to install and set up Wine. We would like to propose a few ideas, and therefore I'm seeking feedback on the following... 1.) Allow all command line options to be configurable via the .winerc file. These options would then have the ability to be overridden by the command line (e.g., if the .winerc includes "debug=true", the command line could override this with -debug=false). Of course this would mean that all command line options would have to include a flag that specifies whether the option is being turned on or off, specifically to allow for the example shown above. 2.) Given the above idea, we then create a graphical configuration tool (or simply extend TkWineSetup) so that we can build a complete .winerc file that includes all possible options available to Wine. This tool would also have help and explanations about each option being presented. And while I'm at it...another idea we have is to extend the support for InstallShield installs under Wine. We could have the Wine server watch for registry additions that are used to put items in the "Start" menu on a windows box. We could then extract that information and put it into scripts that are loaded appropriately under the users Gnome or K menu. Users could then install their application via InstallShield, and then launch them by clicking on the menu item! Thoughts? Comments? Thanks, Jim Graham CodeWeavers, Inc. [EMAIL PROTECTED]
Black cursors on black background.
I'm looking into why black cursors disappear on a black background, I found this comment in the code: windows/x11drv/mouse.c /* We have to do some magic here, as cursors are not fully * compatible between Windows and X11. Under X11, there * are only 3 possible color cursor: black, white and * masked. So we map the 4th Windows color (invert the * bits on the screen) to black. This require some boolean * arithmetic: * * Windows | X11 * AndXor Result | Bits Mask Result * 0 0 black |01 background * 0 1 white |11 foreground * 1 0 no change |X0 no change * 1 1 inverted |01 background * * which gives: * Bits = 'And' xor 'Xor' (the X will be 1) * Mask = (not 'And') or 'Xor' * * FIXME: apparently some servers do support 'inverted' color. * I don't know if it's correct per the X spec, but maybe * we ought to take advantage of it. -- AJ */ Simply "OR'ing" the black on black fixes black, but clobbers the white. How do you implement inverted color?(and test the server) I'd like to "take advantage of it" if I can. Or is there a better way to fix this problem? -Jim
