Re: headless question, and IPC question
Boaz Harrosh wrote: Ken Larson wrote: This assumes that I'm using winelib, correct? (I currently am not, I'm compiling on windows, but considering using winelib instead) Yes!! Winelib can be both your DLL calling code, and you complete Linux application. No need for .EXE compiled or crosscompiled for windows, No need for IPC and no need for two parts at all. I apologize for the State of the documentation that this is not clear! It as been proven that any windows code can be compiled as Winelib. If you are using core Libraries like MFC or ATL than that might get difficult (not impossible), but it seems this is not your case. On the other hand Winelib applications are a Linux applications so they can link to any Linux library. Just that they have a funny Makefile and are built with Winegcc. Statically linking of a DLL is done as follows: - Write a .spec file prototyping your DLL, than “winebuild” it to a .DEF file. (make a rule for it in Makefile) - Link your Winelib against that .DEF file like you do any other Wine/Native DLL. .spec file syntax is documented and should be simple. Now all this is easy if your DLL is extern C. If it is C++ exports you'll need something extra. Is your DLL exporting C++ mangled symbols? Free Life Boaz Thanks for the info. Ultimately, my app is a Java app. I am spawning my EXE wrapper around my DLL and talking to it from Java with sockets. So unless I'm missing something, my entire (Java) app can't be a winelib linux app (barring something like gcj which I'm not sure I'm ready for). Ken
Re: headless question, and IPC question
Dmitry Timoshkov wrote: Mike McCormack [EMAIL PROTECTED] wrote: It looks like the only dependency is from the PostMessageA in dlls/winsock/async.c #514. The windows version of ws2_32.dll does not link to user32.dll however, it appears to load it on demand. I can see the following strings in it: USER32.dll TranslateMessage PeekMessageA PostMessageA DispatchMessageA Seems like it wouldn't be too hard to change the PostMessageA to LoadLibrary/GetProcAddres. depends.exe shows that ws2_32 has a delay load dependency on user32. We have to move user32 to a delay loaded section as well in our version. So do I interpret this to mean there is a plan to change this in wine? That would be great. The proprietary DLL I call also uses winsock, I do not know whether synchronous or asynchronous, but is it then true that even if this dependency were changed to delay, that if the DLL I'm calling opens an async socket (which uses a (non-visible) window handle for the notifications), that wine would require the X windows display at that point and fail anyway? Thanks, Ken
Re: headless question, and IPC question
Ken Larson [EMAIL PROTECTED] wrote: depends.exe shows that ws2_32 has a delay load dependency on user32. We have to move user32 to a delay loaded section as well in our version. So do I interpret this to mean there is a plan to change this in wine? That would be great. I sent a patch to wine-patches which makes user32 a delay loaded dependency for ws2_32 yesterday. -- Dmitry.
Re: Release plans
James Liggett wrote: Molle Bestefich wrote: There's a newer (4.8) IDA Pro demo, but alas, it cannot be installed under WINE CVS HEAD :-/. That's odd...I got IDA 4.8 demo to install and work without any problems at all. Perhaps something broke recently? Must have. Recently? Not so sure. I've tweaked the docs to reflect this (point to idafree 3.85b, which is the only ida that works right now - sort of, and GoVest) in the meantime. What sort of errors do you get? The installer can't create it's installation directory. Creating the directory manually does not help. Creating the directory it would've created - manually, then pointing the installer to the parent directory does not help. Using UNC paths and similar hacks does not help, as the installer truncates '\\' to '\'. Tried with CVS from yesterday and about a week ago. Tried nuking ~/.wine and recreating it, that didn't help either. Now that I think about it, there's one more thing I could try: Replacing \ with / - I'll give that a shot when I get near a Wine box again. If you get it working, let me know, I'll be happy to tweak the docs again.
Re: Release plans
Le dimanche 02 octobre 2005 à 15:45 -0600, Brian Vincent a écrit : I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated. My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries. Maybe we need to collect things like this into a Release Notes page on the wiki? In this case it would look something like, GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type (echo '/usr/local/lib' /etc/ld.so.conf) ldconfig -v. WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ... Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. IMO you should open a bug in gentoo's bugzilla telling them to apply a patch that removes this warning before to build wine as this warning doesn't apply to gentoo users. Altough it can seem crazy to compile everything from scratch, I never had to fix any paths in ld.so.conf under gentoo; if something works well under gentoo, that'd be the emerge process configuration update tool. Bye, signature.asc Description: This is a digitally signed message part
Re: headless question, and IPC question
Ken Larson wrote: Thanks for the info. Ultimately, my app is a Java app. If I recall correctly someone has reported Installation of Sun's Java for windows under wine. Or was it A failure to install? I can't recall. How would you call a DLL on Windows? Free Life Boaz
Migrate website documentation to the Wiki
Hi everyone, I'm willing to move every simple textual (static content) page from the website to the Wiki and link from the website to the corresponding pages. The advantages are obvious: - makes it easy to keep these pages up-to-date - makes it easy for non-dev. contributors to keep these pages up-to-date The problems are: - when clicking on a link from winehq to the wiki the left menu will change which can be confusing I notice that this has already been made for the janitorial page. The pages I'd like to move are about: http://cvs.winehq.org/cvsweb/lostwages/templates/en/* What do you think ? signature.asc Description: This is a digitally signed message part
Re: Release plans
I wrote: I wrote: Maybe there are much better solutions out there, which could also spare you some precious time having to do those Bugzilla reports you are currently making... See for instance Trac, which has built-in reports, and where the user can in a very simple way create h(is/er) own reports: http://projects.edgewall.com/trac/report Hoop-ti-doo, they even have a bugzilla-2-trac conversion script! http://projects.edgewall.com/trac/wiki/TracImport Flyspray - http://flyspray.rocks.cc/ - is also really sweet. Doesn't come with a bugzilla conversion script, though. Mooch off TSVN's bugtracker if you want to see it live :-). http://tortoisesvn.berlios.de/issues/
Re: Release plans
Jonathan Ernst schreef: Le dimanche 02 octobre 2005 à 15:45 -0600, Brian Vincent a écrit : I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated. My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries. Well, obviously, the ebuild + source tarball *is* my binary, as it were. It's not like I can effectively use SuSE or FC 4 rpms. So we 'crazy' source-based distro users can go jump, huh? Thanks :) . Funny, I'd call some of the 'pure' users on Wine-Users a lot crazier than I am, given some of the ways they try to use Wine Maybe we need to collect things like this into a Release Notes page on the wiki? In this case it would look something like, GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type (echo '/usr/local/lib' /etc/ld.so.conf) ldconfig -v. Well that was actually my ultimate question, since I'm working on docs-- if this was in fact a step I needed to find a way to perform, I would document it. But for that I'd have to know what to do, which required knowing the nature of the problem, which I didn't. WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ... Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. IMO you should open a bug in gentoo's bugzilla telling them to apply a patch that removes this warning before to build wine as this warning doesn't apply to gentoo users. OK, thanks for the pointer-- my main problem was knowing if the issue was the ebuild or the actual compilation process. bugzilla.gentoo.org (b.g.o.) I can handle. And thanks for the confirmation that everything ought to work normally (which I would have expected, despite the warning)-- but given our past and current issues with binary compilation, and given that we were specifically asked to check for anomalies in binary installation, I just wanted to be sure. Altough it can seem crazy to compile everything from scratch, I never had to fix any paths in ld.so.conf under gentoo; if something works well under gentoo, that'd be the emerge process configuration update tool. It really depends on your usage needs as to whether compiling everything from scratch is crazy or not. Clearly a 500-seat or more enterprise workstation farm does not have the time or energy most of the time, but I do. And it gives me a nice sandbox to learn in, since Portage does generally work very well, and since I can see what it did, I can begin to 'understand everything that the compilation process entails'. But OK, enough chitchat, I'm off to post a bug for this-- I'll post the bug number here in case anyone wants to follow it. Thanks for the help, I'm looking forward to taking 20050930 for a spin. Holly P.S. --Jonathan, been meaning to ask you; is it possible for you to upload your public GPG to a server somewhere? It would be nice to get rid of the yellow Unverified Signature warning I get from Enigmail every time I read a mail from you. Obviously not critical but thought I'd ask. Holly
Re: Release plans
Le lundi 03 octobre 2005 à 12:19 +0200, Holly Bostick a écrit : [...] P.S. --Jonathan, been meaning to ask you; is it possible for you to upload your public GPG to a server somewhere? It would be nice to get rid of the yellow Unverified Signature warning I get from Enigmail every time I read a mail from you. Obviously not critical but thought I'd ask. I sent them to keyserver.net; hope it works signature.asc Description: This is a digitally signed message part
excessive stack space usage in NTDLL
Hi, The stackspace usage in dlls/ntdll/directory.c is affecting programs. One installer crashes because of it I suspect. objdump -d directory.o|grep sub.*[0-9a-f][0-9a-f][0-9a-f],%esp wine_nt_to_unix_file_name - 0x5f0 (1520 byte) (in this my sample program crashes) append_entry- 0x2cc (716 byte) NtQueryDirectoryFile- 0x22d4 (8916 byte!) problematic also cdrom.o DVD_ReadKey - 0x84c CDROM_DeviceIoControl - 0x40c thread.o start_thread- 0x830 nt.o NtQuerySystemInformation- 0x990 How best to reduce? Allocate space with RtlAllocateHeap()? Ciao, Marcus
Re: enumerate the substorage transforms
Mike McCormack [EMAIL PROTECTED] writes: I thought that too before I sent the patch, so I removed it and recompiled just to make sure. It's used by the following definition in include/msiquery.h: #define MSIDBOPEN_READONLY (LPCTSTR)0 So, yes, I need it to open the database using MsiOpenDatabaseW. It would be better to use MAKEINTRESOURCE or something along these lines. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wcmd unusable when DISPLAY not set. Again.
Dan Kegel [EMAIL PROTECTED] writes: It's been a year or so since my last complaint, time to complain again! wcmd is currently unusable when DISPLAY is not set. Normally, you can do programs/wcmd/wcmd and get a nice DOS prompt. However, if you do unset DISPLAY programs/wcmd/wcmd you get a nonfunctional DOS prompt; for each keystroke, it gives you a new prompt. Pressing ^C terminates wine, and leaves stdin in raw mode. This makes it really friggin' hard to use batch files in a cron job or any other situation where you don't have X available. (And *please* don't tell me to set up a fake X server for this; that should simply not be needed. ) What we should probably do, now that we have support for a null display driver, is to flesh this out a little more and get rid of the tty driver. I don't think anybody in their right mind actually wants to run graphical apps on a tty, and the null driver is probably much closer to what people like you actually need. -- Alexandre Julliard [EMAIL PROTECTED]
Re: excessive stack space usage in NTDLL
Marcus Meissner [EMAIL PROTECTED] writes: The stackspace usage in dlls/ntdll/directory.c is affecting programs. One installer crashes because of it I suspect. Is it by any chance because it does a recursive search of the disk and runs out of stack? If that's the case you'll most likely see the overflow happen in one of the directory.c functions, but they are not the real culprit since they are not themselves recursive. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Migrate website documentation to the Wiki
I'm willing to move every simple textual (static content) page from the website to the Wiki and link from the website to the corresponding pages. I think this is a bad idea. The current system ensures that changes to the core parts of WineHQ are reviewed before being made, whereas a Wiki can allow things to change willy-nilly, often reflecting the views of the last person to touch a page, rather than a consensus. For things that are relatively fluid, like statii and such, I think the Wiki makes great sense. But for things that are, essentially, static, I think the current static web site works fine. Cheers, Jeremy
Re: Stop-ship 0.9 problem
Dimi Paun [EMAIL PROTECTED] wrote: Sorry Dmitry, but to me it seems ridiculous to argue against a fairly well known fact. The AA TrueType fonts has been an ongoing problem for _years_ with no solution in sight, whereas our Wine 0.9 release should be available in a matter of weeks. Given the short time frame, it's not an option to change they way the world works to conform to our liking. It's just not gonna happen. At most we can hope for is to piss a lot of people off and look like we don't have a sense of reality. It looks like FreeType has some bug fixes in that area, at least I've found this one in the changelog: LATEST CHANGES BETWEEN 2.1.10 and 2.1.9 - Another serious bug in handling TrueType hints caused many distortions. It has been introduced in version 2.1.8, and it is highly recommended to upgrade. There are some other fixes in hinting handling including autohinter bug fixes, so it's worth to upgrade to the latest/CVS FreeType and see if it helps Wine as well. Have you asked your Linux vendor to enable/license truetype hinter in FreeType? If not yet, it's time to do so. This has been brought up many times (at least on RH related lists). It is not an option, and for good reasons. Let's just deal with it, and run like bandits :) Could you enlighten me by listing those good reasons here? I suspect that the real problem with licensing the patented technologies in Linux is a general stance of GPL and Linux crowd regarding software patents making them non-free. -- Dmitry.
Re: Stop-ship 0.9 problem
On Mon, 2005-10-03 at 21:46 +0900, Dmitry Timoshkov wrote: Could you enlighten me by listing those good reasons here? I suspect that the real problem with licensing the patented technologies in Linux is a general stance of GPL and Linux crowd regarding software patents making them non-free. IIRC the reason Red Hat gives is that even if they license the technology, it would mean legal problems for their customers since they will not be able to redistribute the product further (i.e. Fedora Core) Regardless, it doesn't really matter. Personally I would prefer to have the hinter on, believe me, but Red Hat would not budge, and they are a very popular distribution. The release is too close to change anything. Even if every distro decides to buy the license, it still wouldn't change anything, as it would take a while to get that onto people's machines. Let's make sure Wine works well on the majority of boxes, and those don't have the hinter enabled (I used to compile the freetype RPM myself but I gave up since after each yum-update that updated it the system would look crappy). We can have a registry setting for that, if people can recompile freetype, they can tweak wine. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: excessive stack space usage in NTDLL
On Mon, Oct 03, 2005 at 02:36:55PM +0200, Alexandre Julliard wrote: Marcus Meissner [EMAIL PROTECTED] writes: No recursion as far as I can see. I get this backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1469332400 (LWP 24408)] 0x5577e57d in wine_cp_wcstombs (table=0x5586e668, flags=0, src=0x57845114, srclen=Cannot access memory at address 0x57845078 ) at wctomb.c:181 181 case 7: dst[-7] = uni2cp_low[uni2cp_high[src[-7] 8] + (src[-7] 0xff)]; (gdb) bt #0 0x5577e57d in wine_cp_wcstombs (table=0x5586e668, flags=0, src=0x57845114, srclen=Cannot access memory at address 0x57845078 ) at wctomb.c:181 #1 0x55725df1 in RtlUnicodeToOemN (dst=0x57845188 #, dstlen=7, reslen=0x0, src=0x57845114, srclen=14) at rtlstr.c:845 #2 0x557271f5 in RtlUpcaseUnicodeStringToCountedOemString (oem=0x57845194, uni=0x57845250, doalloc=Cannot access memory at address 0x57845113 ) at rtlstr.c:1127 #3 0x5571964c in RtlIsNameLegalDOS8Dot3 (unicode=0x57845250, oem=0x0, spaces=0x5784524f W\016) at path.c:909 #4 0x55705055 in wine_nt_to_unix_file_name (nameW=0x578458f4, unix_name_ret=0x57845830, disposition=1, check_case=Cannot access memory at address 0x5784524e ) at directory.c:1162 #5 0x55709ccd in NtQueryFullAttributesFile (attr=0x578458dc, info=0x57845854) at file.c:1388 #6 0x55709ecc in NtQueryAttributesFile (attr=0x578458dc, info=0x578458b4) at file.c:1436 #7 0x55a266bb in GetFileAttributesW (name=0x57842c00) at file.c:1772 #8 0x55a26756 in GetFileAttributesA (name=0x57c7fec8 C:\\Windows\\Temp\\ACDLABS 8.0 (FREE)) at file.c:1793 (gdb) x /i $eip 0x5577e57d wine_cp_wcstombs+2957: mov%edx,0xff40(%ebp) (gdb) (gdb) print $ebp-0xc0 $4 = (void *) 0x57844ff8 (gdb) cat /proc/../maps excerpt: 57842000-57844000 rwxp 57842000 00:00 0 57844000-57845000 ---p 57844000 00:00 0 57845000-57944000 rwxp 57845000 00:00 0 (1MB stack) 579c5000-57a1c000 rwxp 579c5000 00:00 0 57a2-57c8 rwxp 57a2 00:00 0 It just underflowed the 1MB stackspace here. But the above backtrace only has 2kb of stackspace usage, true. Something else must be using the rest of the stack, unless the initial stack pointer was set wrong, which seems unlikely. Probably the app was not compiled with frame pointer and gdb can't get a backtrace. Does winedbg show anything different? I guess the app itself uses so much stuff. There is a lot more backtrace below, but just hexcode. I stopped scrolling after 2 entries. Can I do winedbg do follow CreateProcess()es? Or attach it to running wines by just knowing the PID? Ciao, Marcus
Re: headless question, and IPC question
Boaz Harrosh wrote: Ken Larson wrote: Thanks for the info. Ultimately, my app is a Java app. If I recall correctly someone has reported Installation of Sun's Java for windows under wine. Or was it A failure to install? I can't recall. How would you call a DLL on Windows? Free Life Boaz Typically, you call a native dll by using JNI, java native interface. You end up having to write your own DLL in C/C++ using the JNI specification, which can in turn do anything that C/C++ can do. If Java itself were running under wine, then we could of course run the entire app under wine, and there would be no need to write an EXE wrapper around the proprietary DLL I need to call. That is exactly how our windows verison functions: the Java code uses JNI to call a DLL that in turn calls the proprietary DLL. This is probably not necessary since the original mechanism I mentioned, spawning and EXE under wine which communicates with Java on Linux using sockets, functions fine - apart from the minor issue of requiring a display, and perhaps some performance overhead. Then I am able to use the Linux version of Java (with the correct GUI look and feel, etc.). Really I think the problem kind of comes down to this: as far as I know, you can create an executable with winelib, but you can't just create a library, right? That is, if I wanted to create a .so on linux using winelib, that java can load, I can't, because it has to be a program with a main, right? This is why I wrapped my DLL using and EXE and then run it as a child process. Ken
Re: wcmd unusable when DISPLAY not set. Again.
* On Mon, 3 Oct 2005, Alexandre Julliard wrote: What we should probably do, now that we have support for a null display driver, is to flesh this out a little more and get rid of the tty driver. Alexandre, you mean to eliminate tty driver from the tree at all? I don't think anybody in their right mind actually wants to run graphical apps on a tty, and the null driver is probably much closer to what people like you actually need. Hmmm, I am the one with a non-right mind, who wants to run Microsoft Word with a look'n'feel of TurboVision (well, NCURSES would suffice too) and to play Diablo1 using AA-lib. I am serious, really. :-) So I think we just should switch defaults to a nulldrv, but let the ttydrv lives here and waits for a better times. Please. Thanks. :-)
Re: Stop-ship 0.9 problem
On Sun, Oct 02, 2005 at 08:19:58AM +0200, Lionel Ulmer wrote: The only problem I see is with people having a self-compiled FreeType library with hinting enabled. Why cripple their configuration too by default ? Is there no way to detect at compile / run-time what kind of FreeType library we link with ? Or, at the very least, let this be configurable in winecfg (or in the registry) as it does not seem to be the case with Mike's patch. We need to determine this at runtime really. I have come up with a way, but it's a bit of a hack - I've asked on the freetype list for a better solution. Once I have that I'll add a Wine specific bit to the flags returned by GetRasterizerCaps, x11drv can query this and take the appropriate action. Huw.
Re: Migrate website documentation to the Wiki
On 10/3/05, Jeremy White [EMAIL PROTECTED] wrote: I'm willing to move every simple textual (static content) page from the website to the Wiki and link from the website to the corresponding pages. I'll agree for the same reasons Jeremy cited. The static pages are relatively static and one of the only exceptions to that was a Janitorial page which really required a quick way to jot down ideas. There are two pages that might be useful to move though: Fun Projects and Resources. -Brian
Re: Release plans
On 10/3/05, Molle Bestefich [EMAIL PROTECTED] wrote: What sort of errors do you get? The installer can't create it's installation directory. Creating the directory manually does not help. For now you have to use native comctl32 to install some apps. -- James Hawkins
Re: Documentation volunteer(s) needed
Dimi Paun schreef: On Tue, 2005-09-20 at 23:30 +0200, Holly Bostick wrote: But in any case, I'm having another problem somewhat more relevant-- the docs don't compile as html for me: It should be fixed now, just get the latest version. Just a quick note-- I deleted the previous docs source dir, checked out the current one an hour ago. I will first say that I did get the docs to compile (so now I can read and edit them), *but* I had to compile all formats to do so. I was unable to compile just the html (which would have been preferable to me, since I have no use for .ps or.pdf files), because make html consistently failed with the following error: ./configure; make html checking whether make sets $(MAKE)... yes checking for docbook2html... docbook2html checking for docbook2pdf... docbook2pdf checking for docbook2ps... docbook2ps checking for docbook2txt... docbook2txt checking for nsgmls... nsgmls configure: creating ./config.status config.status: creating Make.rules config.status: creating Makefile config.status: creating en/Makefile config.status: creating fr/Makefile Configure finished. Do 'make' to compile the documentation. make[1]: Entering directory `/usr/local/src/docs/en' docbook2html -u winedev-guide.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/winedev-guide.sgml Done. docbook2html -u wineusr-guide.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/wineusr-guide.sgml Done. docbook2html -u winelib-guide.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/winelib-guide.sgml Done. docbook2html -u wine-faq.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/wine-faq.sgml Done. make[1]: Leaving directory `/usr/local/src/docs/en' make[1]: Entering directory `/usr/local/src/docs/fr' PERLLIB=../po4a/lib perl ../po4a/po4a-translate -v -f sgml -m ../en/wineusr-guide.sgml -p ./wineusr-guide.po -l wineusr-guide.sgml -k 1 po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains only tags) po4a::sgml: msgid skipped to help translators (contains
Re: wcmd unusable when DISPLAY not set. Again.
Saulius Krasuckas [EMAIL PROTECTED] writes: Hmmm, I am the one with a non-right mind, who wants to run Microsoft Word with a look'n'feel of TurboVision (well, NCURSES would suffice too) and to play Diablo1 using AA-lib. I am serious, really. :-) So I think we just should switch defaults to a nulldrv, but let the ttydrv lives here and waits for a better times. Please. Why? It's really an empty skeleton at this point, all it does is mess up the screen and dump a lot of FIXMEs, and I doubt it will ever do more than that. Putting it out of its misery seems the right thing to do. -- Alexandre Julliard [EMAIL PROTECTED]
Re: headless question, and IPC question
On Mon, 3 Oct 2005, Boaz Harrosh wrote: Ken Larson wrote: Thanks for the info. Ultimately, my app is a Java app. If I recall correctly someone has reported Installation of Sun's Java for windows under wine. Or was it A failure to install? I can't recall. How would you call a DLL on Windows? Sun's JVM installs and runs. - Walter
Re: Release plans
On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process. (By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.) -Brian
Re: Trouble compiling tests standalone with cl
Yes! It made my original, simple command work.
I hope this makes it into CVS soon.
On 10/2/05, Dimi Paun [EMAIL PROTECTED] wrote:
On Sun, 2005-10-02 at 22:19 -0700, Dan Kegel wrote:
I'd love that. It should sense _X86_ and set __i386__ if
found, too.
Does this work?
Index: include/windef.h
===
RCS file: /var/cvs/wine/include/windef.h,v
retrieving revision 1.99
diff -u -p -r1.99 windef.h
--- include/windef.h22 Sep 2005 10:58:04 - 1.99
+++ include/windef.h3 Oct 2005 05:26:26 -
@@ -41,6 +41,10 @@ extern C {
# define _X86_
#endif
+#if defined(_X86_) !defined(__i386__)
+# define __i386__
+#endif
+
#ifdef __x86_64__
#define _WIN64
#endif
@@ -126,6 +130,10 @@ extern C {
# endif
#endif
+#ifdef _MSC_VER
+# define inline __inline
+#endif
+
#define CALLBACK__stdcall
#define WINAPI __stdcall
#define APIPRIVATE __stdcall
--
Dimi Paun [EMAIL PROTECTED]
Lattica, Inc.
Re: Release plans
Le lundi 03 octobre 2005 à 10:13 -0600, Brian Vincent a écrit : On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process. Yes everything is ok and Gentoo keeps bringing new releases of Wine much faster than any other distro I know of. (By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.) Agreed. signature.asc Description: This is a digitally signed message part
Re: Migrate website documentation to the Wiki
On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: I'm willing to move every simple textual (static content) page from the website to the Wiki Please don't do this.
Re: Migrate website documentation to the Wiki
Le lundi 03 octobre 2005 à 09:25 -0700, Dan Kegel a écrit : On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: I'm willing to move every simple textual (static content) page from the website to the Wiki Please don't do this. I won't as nobody wants it. Let's just hope that the documentation will be a little bit less outdated. In the meanwhile I sent 5 or 6 patches to update some parts of lostwages that were out of date. -- Jonathan Ernst [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: wcmd unusable when DISPLAY not set. Again.
* On Mon, 3 Oct 2005, Alexandre Julliard wrote: * Saulius Krasuckas [EMAIL PROTECTED] writes: So I think we just should switch defaults to a nulldrv, but let the ttydrv lives here and waits for a better times. Please. Why? It's really an empty skeleton at this point, all it does is mess up the screen and dump a lot of FIXMEs, and I doubt it will ever do more than that. Putting it out of its misery seems the right thing to do. Ok then. My impression was, some thousands of code lines will be removed.
Re: Release plans
Brian Vincent schreef: On 10/3/05, Jonathan Ernst [EMAIL PROTECTED] wrote: Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected. There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process. (By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.) -Brian As far as I know, Gentoo (along with many other distros) cleaned up their act w.r.t wine several months ago (when Mike Hearn, I believe, got the various maintainers to *pay attention* to Wine development, rather than just assuming that everything built the same as it had previously month after month-- when it couldn't because so many changes were going on). So Wine has been working fine for me for some time (or rather, it's been working so fine as possible, without any issues I would specifically attribute to the distribution build process). In any case, the bug on b.g.o. can be found here: http://bugs.gentoo.org/show_bug.cgi?id=107971 If you don't want to go by, the bug has been downgraded from 'normal' to 'trivial' (which it rather is), and a suggestion has been made that, rather than writing a patch against the wine sources (and having to maintain it), an einfo should be added to the ebuild telling users to ignore the message from the compilation process. Which seems a quite reasonable solution that I would expect will be implemented. So I'd call that 'off my plate', myself :) . But then again, I've got plenty to do, so Holly
Help translating Japanese error message in installer
There is a Japanese RPG I am trying to install, which I downloaded from: http://www.i-o.jp/game/mizukake/mizukake_trial.zip This installer runs fine under Windows 98, but fails in Wine. I believe this to be some kind of trivial error, but I cannot read Japanese, so I am unable to diagnose what is going wrong with this installer. A screenshot of the error message is attached. Could somebody who can read Japanese please translate this screenshot for me, so that I can know what is the issue the installer is complaining about? Alex Villacís Lasso
CreateFile access/sharing problem
Any suggestions for how to handle a difference in file access and
sharing handling between Wine (20050830) and WinXP? A program
demonstrating the problem is attached below.
A 3rd party installer program for a VST plugin is calling CreateFile
with dwDesiredAccess = 0x1f01ff and dwSharedMode = FILE_SHARE_WRITE. It
then calls ReadFile, which fails in Wine (error 5) but succeeds in
WinXP.
My solution (polite term) was to force GENERIC_READ|GENERIC_WRITE
access in ntdll/NtCreateFile if the sharing type is FILE_SHARE_WRITE.
I have not been able to figure out from the header files what named
constants the program used for dwDesiredAccess, so I hard coded it with
the values the program used in my example.
But I did notice that FILE_ALL_ACCESS is a different value in Wine and
my VC98 headers from DevStudio 6. In Wine it is:
(STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x1ff)
In VC98:
(STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x3ff)
Is this a Wine bug?
The access and sharing parameters to CreateFile are making me feel
stupid. I read and read and read the docs at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp
and still can't really figure out what they are supposed to do! I am
pretty sure that my hack wouldn't stand and would love to hear the right
way to fix this problem.
Thanks... mo
#include stdio.h // printf
#include windows.h
int main(int argc, char *argv[])
{
if (argc 2) {
puts(usage: wine file-access-test.exe.so PATH);
puts(Tests the access used by the Ivory Library Tools program
that doesn't work with wine.);
return(1);
}
HANDLE file = ::CreateFile(argv[1], 0x1f01ff, FILE_SHARE_WRITE, NULL,
OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (file != INVALID_HANDLE_VALUE) {
DWORD bytesRead;
char bufr[32];
// passes in winxp; fails (error 5) in wine
if (::ReadFile(file, bufr, sizeof(bufr), bytesRead, NULL))
printf(Read %ld bytes\n, bytesRead);
else
printf(ReadFile error: %d\n, ::GetLastError());
::CloseHandle(file);
}
else
printf(CreateFile error: %d\n, ::GetLastError());
return(0);
}
Re: CreateFile access/sharing problem
On 03 Oct 2005 11:20:16 -0700, Michael Ost [EMAIL PROTECTED] wrote: Any suggestions for how to handle a difference in file access and sharing handling between Wine (20050830) and WinXP? A program demonstrating the problem is attached below. Bless your soul. It ought to be pretty easy for someone to convert that little program from C++ into C and add it to the Wine test suite. (Would you consider doing that?) That will make life easier for whoever fixes the bug. - Dan
Re: excessive stack space usage in NTDLL
I guess the app itself uses so much stuff. There is a lot more backtrace below, but just hexcode. that's (likely) because you don't have debug info for the app I stopped scrolling after 2 entries. Can I do winedbg do follow CreateProcess()es? this hasn't been fully tested, I don't recommend it Or attach it to running wines by just knowing the PID? yes, attach pid works fine (you can use info proc to get the list of running processes, except the debugger where you key the commands= A+ -- Eric Pouech
Re: winedbg not starting
Eric, I don't see any abort for a process 8: Yeah, that's not the issue: the debuggee is made of threads 9,a,b (and the debugger as a pid c and its main thread is d), and is still running when the event is set by the debugger. Dumb question: are you running on a vanilla wine tree (ie not modified)? A+ -- Eric Pouech
Re: Paths confusion
F Lace wrote:
Hello Wine Folks,
Thanks to google, I learnt about Wine's existence. I havent tried it
yet, looking through the website, documentation and source code, I am
delighted!
I am browsing through some DLL implementation source one by one, but I
got stuck at the first one itself(kernel32/files) and got confused
with various file path formats.
Following are some of the path names I could collect reading through
different documentation and I also got a few from my friends who are
windows developers.
http://www.winehq.com/site/docs/wine-devel/x3016 is your friend
To list my confusion, I have a few questions reading the source:
1. Do UNC paths really start with UNC\? I havent seen any, I thought
they start with just \\share\
the Win32 form is \\share\...
the NTDLL form starts with UNC\..
2. Does \\?\ denote a UNC path that refers to the local machine?
no, it's a long path (len MAX_PATH) in Win32 form
3. Wine's RtlDetermineDosPathNameType_U says //./foo is a device path,
what does this translate to this path is given to NtCreateFile?
there are a few hardcoded names here, + winecfg:ed drives + VxDs
4. Wine's NtCreateFile seems to specially handle only PIPEs and
MAILSLOTs. How does it handle the other types that I listed below?
(\Device\..., \??\Volume, :{...}, etc
\Device, nor Volume are handled
5. How do you determine from the NT path if it is a path to a device?
check wine_nt_to_unix_path_name
A+
--
Eric Pouech
Re: Stop-ship 0.9 problem
Huw D M Davies wrote: The idea was to enable antialiasing if either the gasp table was missing or if the gasp table tell us to do so. It seems unlikely that a font designer would have gone to the trouble of adding hinting instructions but not the tiny gasp table. Actually I couldn't find a font without a gasp table to test what Windows does in this situation. Ah, OK, so the logic was right then. Apologies.
Re: Help translating Japanese error message in installer
On 10/3/05, Molle Bestefich [EMAIL PROTECTED] wrote: Alex Villacís Lasso wrote: There is a Japanese RPG I am trying to install, which I downloaded from: http://www.i-o.jp/game/mizukake/mizukake_trial.zip This installer runs fine under Windows 98, but fails in Wine. I believe this to be some kind of trivial error, but I cannot read Japanese, so I am unable to diagnose what is going wrong with this installer. I can't read Japanese, but with current CVS HEAD, the IDA Pro installers fail at the same point in the installer as your screen shots indicate. They complain that they cannot create the installation directory. Might be the same. I've tried a bunch of things but have found no workaround. (Your installer doesn't seem like exactly the same though, so you might try some of them - forward slashes, UNC paths, dunno.) The current workaround is to use native comctl32. -- James Hawkins
Re: Migrate website documentation to the Wiki
On 10/3/05, Molle Bestefich [EMAIL PROTECTED] wrote: Isn't there a compromise where Wiki's upfront editing capabilities can be used to ensure up-to-date, dynamic content while you also make sure that nobody wrecks the pages? I'm no wiki expert, but it seems like an obvious solution to have the pages editable only by a certain class of users. People wanting to edit something could then just ask for edit access for certain pages for correcting this or that on wine-devel and be granted those privileges on a case-by-case basis. Or is that simply impossible.. This method is already available in the form of checking out lostwages cvs, making changes, doing a diff, and sending in the patch to be accepted. The only difference is that anyone can make changes to lostwages this way (assuming they get committed). -- James Hawkins
Re: Documentation volunteer(s) needed
From: Holly Bostick [EMAIL PROTECTED] I will first say that I did get the docs to compile (so now I can read and edit them), *but* I had to compile all formats to do so. Sorry about that, the French version is still not up to par. I also tried make html en (since I have no use for the French version either); that also failed with the same error, but that may not be a valid command -- the README doesn't really say that I can combine the type and lang switches, but I thought I'd try. You just have to change dir to the en/ dir: cd en; make html That would do what you want to accomplish. So I have no idea whether installing docbook-sgml and sgmltools-lite had any effect, or whether make html is just not properly working for some reason, but I thought I should report the experience. Thank you! Let's hope someone fixes the French docs building issues (hint, hint! :)). -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Migrate website documentation to the Wiki
From: Brian Vincent [EMAIL PROTECTED] I'll agree for the same reasons Jeremy cited. The static pages are relatively static and one of the only exceptions to that was a Janitorial page which really required a quick way to jot down ideas. There are two pages that might be useful to move though: Fun Projects and Resources. ACK. I also don't think the Wiki is the right medium for the stuff on the site. We should however move the Fun Projects and TODO page over. I've started on the TODO, but I still have a bit to finish it off. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Migrate website documentation to the Wiki
On 10/3/05, James Hawkins [EMAIL PROTECTED] wrote: This method is already available in the form of checking out lostwages cvs, making changes, doing a diff, and sending in the patch to be accepted. The only difference is that anyone can make changes to lostwages this way (assuming they get committed). There is a certain lack of feedback in the process, though. I did exactly what you suggested: http://www.winehq.org/pipermail/wine-patches/2005-September/021063.html but haven't heard back, nor has the change been committed.
Re: winedbg not starting
Eric == Eric Pouech [EMAIL PROTECTED] writes: Eric, I don't see any abort for a process 8: Eric Yeah, that's not the issue: the debuggee is made of threads 9,a,b Eric (and the debugger as a pid c and its main thread is d), and is Eric still running when the event is set by the debugger. Eric Dumb question: are you running on a vanilla wine tree (ie not Eric modified)? A+ I (repeatedly) purged all changes, and cvs update -PAd no longer returns and M or C entries. However I run wine not installed, e.g. I start wine with the fully qualified path and also the Aedebug registry entry contains the full path. What about trying yourself? You can download switchercad from http://ltspice.linear.com/software/swcadiii.exe without any registration, It's about 6 MByte download, and it installs without problems. The programm author, Mike Engelhardt, has always been helpfull questions. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: CreateFile access/sharing problem
On October 3, 2005 11:20 am, Michael Ost wrote: Any suggestions for how to handle a difference in file access and sharing handling between Wine (20050830) and WinXP? A program demonstrating the problem is attached below. A 3rd party installer program for a VST plugin is calling CreateFile with dwDesiredAccess = 0x1f01ff and dwSharedMode = FILE_SHARE_WRITE. It then calls ReadFile, which fails in Wine (error 5) but succeeds in WinXP. The access and sharing parameters to CreateFile are making me feel stupid. I read and read and read the docs at http://msdn.microsoft.com/library/default.asp?url=/library/en- us/fileio/fs/createfile.asp and still can't really figure out what they are supposed to do! I am pretty sure that my hack wouldn't stand and would love to hear the right way to fix this problem. Thanks... mo I think that maybe you/we are getting confused as a result of Microsoft trying to simplify the language and actually making it worse. I think the problem is with the FILE_SHARE_... descriptions. (There seems to be a disconnect between the designers and the linguists, especially when negatives become involved) In the old days the description was possibly worse: FILE_SHARE_READ - Subsequent open operations on the object will succeed only if read access is requested. I think that the linguists are trying to put a positive spin on what is actually a negative construct. As far as I am concerned this is what is meant. FILE_SHARE_READ - Enables subsequent open operations on an object to request read access. If this flag is not specified then any subsequent open operations specifying read access will fail. If this flag is specified then any subsequent operations specifying read access may succeed or fail, depening on other conditions. Basically it all dates back to the old days of DOS. The sharing was to control how a file was shared; the first opening of the file is constraining what else may be done. By specifying FILE_SHARE_READ the caller is permitting other calls to open the file for reading. We could (INCORRECTLY) read the bad current text to mean During this call if the file is opened for reading but the FILE_SHARE_READ is not set then the call will fail. Anyway, I'll have a quick look. -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: winedbg not starting
Uwe Bonnes [EMAIL PROTECTED] writes: I (repeatedly) purged all changes, and cvs update -PAd no longer returns and M or C entries. However I run wine not installed, e.g. I start wine with the fully qualified path and also the Aedebug registry entry contains the full path. That's most likely the problem, if you specify the path to the winedbg wrapper script it gets launched as a Unix process, and doesn't inherit handles. Simply use 'winedbg' in the AeDebug entry, it should work fine when running from the source tree too. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Migrate website documentation to the Wiki
Le lundi 03 octobre 2005 à 13:23 -0700, Dan Kegel a écrit : On 10/3/05, James Hawkins [EMAIL PROTECTED] wrote: This method is already available in the form of checking out lostwages cvs, making changes, doing a diff, and sending in the patch to be accepted. The only difference is that anyone can make changes to lostwages this way (assuming they get committed). There is a certain lack of feedback in the process, though. I did exactly what you suggested: http://www.winehq.org/pipermail/wine-patches/2005-September/021063.html but haven't heard back, nor has the change been committed. I think it would be preferable to put these infos in the Wiki or in lostwages and avoid having resources at too much different places, it will just confuse users imho. I know you don't like Wikis, but it's just a matter of copy pasting your content. I can do it if you want. -- Jonathan Ernst [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Migrate website documentation to the Wiki
James Hawkins wrote: Molle Bestefich wrote: Isn't there a compromise where Wiki's upfront editing capabilities can be used to ensure up-to-date, dynamic content while you also make sure that nobody wrecks the pages? I'm no wiki expert, but it seems like an obvious solution to have the pages editable only by a certain class of users. People wanting to edit something could then just ask for edit access for certain pages for correcting this or that on wine-devel and be granted those privileges on a case-by-case basis. This method is already available in the form of checking out lostwages cvs, making changes, doing a diff, and sending in the patch to be accepted. The only difference is that anyone can make changes to lostwages this way (assuming they get committed). Technically speaking, perhaps. But a wiki lends itself to editing so much better than the tardy process of finding the right CVS server, logging in, checking out a working copy, finding the piece of documentation that is relevant, making a change, checking if it compiles, sending a patch to wine-patches (that never shows up) and to wine-devel (and never receiving a response). Compare that to just sending a mail to wine-devel saying eg. hey guys, there's two A links with 'binary' in their name on the download page, one of them should be 'third-party', can I get editing rights to it? In the concrete case of the download page the answer would probably be No, but we'll go fix it for you, but you get the drift. Ahem. For any other page the response will probably be Sounds good, you've got access to edit the blah blah section now. Remember to click preview and see if it looks good before you commit.
Re: winedbg not starting
Alexandre == Alexandre Julliard [EMAIL PROTECTED] writes: Alexandre Uwe Bonnes [EMAIL PROTECTED] writes: I (repeatedly) purged all changes, and cvs update -PAd no longer returns and M or C entries. However I run wine not installed, e.g. I start wine with the fully qualified path and also the Aedebug registry entry contains the full path. Alexandre That's most likely the problem, if you specify the path to Alexandre the winedbg wrapper script it gets launched as a Unix Alexandre process, and doesn't inherit handles. Simply use 'winedbg' in Alexandre the AeDebug entry, it should work fine when running from the Alexandre source tree too. Thanks, that's the problem. Will wine now start the installed winedbg in the path or the winedbg from the path where wine was started from? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: RH8 spec for 20050830
On September 26, 2005 11:59 am, Michael Ost wrote: Can someone who understands wine build issues review this RPM spec file for me, please? ... So what is the status of getting RedHat RPMS again? Are you having any luck, Michael? I am going to be needing RedHat RPMS for Wine very soon, for testing purposes. I'd be quite willing to help out but it would suit me best if you were to take the lead. -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: shellpath: use wine_get_dos_file_name
Juan Lang wrote: ChangeLog: use wine_get_dos_file_name rather than relying on GetFullPathNameW hack. This is going to cause us poor ReactOS guys some trouble as that kernel32 function neither exists in Windows nor ReactOS. Isn't there a better solution? - Thomas
Re: winecfg: remove .dll extension from DllOverrides
On 10/3/05, Juan Lang [EMAIL PROTECTED] wrote: This seems to be a common source of confusion. (It got me, and it's asked on wine-users periodically.) Do .exe extensions need to be stripped too? I believe only .dll needs to be stripped. .exe and others like .ocx must remain. -- James Hawkins
Re: shellpath: use wine_get_dos_file_name
This is going to cause us poor ReactOS guys some trouble as that kernel32 function neither exists in Windows nor ReactOS. Isn't there a better solution? This function was already going to cause you trouble, as getenv(HOME) probably won't produce the correct results anyway. Just get rid of the special cases portion of _SHGetDefaultValue, they never apply to ROS. --Juan __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: shellpath: use wine_get_dos_file_name
Juan Lang wrote: This function was already going to cause you trouble, as getenv(HOME) probably won't produce the correct results anyway. Just get rid of the special cases portion of _SHGetDefaultValue, they never apply to ROS. Actually no as it is only used in shfldr_unixfs.c - which we don't port. - Thomas
Re: shellpath: use wine_get_dos_file_name
--- Thomas Weidenmueller [EMAIL PROTECTED] wrote: This function was already going to cause you trouble... Actually no as it is only used in shfldr_unixfs.c - which we don't port. Sorry, I wasn't clear enough. I mean, _SHGetDefaultValue was already problematic for you, before I changed it to call wine_get_dos_file_name. The special cases portion of _SHGetDefaultValue don't apply to ROS, so they should be removed from your tree in any case. --Juan __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: shellpath: use wine_get_dos_file_name
Juan Lang wrote: Sorry, I wasn't clear enough. I mean, _SHGetDefaultValue was already problematic for you, before I changed it to call wine_get_dos_file_name. The special cases portion of _SHGetDefaultValue don't apply to ROS, so they should be removed from your tree in any case. Ah ok thanks. - Thomas
Cannot compile 20050830 on Solaris 9
I have been trying to compile wine from source on Solaris 9 on x86. This has proven to be very frustrating. I had to rename a struct in one of the files in the tools/windump/main.c because of a name clash, but that was easy. I am pretty new to the whole compiling from source thing on Unix, but have built several packages (including Wine), on various Linux platforms and a few on Solaris. The main problem I seem to be having is with the assembler portion. All goes well until it gets to the d3d8 directory, and I get the following: ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./d3d8.specbasetexture.o cubetexture.o d3d8_main.o device.o directx.o drawprim.o indexbuffer.o resource.o shader.o stateblock.o surface.o swapchain.o texture.o utils.o vertexbuffer.o volume.o volumetexture.o vshaderdeclaration.o d3d8.dll.dbg.o version.res -o d3d8.dll.so -L../../dlls -L../../dlls/wined3d -L../../dlls/user32 -L../../dlls/gdi32 -L../../dlls/advapi32 -L../../dlls/kernel32 -lwined3d -luser32 -lgdi32 -ladvapi32 -lkernel32 -L../../libs/wine -lwine -ldxguid -luuid -L/usr/openwin/lib -R/usr/openwin/lib -lSM -lICE -lXext -lX11 -lsocket -lnsl -lGL -L../../libs/port -lwine_port -lresolv -lsocket -lnsl Assembler: d3d8.dll-LsL4C9.spec.c /var/tmp//ccpfivNU.s, line 515 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 515 : Syntax error /var/tmp//ccpfivNU.s, line 516 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 516 : Syntax error /var/tmp//ccpfivNU.s, line 517 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 517 : Syntax error /var/tmp//ccpfivNU.s, line 518 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 518 : Syntax error /var/tmp//ccpfivNU.s, line 519 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 519 : Syntax error /var/tmp//ccpfivNU.s, line 520 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 520 : Syntax error /var/tmp//ccpfivNU.s, line 522 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 522 : Syntax error /var/tmp//ccpfivNU.s, line 523 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 523 : Syntax error /var/tmp//ccpfivNU.s, line 524 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 524 : Syntax error /var/tmp//ccpfivNU.s, line 525 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 525 : Syntax error /var/tmp//ccpfivNU.s, line 526 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 526 : Syntax error /var/tmp//ccpfivNU.s, line 527 : Illegal mnemonic /var/tmp//ccpfivNU.s, line 527 : Syntax error /var/tmp//ccpfivNU.s, line 555 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_WineDirect3DCreate /var/tmp//ccpfivNU.s, line 564 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_ChangeDisplaySettingsExW /var/tmp//ccpfivNU.s, line 573 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_GetClientRect /var/tmp//ccpfivNU.s, line 582 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_GetDC /var/tmp//ccpfivNU.s, line 591 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_GetDesktopWindow /var/tmp//ccpfivNU.s, line 600 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_GetPropA /var/tmp//ccpfivNU.s, line 609 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_GetSystemMetrics /var/tmp//ccpfivNU.s, line 618 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_ReleaseDC /var/tmp//ccpfivNU.s, line 627 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_SetWindowLongA /var/tmp//ccpfivNU.s, line 636 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_SetWindowPos /var/tmp//ccpfivNU.s, line 645 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_CreateDCA /var/tmp//ccpfivNU.s, line 654 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_DeleteDC /var/tmp//ccpfivNU.s, line 663 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_ExtEscape /var/tmp//ccpfivNU.s, line 672 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_GetDeviceCaps /var/tmp//ccpfivNU.s, line 681 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_GetDeviceGammaRamp /var/tmp//ccpfivNU.s, line 690 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_SetDeviceGammaRamp /var/tmp//ccpfivNU.s, line 699 : Warning: Illegal subtraction - symbols from different sections: imports, .L__wine_spec_RegOpenKeyA /var/tmp//ccpfivNU.s, line 708 : Warning: Illegal
Re: [AppDb] Submit new version broken
Fixed. Chris On Sunday 02 October 2005 12:58 pm, Chris Morgan wrote: Ahh. This should be easy to fix, I must not have tested that page before checking it in. Thanks for the bug report Jon. Chris On 10/2/05, Jonathan Ernst [EMAIL PROTECTED] wrote: Hello, The upgrade to xinha broke the submit new version page (submit new application works like a charm now even with both htmlarea editors). I have no time to look into it but it seems that xinha doesn't know that it has to convert the textarea whose id is editor2. The JavaScript console shows: Error : textarea has no properties Source File : http://appdb.winehq.org/xinha/htmlarea.js Line : 98 Bye, Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDQBBM5uNwURKeRvURAsyyAJ9weqNw4aUAjr/uTL+LHQuGOZBK0wCgpngp ZMbe9oCVbt+GNv/NT2sJi2k= =Es3+ -END PGP SIGNATURE-
Re: Cannot compile 20050830 on Solaris 9
Le lun 03/10/2005 à 19:11, Rob D a écrit : I have been trying to compile wine from source on Solaris 9 on x86. This has proven to be very frustrating. I had to rename a struct in one of the files in the tools/windump/main.c because of a name clash, but that was easy. I am pretty new to the whole compiling from source thing on Unix, but have built several packages (including Wine), on various Linux platforms and a few on Solaris. The main problem I seem to be having is with the assembler portion. All goes well until it gets to the d3d8 directory, and I get the following: [snip] I thought at first that it was inadvertently using the AS assembler, but apparently the AS = gas in the Makefile says otherwise. Not sure where to go from here, since the /var/tmp files disappear immediately. Are you sure your gcc is setup to use gas and not as? There's a section about that on Solaris in README. The same kind of problem can happen too with ld. Robert Lunnon makes some Solaris version of Wine, maybe you could find them. Vincent
How to fix the permission stuff.
Advice please. This looks a little too big to be done without discussion. This stems from Michael Ost's CreateFile issue and is much more fundamental than the SHARE settings. Consider. ...CreateFile ( FILE_READ_DATA...) ...ReadFile (...) That is sensible and perfectly legal under Windows but fails under Wine due to an inadequate handling of the generic vs specific permissions. It seems to me that the fix to this minor problem includes: a. Extending the server's Object concept (or at least the ops structure) to include the relevant GENERIC_MAPPING definition for the object. b. Extend the testing in handle.c so that the test of access takes into account the fact that the granted permissions might be generic whilst the requested is specific, and vice versa. This requires a in order to know how to do the conversion. c. Fix up calls to be a little more sensible in their requests. For example ReadFile does not need GENERIC_READ; it only needs FILE_READ_DATA. Alternatively we could specify that the access settings held for a handle in the server are only specific and the appropriate object's code is responsible for converting from generic to specific. Any comments? -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
RE: Cannot compile 20050830 on Solaris 9
The only Solaris 9 binary I could find was from his website at: http://www.members.optushome.com.au/bobl/ The only problem is that it is 20040309, which is over a year and a half old and it has the RTLD_FIRST problem. various combinations of symlinking /usr/ccs/bin/as to /opt/sfw/bin/gas and back, with and without running configure between makes does change the output significantly. Some combinations give the Assembler Message Unknown pseudo-op '.half', but most combinations give the illegal mnemonic or dozens of the following error: (standard input): Assembler messages: (standard input): 4802: Error: Rest of line ignored. First ignored character is '@'' Since changing the symlink appears to change the behaviour, I would assume that gcc IS trying to use as instead of gas, but it also seems that adding the symlink and running configure should make it use gas. Now Im really confused. I read somewhere that someone had to maually configure gcc to use gas. Not sure how to do that at all, but now that is my next task. Thanks Rob Done At 05:28 PM 10/3/2005, you wrote: Le lun 03/10/2005 à 19:11, Rob D a écrit : I have been trying to compile wine from source on Solaris 9 on x86. This has proven to be very frustrating. I had to rename a struct in one of the files in the tools/windump/main.c because of a name clash, but that was easy. I am pretty new to the whole compiling from source thing on Unix, but have built several packages (including Wine), on various Linux platforms and a few on Solaris. The main problem I seem to be having is with the assembler portion. All goes well until it gets to the d3d8 directory, and I get the following: [snip] I thought at first that it was inadvertently using the AS assembler, but apparently the AS = gas in the Makefile says otherwise. Not sure where to go from here, since the /var/tmp files disappear immediately. Are you sure your gcc is setup to use gas and not as? There's a section about that on Solaris in README. The same kind of problem can happen too with ld. Robert Lunnon makes some Solaris version of Wine, maybe you could find them. Vincent
Re: Documentation update
On Sun, 2005-10-02 at 21:47 +, Molle Bestefich wrote: Fix up winedev-debugger doc to match 0.9. Remove 404s, remove config file references, mention disassemblers that actually installs, etc. Applied, but in the future please include [WINEDOC] at the beginning of the Subject: so I can pick it up easier. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Help translating Japanese error message in installer
Hi, FYI:The error message means Invalid Folder Name Cheers Vik 2005-10-03 (月) の 13:15 -0500 に Alex Villacís Lasso さんは書きました: There is a Japanese RPG I am trying to install, which I downloaded from: http://www.i-o.jp/game/mizukake/mizukake_trial.zip This installer runs fine under Windows 98, but fails in Wine. I believe this to be some kind of trivial error, but I cannot read Japanese, so I am unable to diagnose what is going wrong with this installer. A screenshot of the error message is attached. Could somebody who can read Japanese please translate this screenshot for me, so that I can know what is the issue the installer is complaining about? Alex Villacís Lasso
Re: CreateFile access/sharing problem
On Mon, 2005-10-03 at 12:14, Dan Kegel wrote: On 03 Oct 2005 11:20:16 -0700, Michael Ost [EMAIL PROTECTED] wrote: Any suggestions for how to handle a difference in file access and sharing handling between Wine (20050830) and WinXP? A program demonstrating the problem is attached below. Bless your soul. It ought to be pretty easy for someone to convert that little program from C++ into C and add it to the Wine test suite. (Would you consider doing that?) That will make life easier for whoever fixes the bug. Sure, but I don't know where the tests are. Somehow I haven't run across that yet. Can you point me? - mo
Re: CreateFile access/sharing problem
Michael Ost [EMAIL PROTECTED] wrote: A 3rd party installer program for a VST plugin is calling CreateFile with dwDesiredAccess = 0x1f01ff and dwSharedMode = FILE_SHARE_WRITE. It then calls ReadFile, which fails in Wine (error 5) but succeeds in WinXP. My solution (polite term) was to force GENERIC_READ|GENERIC_WRITE access in ntdll/NtCreateFile if the sharing type is FILE_SHARE_WRITE. Most likely sharing mode has nothing to do with access rights. The problem is that the app doesn't specify neither of GENERIC_ flags. But it does specify STANDARD_RIGHTS_ALL == (DELETE|READ_CONTROL|WRITE_DAC|WRITE_OWNER|SYNCHRONIZE). It appears that Windows treats GENERIC_ rights as an addition to the STANDARD_RIGHTS_xxx flags, and missing GENERIC_ rights are normally ignored. I have not been able to figure out from the header files what named constants the program used for dwDesiredAccess, so I hard coded it with the values the program used in my example. But I did notice that FILE_ALL_ACCESS is a different value in Wine and my VC98 headers from DevStudio 6. In Wine it is: (STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x1ff) In VC98: (STANDARD_RIGHTS_REQUIRED|SYNCHRONIZE|0x3ff) Is this a Wine bug? Please send a patch for this. Your test app needs to be extended to verify who is responsible for handling the dwDesiredAccess: CreateFileW ot NtCreateFile (I think it's the latter one, but it needs to be tested). -- Dmitry.
Re: RH8 spec for 20050830
On Mon, 2005-10-03 at 14:31, Bill Medland wrote: So what is the status of getting RedHat RPMS again? Are you having any luck, Michael? I am going to be needing RedHat RPMS for Wine very soon, for testing purposes. I'd be quite willing to help out but it would suit me best if you were to take the lead. I can provide you with a source RPM that works on my redhat 8-ish system. I don't have the machines to build bona fide rh8, rh9, etc binary RPMs but I'd be happy to post the source one. Is there a good spot? I based it on the spec file from Vincent, with a couple of mods to the patches for the new sources. There was some sort of change involving fonts that I didn't satisfactorily resolve. His spec includes wine-fonts-VERSION.tar.gz. I couldn't find that file via google, so I copied the 20050524 file over. I don't _think_ that's right, but I am not sure... Anyway it's all yours (or anyone else's) if you want it. - mo
Re: CreateFile access/sharing problem
On 03 Oct 2005 20:59:13 -0700, Michael Ost [EMAIL PROTECTED] wrote:
Bless your soul. It ought to be pretty easy for someone to
convert that little program from C++ into C and add it to the Wine test
suite. (Would you consider doing that?)
Sure, but I don't know where the tests are. Somehow I haven't run across
that yet. Can you point me?
$ grep -l 'open(' dlls/*/tests/*.c
dlls/kernel/tests/file.c
dlls/msvcrt/tests/file.c
dlls/msvcrt/tests/printf.c
Looking at the three, I'd say dlls/msvcrt/tests/file.c.
To build a standalone Windows executable of that file, do
cd dlls\msvcrt\tests
cl -DSTANDALONE -D_X86_ -I../../../include file.c
or, if dimi's patch isn't in yet, you need two more defines:
cl -DSTANDALONE -D_X86_ -D__i386__ -Dinline=__inline -I../../../include file.c
Then you can run the same executable on both windows and linux.
I'd build and run the test as is before changing it, just
to make sure it works.
Re: CreateFile access/sharing problem
Michael Ost [EMAIL PROTECTED] wrote:
Or did you mean post it to wine-patches? I am totally new to
wine-patches, but I can give it a go... mo
Yes, wine-patches is what you need. Do not forget a changelog
description for your change.
Dan Kegel [EMAIL PROTECTED] wrote:
$ grep -l 'open(' dlls/*/tests/*.c
dlls/kernel/tests/file.c
dlls/msvcrt/tests/file.c
dlls/msvcrt/tests/printf.c
Looking at the three, I'd say dlls/msvcrt/tests/file.c.
It's dlls/kernel/tests/file.c, test_CreateFileA/W.
--
Dmitry.
Re: CreateFile access/sharing problem
Monday, October 3, 2005, 10:08:24 PM, Dmitry Timoshkov wrote: Michael Ost [EMAIL PROTECTED] wrote: A 3rd party installer program for a VST plugin is calling CreateFile with dwDesiredAccess = 0x1f01ff and dwSharedMode = FILE_SHARE_WRITE. It then calls ReadFile, which fails in Wine (error 5) but succeeds in WinXP. My solution (polite term) was to force GENERIC_READ|GENERIC_WRITE access in ntdll/NtCreateFile if the sharing type is FILE_SHARE_WRITE. Most likely sharing mode has nothing to do with access rights. The problem is that the app doesn't specify neither of GENERIC_ flags. But it does specify STANDARD_RIGHTS_ALL == (DELETE|READ_CONTROL|WRITE_DAC|WRITE_OWNER|SYNCHRONIZE). It appears that Windows treats GENERIC_ rights as an addition to the STANDARD_RIGHTS_xxx flags, and missing GENERIC_ rights are normally ignored. It is an additional flags to the rest of the file flags because they are transferred all the way to the kernel. And being translated into specific access rights by an object manager according to the object type. It has array of the generic attributes mappings. Vitaliy
Re: CreateFile access/sharing problem
Vitaliy Margolen [EMAIL PROTECTED] wrote: It is an additional flags to the rest of the file flags because they are transferred all the way to the kernel. And being translated into specific access rights by an object manager according to the object type. It has array of the generic attributes mappings. Does the ntdll export RtlMapGenericMask have anything to do with mapping GENERIC_ flags into STANDARD_RIGHTS_? Is there any information regarding that? -- Dmitry.
Re: CreateFile access/sharing problem
Monday, October 3, 2005, 11:21:37 PM, Dmitry Timoshkov wrote: Vitaliy Margolen [EMAIL PROTECTED] wrote: It is an additional flags to the rest of the file flags because they are transferred all the way to the kernel. And being translated into specific access rights by an object manager according to the object type. It has array of the generic attributes mappings. Does the ntdll export RtlMapGenericMask have anything to do with mapping GENERIC_ flags into STANDARD_RIGHTS_? Is there any information regarding that? Hmm, I don't know nothing about that one. I did some reading about object manager and on of the functions of it is to translate those generic access flags into appropriate full attributes. What interesting is that it's not per object but per object type. So all files (real files, named pipes, etc) have the same mapping. I'm not sure how far should we go with this. But I have a big work cut out for me fixing wine's object manager. Vitaliy
