Re: LWN Timeline for 2008: Wine 1.0 made it!
2009/1/22 Austin English austinengl...@gmail.com: I wrote an article on common myths/mistruths (http://lwn.net/Articles/315071/), went in today's release (will be free to public in a week). Looks like the editors went with the first draft, which has a few more grammar errors, etc. If there are any more articles, I'll be sure to send them final copies, not proofs :-). Has anyone managed to concoct a Google Alert that reliably picks up most or all articles about Wine the software, but without a zilliion articles about wine the drink? - d.
Re: LWN Timeline for 2008: Wine 1.0 made it!
On Thu, Jan 22, 2009 at 08:28:07AM +, David Gerard wrote: 2009/1/22 Austin English austinengl...@gmail.com: I wrote an article on common myths/mistruths (http://lwn.net/Articles/315071/), went in today's release (will be free to public in a week). Looks like the editors went with the first draft, which has a few more grammar errors, etc. If there are any more articles, I'll be sure to send them final copies, not proofs :-). Has anyone managed to concoct a Google Alert that reliably picks up most or all articles about Wine the software, but without a zilliion articles about wine the drink? I am using windows emulator wine, seems to be pretty reliable, not sure if it catches everything. Ciao, Marcus
Re: msxml3: Implement IXMLDOMDocument2 IPersistStream_Save
Alistair Leslie-Hughes wrote: Hi, Helps http://bugs.winehq.org/show_bug.cgi?id=9012 Changelog: msxml3: Implement IXMLDOMDocument2 IPersistStream_Save Best Regards Alistair Leslie-Hughes No patch here.
Re: AppDB: Rating / Patching
On Tue, Jan 20, 2009 at 06:34:14PM +0100, Francois Gouget wrote: On Wed, 21 Jan 2009, Paul TBBle Hampson wrote: [...] What about apps that fail to include a necessary third-party library? If I understand the AppDB comments and followed the IRC discussion correctly, Warcraft 3's latest patch (1.22) was built with a newer Visual Studio and so requires new Visual C runtimes, while previous versions did not. And the patcher doesn't install these runtimes. If you don't need to manually install the third-party library on a stock installation of the application's officially supported Windows platform (e.g. Wow on Windows XP), then you should not need to manually install it in Wine. If you do, then that application cannot be rated platinum. True, but not the point I'm talking about. On a stock install of Windows XP, you'd have to go get the runtimes and install them, same as under a stock Wine prefix. On a well-used Windows XP install, you most likely already have the Visual Studio 7 runtimes installed, so won't notice the flaw in the installer. Same as under a well-used Wine prefix. To my mind, this shouldn't prevent the application being rated platinum. The maintainer of Warcraft 3 rather feels that until Wine implements the Visual Studio 7 runtime libraries as builtins, Warcraft 3 cannot be rated platinum. -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpaISRnbVZNa.pgp Description: PGP signature
Re: AppDB: Rating / Patching
On Thu, Jan 22, 2009 at 12:09:52PM +0100, Francois Gouget wrote: On Thu, 22 Jan 2009, Paul TBBle Hampson wrote: [...] If you don't need to manually install the third-party library on a stock installation of the application's officially supported Windows platform (e.g. Wow on Windows XP), then you should not need to manually install it in Wine. If you do, then that application cannot be rated platinum. True, but not the point I'm talking about. Strange. It seemed spot on to me and I have not seen anything that would make me think otherwise so far. On a stock install of Windows XP, you'd have to go get the runtimes and install them, same as under a stock Wine prefix. Are you sure? It's quite possible that some Windows component (IE 7, Messenger, a service pack, etc) installs these runtimes so that you would not see this issue on Windows XP (or Vista). If so the Warcraft 3 maintainer is correct and the application cannot be rated platinum. So maybe rather than 'stock Windows installation' I should say an 'up to date Windows installation with no third party software'. Warcraft III and Frozen Throne expansion was released to support Windows 98/ME/2k/XP. Nowhere in it's patch notes does it say that the minimum requirements to run Warcraft 3 have changed to have the minimum requirements of Windows 2k XP only. Since to my knowledge the Visual Studio 2008 (I believe that is 7, right?), doesn't have an runtimes for Windows 98 or ME. Basically to me the game developer dropped the ball, they shouldn't have compiled the patch contents in such a way that a) required a distributable that is not supported on all of the platforms they originally released a product for or b) failed to include the necessary runtimes when using any Visual Studio product. -- Darragh Nothing is foolproof to a sufficiently talented fool.
Re: AppDB: Rating / Patching
On Thu, 22 Jan 2009, Ben Klein wrote: [...] Perhaps the question remains, is a VC7 runtime library intended to be developed and shipped with Wine? I don't think this is the case. We have msvcirt, msvcrt, msvcrt20, msvcrt40, msvcr71 so I would not be so sure. Which dlls are we talking about anyway? msvcp80 and msvcr80? Or is it mfc80 that's needed? Btw, the AppDB mentions Visual C++ 2005 which means we're talking about VC8, not VC7. Or is the AppDB wrong? Or maybe I'm looking at the wrong AppDB entry: there's Reign of Chaos (rated platinum), and the Frozen Throne (rated gold). -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?
Re: AppDB: Rating / Patching
2009/1/22 Francois Gouget fgou...@free.fr: On Thu, 22 Jan 2009, Ben Klein wrote: [...] Perhaps the question remains, is a VC7 runtime library intended to be developed and shipped with Wine? I don't think this is the case. We have msvcirt, msvcrt, msvcrt20, msvcrt40, msvcr71 so I would not be so sure. Which dlls are we talking about anyway? I'm always happy to be corrected :) msvcp80 and msvcr80? Or is it mfc80 that's needed? Btw, the AppDB mentions Visual C++ 2005 which means we're talking about VC8, not VC7. Or is the AppDB wrong? Or maybe I'm looking at the wrong AppDB entry: there's Reign of Chaos (rated platinum), and the Frozen Throne (rated gold). Someone mentioned Warcraft 3, someone else mentioned WoW, I'm not sure any more. It's all too confusing when you're low on coffee :P
Re: WMF Support
I actually took some time out of my day (that I probably shouldn't have) to track down the issue and submitted a patch ( http://www.winehq.org/pipermail/wine-cvs/2009-January/052045.html). Not everything in the WMF files renders properly but at least Wine doesn't crash horribly, for now I've just pre-rendered the WMF files (we're distributing computers to students with this software, so we want things to look right). Also, there is a 15 day trial of the software :) Erich Hoover ehoo...@mines.edu On Wed, Jan 21, 2009 at 11:03 PM, Rolf Kalbermatter r.kalbermat...@hccnet.nl wrote: Erich Hoover wrote: I ran into an issue with WMF files in helping someone get an application to work (Athena Visual Studio) and I worked around it by pre-rendering the application's vector WMF files. I don't currently have the time to resolve the issue, but for when I do I'm curious whether there is a reason that OleLoadPicture* has been implemented manually. It seems that the LGPL libwmf has excellent support for both bitmap and vector WMF files (it at least worked for converting the files I had trouble with!), so it seems to me like it would make sense to use this library rather than spinning a separate implementation. Any comments are appreciated. Do you have somewhere the specific WMF file in question? The license is a bit to expensive to buy it just to test this ;-) Rolf Kalbermatter
Re: warning in wldap32/parse.c:447
Hi! Nikolay Sivov wrote: Hi, your patch for wldap32 added a warning: I know and I sent a patch to revert that change: http://www.winehq.org/pipermail/wine-patches/2009-January/067780.html and Alexandre rejected it: http://www.winehq.org/pipermail/wine-devel/2009-January/072151.html He is right and wrong in that email: - Right: wldap32 is broken for Win64 Wine builds - Wrong: I didn't do the long to LONG wldap32 changes but Francois. gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -g -O2 -o parse.o parse.c parse.c: In function ‘ldap_parse_vlv_controlW’: parse.c:447: warning: passing argument 5 of ‘ldap_parse_vlv_control’ from incompatible pointer type The warning is a minor nuisance but not an error. And that code isn't used with never openldap versions so not many people see it. That's why I didn't catch it first hand as there is no warning on F9 and F10. bye michael
Re: LWN Timeline for 2008: Wine 1.0 made it!
On 1/9/09, Francois Gouget fgou...@free.fr wrote: Sure they carry the Wine announcements, and occasionally mention an article about Wine in the Press section. But real articles about Wine? Nope. One almost gets the feeling that they don't like Wine for some reason... There was a full lead-in article in the Development section right when Wine hit the original Beta release - I wrote that. Jonathan Corbett really doesn't seem to have a strong opinion regarding Wine. Or, at least if he has a personal opinion he seems able to set it aside for the sake of whatever goes into LWN. I've exchanged a few emails with him at different times never got the feeling he didn't like Wine. It just doesn't seem to be something he uses to solve any problems he might have. LWN is definitely receptive to any articles. Things that come to mind would be an article describing Wine being used to get a specific Windows program to run. For example, how you could use Wine to make iTunes run (not sure if iTunes is actually working these days.) Another idea might be someone describing a backend development process used to make Wine do something neat. Like a technical description of what CodeWeavers did to get Chrome to run, or what Google has done to make the new version of Picasa work, etc. As compensation, they'll give a subscription to LWN for a year. That's what I got as compensation because I wasn't looking for $$$ and it was something they could give away without costing any $$$. -Brian
Re: Support for Dragon NS in Wine
Susan, thanks for your continued research. It's giving me a good grasp of reality. On that note, will it be possible to run the various MS Office 2003 apps. on the Mac with Crossover, or will there be so many snags that it makes more sense to buy the Office product designed for Mac? This is a question for all of you. On Wed, Jan 21, 2009 at 6:13 AM, Susan Cragin susancra...@earthlink.netwrote: Thanks to all of you. This is very helpful information. Susan, I appreciate your willingness to run more tests. I'm particularly interested in being able to run NS on CrossOver Mac by Codeweavers. I am planning on switching from a PC to a Mac, and for several reasons, I don't want to have to install the Windows operating system and use Boot Camp or Fusion. I already own NS 8 Professional and am hoping it can function on the Mac and be used on Office applications designed for the Mac (and on Mac applications, too). I don't need most of the features that go beyond the Preferred version, so if I stick to those features available on Preferred, would I get good functionality? Of course, if I could also use the feature that records and saves a transcript of specific dictations (not available on Preferred), it would be especially nice. Any possibility of your testing that out? I was hoping I could upgrade to the new version 10 and use it on the Mac, but it seems that would not be a good idea at this time. I'll be grateful for whatever further assistance you can provide. Steve D. On Tue, Jan 20, 2009 at 5:44 PM, Susan Cragin susancra...@earthlink.netwrote: On Tue, Jan 20, 2009 at 3:23 PM, Jeff Zaroyko jeffzaro...@gmail.com wrote: While I don't own any NS product, two open bugs to come to mind for NS 8, one affecting the installer but with a workaround, bug 15708 and the other a user has reported a regression bug 16248 but was not interested in running a regression test. http://bugs.winehq.org/show_bug.cgi?id=15708 http://bugs.winehq.org/show_bug.cgi?id=16248 I think those were both for NS 7, not 8... A full list of NS bugs is at http://bugs.winehq.org/buglist.cgi?quicksearch=Dragon+Naturally+Speaking Looks like 9 is happier than 10...? I have 7, 8, 9, 9.5 and 10 here. I'll test a couple tonight, maybe 7 and 8, on today's git. Here's what I remember. 7 worked great right out of the box at one time, with all-native code. 8 is virtually the same product as 7. Ditto worked great. (Nobody bought 8 much because it was the same engine as 7.) 9.0 worked pretty good out of the box with a couple of glitches. 9.5 does not install, and works not at all, except for one lucky man who developed a workaround that doesn't always work. (9.5 replaced 9.0 as version 9, and 9.0 is no longer sold, at least in the US.) 10.0 installs well and runs pretty well for 10 minutes, then nasty crashes happen. Wine support has been given primarily for the two cheapest consumer versions, Standard and Preferred. Very few people have asked about Professional, and I don't know of anyone who has tried to make Professional 8 run with wine. Susan Well, I tested 7 and 8 last night with a current git. For 7, bug 15708 is still active. I was unable to do the workaround. 8 installs and trains without a problem but then does not run. I filed a bug report. bug 17057. I will do a little more work on this and keep you updated. Susan -- Steven M. Druker Executive Director Alliance for Bio-Integrity www.biointegrity.org Home Office: (641) 472-8008
Re: Adjust dlls/iphlpapi/ipstats.c to FreeBSD 8
On Fri, 9 Jan 2009, Gerald Pfeifer wrote:
I am not aware of one. Tijl and me actually argued to get the
original behavior back (for this and other reasons like source
compatbility) but failed. I just pushed again.
FreeBSD upstream is not going to change, from what I can tell, so we
really need something like the following patch.
If you guys prefer something like
#ifndef RTF_LLINFO
#define RTF_LLINFO 0
#endif
instead, I can also create a patch for that!
Gerald
original message
From: Gerald Pfeifer ger...@pfeifer.com
To: wine-patc...@winehq.org
Date: Thu, 1 Jan 2009 20:32:51
Subject: Adjust dlls/iphlpapi/ipstats.c to FreeBSD 8
FreeBSD 8 is seeing a major rewrite of the arp code which removed
the RTF_LLINFO flag and thus broke Wine, among others, see
http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020464.html
and the follow-ups for details.
The patch below is the solution for Wine (and other ports) agreed upon
by the respective FreeBSD core maintainers; a variant thereof has been
explicitly reviewed and approved.
Gerald
ChangeLog:
Only use RTF_LLINFO if #defined, fixing FreeBSD 8 after the arp-v2
rewrite.
Index: dlls/iphlpapi/ipstats.c
===
RCS file: /home/wine/wine/dlls/iphlpapi/ipstats.c,v
retrieving revision 1.37
diff -u -3 -p -r1.37 ipstats.c
--- dlls/iphlpapi/ipstats.c 30 Jun 2008 13:28:42 - 1.37
+++ dlls/iphlpapi/ipstats.c 1 Jan 2009 19:24:21 -
@@ -1250,7 +1250,13 @@ DWORD getRouteTable(PMIB_IPFORWARDTABLE
DWORD getNumArpEntries(void)
{
#if defined(HAVE_SYS_SYSCTL_H) defined(NET_RT_DUMP)
- int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};
+ int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS,
+#ifdef RTF_LLINFO
+ RTF_LLINFO
+#else
+ 0
+#endif
+ };
#define MIB_LEN (sizeof(mib) / sizeof(mib[0]))
DWORD arpEntries = 0;
size_t needed;
@@ -1308,7 +1314,13 @@ DWORD getArpTable(PMIB_IPNETTABLE *ppIpN
#if defined(HAVE_SYS_SYSCTL_H) defined(NET_RT_DUMP)
if (table)
{
- int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS, RTF_LLINFO};
+ int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET, NET_RT_FLAGS,
+#ifdef RTF_LLINFO
+ RTF_LLINFO
+#else
+ 0
+#endif
+ };
#define MIB_LEN (sizeof(mib) / sizeof(mib[0]))
size_t needed;
char *buf, *lim, *next;
cmd.exe.manifest
0010:trace:file:RtlGetFullPathName_U (LC:\\windows\\system32\\cmd.exe.manifest 520 0xff9aaaf4 (nil)) attr= sharing=0001 disp=1 options=0010 ea=(nil).0x 0009:trace:seh:start_debugger Starting debugger winedbg --auto 8 100 ? ahh fer 's sake :) this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80. 0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x11,0002,0038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec1 LC:\\windows\\system32\\cmd.exe 0010:trace:heap:RtlFreeHeap (0x11,0002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec1 type #0018 name #0001 lang level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x11,0002,0060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x11,0002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (LC:\\windows\\system32\\cmd.exe.manifest,0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (LC:\\windows\\system32\\cmd.exe.manifest 520 0xffdc5f14 (nil)) ... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be themed. ... wossgoinon?! :) l.
Re: cmd.exe.manifest
2009/1/22 Luke Kenneth Casson Leighton l...@lkcl.net: 0010:trace:file:RtlGetFullPathName_U (LC:\\windows\\system32\\cmd.exe.manifest 520 0xff9aaaf4 (nil)) attr= sharing=0001 disp=1 options=0010 ea=(nil).0x 0009:trace:seh:start_debugger Starting debugger winedbg --auto 8 100 ? ahh fer 's sake :) this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80. 0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x11,0002,0038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec1 LC:\\windows\\system32\\cmd.exe 0010:trace:heap:RtlFreeHeap (0x11,0002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec1 type #0018 name #0001 lang level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x11,0002,0060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x11,0002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (LC:\\windows\\system32\\cmd.exe.manifest,0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (LC:\\windows\\system32\\cmd.exe.manifest 520 0xffdc5f14 (nil)) ... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be themed. cmd.exe *may* have a manifest, it's just that it won't specify common controls v6 (which enables the theming code in = XP). For example, patch.exe and install.exe in cygwin have .manifest files to tell Vista I am *not* an installer!. ... wossgoinon?! :) When Wine (or Windows = XP) loads a process (exe or dll), it looks for a .manifest file in the folder where the exe is located. If it does not find one there, it looks for a RT_MANIFEST resource in the processes resource block. Failing that, it assumes that the process was not built with a manifest. NOTE: I'm not sure on the ordering of the check for a manifest file (i.e. which takes precedence -- external file or embedded resource). In the trace log above, you can see that Wine is checking for an embedded manifest resource first, then the external .manifest file. So the problem lies elsewhere... do you have any more information on the debug output? - Reece
Re: msxml3/tests:domdoc.c Test doc pointer before using it (coverity)
On Thu, Jan 22, 2009 at 6:50 AM, Joris Huizer joris_hui...@yahoo.com wrote: From: Joris Huizer jorishui...@debian.(none) Your e-mail is messed up in the patches. Alexandre's scripts take the patch info over the e-mail headers, so you should fix that. -- -Austin
Re: cmd.exe.manifest
On Thu, Jan 22, 2009 at 6:59 PM, Reece Dunn mscl...@googlemail.com wrote: 2009/1/22 Luke Kenneth Casson Leighton l...@lkcl.net: 0010:trace:file:RtlGetFullPathName_U (LC:\\windows\\system32\\cmd.exe.manifest 520 0xff9aaaf4 (nil)) attr= sharing=0001 disp=1 options=0010 ea=(nil).0x 0009:trace:seh:start_debugger Starting debugger winedbg --auto 8 100 ? ahh fer 's sake :) this is after various complicated ways to create a subprocess with which to communicate (stdin / stdout) involving CreatePipe, open_osfhandle, - but it's being done from an app that's compiled with msvcr80. 0009: close_handle() = 0 0010:trace:heap:RtlAllocateHeap (0x11,0002,0038): returning 0x114e58 0010:trace:actctx:get_manifest_in_module looking for res #0001 in module 0x7ec1 LC:\\windows\\system32\\cmd.exe 0010:trace:heap:RtlFreeHeap (0x11,0002,0x114e58): returning TRUE 0010:trace:resource:LdrFindResource_U module 0x7ec1 type #0018 name #0001 lang level 3 0010:trace:resource:find_entry_by_id root 0x7ec322e4 dir 0x7ec322e4 id 0018 not found 0010:trace:actctx:get_manifest_in_associated_manifest looking for manifest associated with (null) id 1 0010:trace:heap:RtlAllocateHeap (0x11,0002,0060): returning 0x114e58 0009:trace:heap:RtlFreeHeap (0x11,0002,0x1361e0): returning TRUE 0010:trace:file:RtlDosPathNameToNtPathName_U (LC:\\windows\\system32\\cmd.exe.manifest,0xffdc6170,(nil),(nil)) 0009:trace:process:CreateProcessW started process pid 000f tid 0010 0010:trace:file:RtlGetFullPathName_U (LC:\\windows\\system32\\cmd.exe.manifest 520 0xffdc5f14 (nil)) ... but hang on... some notes somewhere after a google search for cmd.exe.manifest, apparently there isn't supposed to _be_ a manifest for cmd.exe - so that it can't be themed. cmd.exe *may* have a manifest, it's just that it won't specify common controls v6 (which enables the theming code in = XP). For example, patch.exe and install.exe in cygwin have .manifest files to tell Vista I am *not* an installer!. ... wossgoinon?! :) When Wine (or Windows = XP) loads a process (exe or dll), it looks for a .manifest file in the folder where the exe is located. If it does not find one there, it looks for a RT_MANIFEST resource in the processes resource block. Failing that, it assumes that the process was not built with a manifest. NOTE: I'm not sure on the ordering of the check for a manifest file (i.e. which takes precedence -- external file or embedded resource). In the trace log above, you can see that Wine is checking for an embedded manifest resource first, then the external .manifest file. So the problem lies elsewhere... do you have any more information on the debug output? hiya reece, thanks for responding. yes, i do - lemme get back to you with it: i'm in the middle of a ... actually, i _do_ have it: http://lkcl.net/subprocess.wine.trace it's a trace+all so is about 15mb (sorry!) i'm doing a rebuild back to msvcrt to see if the problem goes away. reproducing this in c-code will be quite a bit of work - it's not like the other tests i did (the msvcrt ones) - it'll be about... 150 to 200 lines of c code, doing a CreateProcess and other tricks, and would take about a day to go through the python code, replicating the python subsytems being used _without_ the python. and this is getting pretty draining - it's been a _lot_ of work. l.
Re: cmd.exe.manifest
So the problem lies elsewhere... do you have any more information on the debug output? hiya reece, thanks for responding. yes, i do - lemme get back to you with it: i'm in the middle of a ... actually, i _do_ have it: it's a trace+all so is about 15mb (sorry!) i'm doing a rebuild back to msvcrt to see if the problem goes away. http://lkcl.net/subprocess.wine.trace.msvcrt.native and, once that's uploaded, i'll also do one: http://lkcl.net/subprocess.wine.trace.msvcrt.builtin but give me a few mins to do that one, it'll be there in a bit. here's the python application that did that: import subprocess p = subprocess.Popen([cmd, /k echo, hello], stdout=subprocess.PIPE) (stdout, stderr) = p.communicate() print repr(stdout) print repr(stderr) nice and short, isn't it? :) the code that goes with that - in the python subprocess module - is a bit of a lairy hairy bundle of fun. anyway, as you can see, open_osfhandle and CreateProcess all go swimmingly well - it's just that when you get msvcr80 involved it all goes pearshaped. l.
Re: cmd.exe.manifest
On Thu, Jan 22, 2009 at 8:14 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: So the problem lies elsewhere... do you have any more information on the debug output? hiya reece, thanks for responding. yes, i do - lemme get back to you with it: i'm in the middle of a ... actually, i _do_ have it: it's a trace+all so is about 15mb (sorry!) i'm doing a rebuild back to msvcrt to see if the problem goes away. http://lkcl.net/subprocess.wine.trace.msvcrt.native sorry that's ... oh bugger it i'll log in to my server and correct it :) and, once that's uploaded, i'll also do one: http://lkcl.net/subprocess.wine.trace.msvcrt.builtin anyway, as you can see, open_osfhandle and CreateProcess all go swimmingly well - it's just that when you get msvcr80 involved it all goes pearshaped. ahh... correction... err... actually, builtin msvcrt _doesn't_ go according to plan! the data is returned (echo hello) but the python process hangs - it never sees the results come back. ahh -it i'm going to have to write a c test case, aren't i.
Re: cmd.exe.manifest
ahh... correction... err... actually, builtin msvcrt _doesn't_ go according to plan! the data is returned (echo hello) but the python process hangs - it never sees the results come back. correction: the reason for that was that my test case had cmd /k echo test not cmd /c echo test. so i needed to type exit return. so, we conclude that the child process creation code using msvcrt is fine but with msvcr80 is buggered. i've found a test example (KB Q190351) which does a reaaasonable job - reading from the console of the child doesn't work. so the code from Q190351 would be a _good_ one to use. or write a test case based on Modules/posixmodule.c.
Re: Problems with configure on Mac
James Mckenzie wrote: Cesar Izurieta ce...@ecuarock.net wrote: Sent: Jan 21, 2009 7:49 AM To: James Mckenzie jjmckenzi...@earthlink.net Cc: Wine Development Mailing List wine-devel@winehq.org Subject: Re: Problems with configure on Mac Try something like: LDFLAGS=-L/opt/local/lib CPPFLAGS=-I/opt/local/include/ ./configure You need to specify both the library dirs and the include dirs. This is using macports. For fink I guess the libraries are located somewhere under /sw IIRC. I'll find them and use them this evening after reviewing the log file. Used the proper directories for Fink and built it after addressing a few more 'missing dependencies'. However when I run wine notepad, I get a lengthy error. The thread on gdi32.dll errors addresses some of this. However, the .wine directory gets created but it is partially empty which leads me to believe there is a problem with my build as yours works. One question: What version of gcc are you using to build Wine? Thank you. James McKenzie
Re: Running a simple .Net 3.0 application.
On 2009-01-14 (Wednesday) 20:59:09 Louis Lenders wrote: ... 7. Now Run the app, it crashes into a bunch of unimplemented functions. Fortunately just simple stubs were enough to make the app happy. I added stubs for gdi32.GdiEntry13 kernel32.WerRegisterMemoryBlock ntdll.NtSecureConnectPort ntdll.RtlEnumerateGenericTableWithoutSplaying ntdll.RtlIsGenericTableEmpty Well, that was enough to get the app running. ... I'm not sure if it would be useful to open bugs already for the unimplemented functions. If so, just shout, and i'll open some bugs. Can you please e-mail me or post here as attachment stubs you have implemented so I don't duplicate work you already done? Are you planning to send a patch for at least GdiEntry13? If not then may be I will. And I think it would be useful to have bugs for these functions if you aren't going to send patches to implement them at least as stubs in near future. Thank you very much for useful tips (especially for mentioning InstallRite - didn't know about it before)! Conclusion: once the installer is fixed, there's good chance simple .net 3.0 at least apps will run quickly I think not just simple apps but even very complex ones like SolidWorks 2009! I successfully installed SolidWorks 2009 in Wine by using InstallRite InstallKit (created in clean Windows XP SP2). And I was actually able to run it (however one native override was necessary to really run it). Some basic things work; however SolidWorks affected by some bugs which prevent its normal operation - for example it crashes because of gdi32.GdiEntry13 being not implemented if I try to do some usual things (for example, creating new part using standard template). SolidWorks is .NET 3.0 application and it expect this function implemented (hopefully stub implementation will be enough).
