Re: Wrong status of gdi32
On Tue, Oct 8, 2013 at 11:54 AM, C.W. Betts computer...@hotmail.com wrote: Some of those are probably Wine-specific, and/or are forwarded from other DLLs. On Oct 8, 2013, at 8:35 AM, Akira Nakagawa matyapir...@gmail.com wrote: I found this page shows that gdi32 dll has more than 800 functions,but the spec file has only 500 . That info is from the windows 8 dll, not wine's. Wine doesn't implement the full win32 API, only what is needed to run applications. If you've got an application that doesn't run because of a missing gdi32 function, please report it to bugzilla: https://bugs.winehq.org -- -Austin
Fwd: [GSoC Mentors Announce] Re: GSoC 2013 Mentors/Org Admins: Pencils Down and Final Evaluation Dates Approaching
-- Forwarded message -- From: Carol Smith car...@google.com Date: Mon, Sep 23, 2013 at 12:04 PM Subject: [GSoC Mentors Announce] Re: GSoC 2013 Mentors/Org Admins: Pencils Down and Final Evaluation Dates Approaching To: GSoC Mentors Announce gsoc-mentors-annou...@googlegroups.com Hi GSoC 2013 mentors and org admins, This is just a friendly reminder that final evaluations are now open and must be submitted by this Friday, 27 September at 19:00 UTC. Don't delay, submit today! Thanks, Carol -- -Austin
Adding an appcompat/appshim bugzilla keyword
Anastasius mentioned at http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for bugs that are caused by applications using broken/deprecated behavior might be useful. I'm in favor of it, but wanted some more opinions (and potentially a better naming scheme). Comments/opinions? -- -Austin
Re: [AppDB] How to deal with hardware/driver dependent test result?
On Tue, Aug 27, 2013 at 8:57 PM, Felix Yan felixonm...@gmail.com wrote: Hi, I'm maintaining Spore 1.0, and it works correctly in wine for over a year on Nvidia video card with closed-source nvidia driver - but I do noticed with Intel cards with open source drivers, the game is nearly not playable - missing texture and more problems. Today comes in a new test result that mark the game as Garbage, while the description is exactly what happened on my laptop with Intel chip. What should I do about this? To proceed with the test result and change the game to Garbage stage, or reject with Nvidia cards works fine? I don't think either is fine, so I come to the list for help. Thanks! Regards, Felix Yan It's a valid report. Submitting more up to date results with Nvidia so users know it works there would be helpful (as well as a note in the HowTo section, for example). -- -Austin
Re: Request to delete some attachments
On Thu, Aug 22, 2013 at 1:23 PM, Ken Sharp kennyb...@o2.co.uk wrote: Could a Bugzilla admin please delete the attachments in http://bugs.winehq.org/show_bug.cgi?id=24867 ? I don't know if metatester.exe can be freely distributed. Done. -- -Austin
Re: Willing to join Wine
On Tue, Aug 20, 2013 at 3:13 AM, Priyank Bhatt priyankbhatt1...@gmail.com wrote: I want to work for Wine . I'm a third year undergraduate Student , I have done my elimentary course on machine learning algorithm . I am also familiar with C/C++ and some what of Python . Please suggest what all do I need to learn or read so as to start contributing to the open source community of mlpack. As an amateur and as per your free slots what project form the idea's page should I work on ? If you want to work on Wine, the best place to start would be: http://wiki.winehq.org/Developers Though your email seems like a copy/paste from a GSoC application for mlpack...note that GSoC has already started, you'd have to wait until next year (and put more effort than a simple copy/pasted email). -- -Austin
Re: wine-bugs change?
On Tue, Aug 13, 2013 at 8:57 AM, Thomas Spear speeddy...@gmail.com wrote: Thanks Henri. Sadly, when I tried that, it filtered nothing at all, just the same as the issue I originally reported. Probably a gmail problem with filtering on the List-Id, as they don't have proper support for matching it in filters, only searches. Thank you, Thomas On Tue, Aug 13, 2013 at 10:54 AM, Henri Verbeet hverb...@gmail.com wrote: On 13 August 2013 17:23, Bruno Jesus 00cp...@gmail.com wrote: My filters are still working fine, probably they are configured the same as yours: Matches: to:(wine-devel@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam Matches: from:(wine-b...@winehq.org) Do this: Skip Inbox, Apply label WineDevel, Never send it to Spam In case anyone finds this useful, you'll generally want to filter mailing lists based on the List-Id header. The recent Gmail changes for bulk/social network notifications/etc. email may be the cause: http://gmailblog.blogspot.com/2013/05/a-new-inbox-that-puts-you-back-in.html -- -Austin
Re: wine mannual is wrong?
On Mon, Aug 5, 2013 at 7:49 AM, 中川祥 matyapir...@gmail.com wrote: I'm interpretering wine.man. I found it saysthis requires X11 to run. But the newest ver. does not require X11,does it? Yes. Unless you're on Mac and use the Mac driver instead. -- -Austin
Re: Wiki RFC: Redirects, swarm tactics, etc.
On Thu, Aug 1, 2013 at 11:03 PM, Kyle Auble kau...@lavabit.com wrote: So I've finished with pretty much all of the edits I had in mind for the wiki, but before I ride off into the sunset for a while, I wanted to toss out a few ideas. .. 2. There's still a lot of old/missing content on the wiki, and much of it requres a good sense of where the code is at. Also, it might be too overwhelming for one person to work in depth on more than a few pages at this point. I feel like a semi-coordinated swarm of editing might be the best bet for further improvements. I was picturing a table of all relevant pages, then people could adopt one or two to work on, then strike/delete a record once that page is finished. Any thoughts? I'll help, if you have a list of pages that you need edited. -Austin
Re: ws2_32/tests: Test the precedence of parameters while creating a socket in WSASocket()
On Tue, Jul 30, 2013 at 5:13 PM, Bruno Jesus 00cp...@gmail.com wrote: You forgot the patch. -- -Austin
Re: kernel32: Correct log on / logon (noun / verb)
On Wed, Jul 24, 2013 at 4:37 PM, Ken Sharp kennyb...@o2.co.uk wrote: Evening Winos, Attached is a patch to correct some winerr messages. Specifically change a noun to a verb, and update the .po files with it. Firstly, could you take a look and point out any obvious errors I may have made? I have marked some of the translations fuzzy because it's not clear if the original translator realised that this should have been the verb and not the noun. A quick look through the translations on Wikipedia suggests that most languages do use different terms for the noun and the verb. https://cs.wikipedia.org/wiki/Login https://de.wikipedia.org/wiki/Login_(Informationstechnik) https://es.wikipedia.org/wiki/Login and so on. Some of these listings seem to use completely different words to the current translation in Wine so I wouldn't dare make a guess. For logon/log on, at least from an American viewpoint, your change is correct. Secondly, what do people think about the use of Can't as opposed to Cannot? I have not made the change in the patch but I'm wondering if people think that this should be done. Can't is informal and as my old English teacher would say, Can't is not a word! It is, but being pedantic cannot is probably the better choice. I assume Windows uses can't seen as it listed in winerror.mc. Can't is definitely informal, but cannot seems a bit too formal for the strings that are currently in en.po, imo. I don't have a strong preference on this, though.
Re: windowscodecs: Workaround libtiff bug when it defines toff_t as 32-bit for 32-bit builds.
I had filed a bug with Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=459820 On Jul 25, 2013 5:31 PM, Vincent Povirk madewokh...@gmail.com wrote: I have no opinion on this sort of work-around (it should work afaict, and I haven't found any other places where we currently use toff_t), but did you file a bug with whatever distro has such broken headers?
Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
On Mon, Jul 1, 2013 at 7:11 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-07-01 19:58+0100 Hin-Tak Leung wrote: --- On Mon, 1/7/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: ... I hope your negative attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows. ... Look. You have been advised a few times, that it is possible and even easy to bypass installation-related problems and been given brief instructions on how to do so. The problem discussed on this thread is not with the generic part of the installation you have referred to but instead the problem is with running one of the post install scripts that is invoked by setup.exe. you have also been told, *many times*, and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list. Many times by you and once by a Cygwin developer. I have answered both, but I am going to try again now since you brought it up again. Even if that assertion were true (something we don't know until some Wine developer with an interest in Cygwin systematically looks at it for the latest Wine to see how many Cygwin bugs are left for that much improved version of Wine) it only strengthens my argument. The fact remains, Cygwin is open-source software so in theory (i.e., the Wine developer pursuing this opportunity will need some knowledge of Cygwin) you know exactly what is going on with the calls to Windows software, and you can also directly compare results for those calls between the Wine version and Microsoft version of Windows. Therefore I think it is obvious that Cygwin represents a good opportunity to get rid of Wine bugs. If there are a lot of such bugs like you and the Cygwin developer assert, then it represents even a bigger opportunity to debug those Wine issues with exact source code in hand that demonstrates the issue. I think we don't really know what bugs are still left in recent Wine until a systematic evaluation is done of Cygwin on Wine, but my argument stands whether there are a lot of such bugs or only a few. While it's likely that debugging this (and other) Cygwin problems with Wine would find and eliminate bugs from Wine, it also takes a lot of effort and know how to do so. That time is often better spent on issues that require less effort to debug, and help more user visible applications. In other words, while fixing Cygwin issues is a valuable effort, it takes a lot of time and effort that is better spent elsewhere. If you want to spend that time and effort, feel free to do so. But asking others to spend their time to debug issues that fix Cygwin isn't likely to find many volunteers. -- -Austin
Re: [RFC PATCH] loader: allow overriding pthread_create correctly on linux
On Fri, Jun 28, 2013 at 3:53 AM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
This should be enough to fix bug #30557 in the most thorough possible way.
Only tested on ubuntu precise 32-bits atm, but I believe it should work on
64-bits too.
TODO: pthread_create_2_0 is not handled correctly right now, so it will fail
on ancient glibc's 2.2.
But because NPTL requires a slightly newer glibc than that I do not believe
it will be a real issue.
Comments welcome :-)
---
diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c
index 01a8026..e9775c3 100644
--- a/dlls/ntdll/thread.c
+++ b/dlls/ntdll/thread.c
@@ -33,6 +33,7 @@
#ifdef HAVE_SYS_SYSCALL_H
#include sys/syscall.h
#endif
+#include errno.h
#define NONAMELESSUNION
#include ntstatus.h
@@ -58,6 +59,7 @@ struct startup_info
TEB*teb;
PRTL_THREAD_START_ROUTINE entry_point;
void *entry_arg;
+BOOLnative_thread;
};
static PEB *peb;
@@ -186,6 +188,20 @@ done:
return status;
}
+#ifdef __linux__
+extern typeof(pthread_create) *__glob_pthread_create, *call_pthread_create;
+static typeof(pthread_create) __hook_pthread_create;
+
+static void thread_wrap_init(void)
+{
+call_pthread_create = __hook_pthread_create;
+}
+
+#else
+#define __glob_pthread_create pthread_create
+#define thread_wrap_init()
+#endif
+
/***
* thread_init
*
@@ -204,6 +220,7 @@ HANDLE thread_init(void)
struct ntdll_thread_data *thread_data;
static struct debug_info debug_info; /* debug info for initial thread */
+thread_wrap_init();
virtual_init();
/* reserve space for shared user data */
@@ -327,11 +344,7 @@ void terminate_thread( int status )
pthread_exit( UIntToPtr(status) );
}
-
-/***
- * exit_thread
- */
-void exit_thread( int status )
+static void exit_thread_common( int status )
{
static void *prev_teb;
TEB *teb;
@@ -377,9 +390,60 @@ void exit_thread( int status )
close( ntdll_get_thread_data()-wait_fd[1] );
close( ntdll_get_thread_data()-reply_fd );
close( ntdll_get_thread_data()-request_fd );
+}
+
+void exit_thread( int status )
+{
+exit_thread_common(status);
pthread_exit( UIntToPtr(status) );
}
+#ifdef __linux__
+
+struct unix_arg {
+void *(*start)(void *);
+void *arg;
+};
+
+/* dummy used for comparison */
+static DWORD native_unix_start;
+
+static void call_native_cleanup(void *arg)
+{
+RtlFreeThreadActivationContextStack();
+exit_thread_common(0);
+}
+
+static int
+__hook_pthread_create(pthread_t *thread, const pthread_attr_t *attr,
+ void *(*start_routine) (void *), void *parm)
+{
+NTSTATUS ret;
+struct unix_arg arg;
+arg.start = start_routine;
+arg.arg = parm;
+
+TRACE(Overriding thread creation!\n);
+if (attr)
+FIXME(thread attributes ignored!\n);
+
+ret = RtlCreateUserThread( NtCurrentProcess(), NULL, FALSE, NULL, 0, 0,
(void*)native_unix_start, arg, NULL, (void*)thread );
+if (ret != STATUS_SUCCESS)
+FIXME(ret: %08x\n, ret);
+switch (ret) {
+case STATUS_SUCCESS:
+return 0;
+case STATUS_NO_MEMORY:
+return ENOMEM;
+case STATUS_TOO_MANY_OPENED_FILES:
+return EMFILE;
+default:
+ERR(Unhandled ntstatus %08x\n, ret);
+return ENOMEM;
+}
+}
+
+#endif
/***
* start_thread
@@ -412,9 +476,18 @@ static void start_thread( struct startup_info *info )
if (TRACE_ON(relay))
DPRINTF( %04x:Starting thread proc %p (arg=%p)\n,
GetCurrentThreadId(), func, arg );
-call_thread_entry_point( (LPTHREAD_START_ROUTINE)func, arg );
-}
+#ifdef __linux__
+if (info-native_thread) {
+void *(*start)(void*) = (void*)func;
+FIXME(Started native thread %08x\n, GetCurrentThreadId());
+pthread_cleanup_push(call_native_cleanup, NULL);
+pthread_exit(start(arg));
+pthread_cleanup_pop(1);
+} else
+#endif
+call_thread_entry_point( (LPTHREAD_START_ROUTINE)func, arg );
+}
/***
* RtlCreateUserThread (NTDLL.@)
@@ -497,8 +570,18 @@ NTSTATUS WINAPI RtlCreateUserThread( HANDLE process,
const SECURITY_DESCRIPTOR *
info = (struct startup_info *)(teb + 1);
info-teb = teb;
-info-entry_point = start;
-info-entry_arg = param;
+#ifdef __linux__
+info-native_thread = (void*)start == (void*)native_unix_start;
+if (info-native_thread) {
+struct unix_arg *arg = param;
+info-entry_point =
Re: riched20: ITextDocument implementation
On Wed, Jun 26, 2013 at 1:32 AM, Qian Hong fract...@gmail.com wrote: Hi, Welcome again :) On Wed, Jun 26, 2013 at 3:11 PM, Tiger Soldier tigerso...@gmail.com wrote: This is my first time to develop WINE. Any comments/suggestions? [1] http://bugs.winehq.org/show_bug.cgi?id=17042 Improving Rich Edit is great appreciated! Interesting, one of GSoC2013 students Jactry Zeng is planning on implementing ITextDocument as well [1] [2]. Maybe it is a good idea to work with Jactry together, if that doesn't violate GSoC rules - actually I don't know, hopefully Austin English or other GSoC mentor/manager could comment on this. There's nothing preventing someone else from working on the same area of code (we can't control what other people do). However it is still the responsibility of the student to complete their proposal. -- -Austin
Re: wined3d: print the architecture when showing driver problems
On Mon, Jun 24, 2013 at 12:20 AM, Henri Verbeet hverb...@gmail.com wrote:
On 23 June 2013 07:10, Austin English austinengl...@gmail.com wrote:
Please consider applying before the release of 1.6. It has no
functional changes, but would really help when diagnosing user
problems.
This is not really a wined3d patch. That said, while I agree that
printing the architecture would be useful here, you can probably avoid
the #ifdef by using something along the lines of sizeof(void *) == 8 ?
64-bit : 32-bit, although ideally we'd probably get the actual
architecture from somewhere like ntdll.
My understanding was that using the _WIN64 macro was preferred. I can
certainly do that instead. How's this?
--
-Austin
From 0cc848b88f98f7da67671bbedb0a28c16cad2d66 Mon Sep 17 00:00:00 2001
From: Austin English austinengl...@gmail.com
Date: Tue, 25 Jun 2013 18:52:02 -0700
Subject: [PATCH] wined3d: print the architecture when showing driver problems
(try 2)
---
dlls/winex11.drv/opengl.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index cd24575..a3199cb 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -464,7 +464,8 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
if(pglXMakeCurrent(gdi_display, win, ctx) == 0)
{
-ERR_(winediag)( Unable to activate OpenGL context, most likely your
OpenGL drivers haven't been installed correctly\n );
+ERR_(winediag)( Unable to activate OpenGL context, most likely your
%s OpenGL drivers haven't been
+installed correctly\n, sizeof(void *) == 4 ?
32-bit:64-bit );
goto done;
}
gl_renderer = (const char *)opengl_funcs.gl.p_glGetString(GL_RENDERER);
@@ -506,9 +507,10 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
* Detect a local X11 server by checking whether the X11 socket is a
Unix socket.
*/
if(!getsockname(fd, (struct sockaddr *)uaddr, uaddrlen)
uaddr.sun_family == AF_UNIX)
-ERR_(winediag)(Direct rendering is disabled, most likely your
OpenGL drivers
+ERR_(winediag)(Direct rendering is disabled, most likely your %s
OpenGL drivers
haven't been installed correctly (using GL
renderer %s, version %s).\n,
- debugstr_a(gl_renderer),
debugstr_a(WineGLInfo.glVersion));
+ sizeof(void *) == 4 ? 32-bit:64-bit,
debugstr_a(gl_renderer),
+ debugstr_a(WineGLInfo.glVersion));
}
else
{
@@ -522,9 +524,10 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
* it shows 'Mesa X11'.
*/
if(!strcmp(gl_renderer, Software Rasterizer) || !strcmp(gl_renderer,
Mesa X11))
-ERR_(winediag)(The Mesa OpenGL driver is using software
rendering, most likely your OpenGL
+ERR_(winediag)(The Mesa OpenGL driver is using software
rendering, most likely your %s OpenGL
drivers haven't been installed correctly (using GL
renderer %s, version %s).\n,
- debugstr_a(gl_renderer),
debugstr_a(WineGLInfo.glVersion));
+ sizeof(void *) == 4 ? 32-bit:64-bit,
debugstr_a(gl_renderer),
+ debugstr_a(WineGLInfo.glVersion));
}
ret = TRUE;
--
1.8.2.1
Re: [bugzilla] Add descriptions for additional resolutions (try 2)
On Tue, Jun 18, 2013 at 4:12 AM, Alexandre Julliard julli...@winehq.org wrote: André Hentschel n...@dawncrow.de writes: +dd + The problem is not a [% terms.bug %] in Wine, + but in some upstream software Wine depends on or broken + packages in distributions. + Note: Most other bug trackers call this NOTOURBUG. We should probably rename it. UPSTREAM is not a good name for the way we are using it. -- Alexandre Julliard julli...@winehq.org What did you have in mind instead? -- -Austin
Re: [bugzilla] Add descriptions for additional resolutions (try 2)
On Tue, Jun 18, 2013 at 1:02 PM, Rosanne DiMesio dime...@earthlink.net wrote: NOTOURBUG or 3RDPARTY seem to be the most common. NOTOURBUG would be clearer to users. We generally refer to things like PlayOnLinux, Wineskin, etc. as third party, so using that could potentially cause some confusion. NOTOURBUG is fine with me. -- -Austin
Re: Using of mac driver completely breaks tablets support?
On Sun, Jun 16, 2013 at 3:46 PM, Frédéric Delanoy frederic.dela...@gmail.com wrote: On Wed, Jun 12, 2013 at 6:35 PM, Ken Thomases k...@codeweavers.com wrote: Hi, On Jun 12, 2013, at 10:47 AM, Andrey Upadyshev wrote: How can I switch back to x11 driver? In the registry, set the following: [HKEY_CURRENT_USER\Software\Wine\Drivers] Graphics=x11 Some of the basics of how to do that (although not this specific thing) are documented at http://wiki.winehq.org/UsefulRegistryKeys. Regards, Ken You should probably document this setting on the wiki and/or in the FAQ. Frédéric I've added it to: http://wiki.winehq.org/UsefulRegistryKeys and to winetricks (macdriver=mac / macdriver=x11): https://code.google.com/p/winetricks/source/detail?r=997 -- -Austin
Fwd: [GSoC Mentors Announce] GSoC 2013: Mentor Summit Travel and Details
FYI for GSoC mentors. It's a ways away, but have the date in mind if you'd like to attend. Remember we have two slots, so if there are more than 2 people, we'll give preference to people that haven't gone before. -Austin -- Forwarded message -- From: Carol Smith car...@google.com Date: Thu, Jun 13, 2013 at 11:23 AM Subject: [GSoC Mentors Announce] GSoC 2013: Mentor Summit Travel and Details To: gsoc-mentors-announce gsoc-mentors-annou...@googlegroups.com Hi everyone, The Google Summer of Code Mentor Summit is approaching! When: 19-20 October, 2013 Where: Google Headquarters, Mountain View, California Some brief background: The Google Summer of Code Mentor Summit is a two-day unconference [0] that brings together two mentors (or org admins) from each of the mentoring organizations that has participated in GSoC that year. Google pays for a two-night hotel stay, transportation costs, conference facilities, and food for the weekend, and the attendees make the agenda. We've consistently heard from mentors over the years that the summit was one of the best conferences of the year for them. The opportunity to meet face-to-face with other FOSS community members is a valuable experience, as is the time spent discussing ideas in a casual forum where everyone's voice can be heard. I'd encourage your organization to send delegates to the summit even if you don't quite understand of the utility of it now - I feel confident you won't be disappointed with the results. Attendees stay at the Wild Palms hotel [1] while they're in town and we serve a traditional dinner of thai food on Friday night and have a pool party on Saturday night. Here's how to proceed with booking and attending: 1) Your organization will need to decide on two delegates [2] to send to the event. Any people who want to attend above and beyond the two from your org will need to list themselves on the Waiting List [3] and wait for word from me about extra space as we get closer to the event. NB: The wiki requires a login when visiting for the first time. The username is mentor and the password is yourock. I highly recommend creating your own account with a unique password once you have logged in for the first time. 2) Once your organization has decided on the two delegates it would like to send to this year's event, those individuals can feel free to book their hotel rooms at the Wild Palms [4] now. Please note that if the Wild Palms fills up you will need to make your reservation with the Domain Hotel instead [5]. If you really want to stay at the Wild Palms, make sure to book early! We'll have shuttles running between the hotels and to campus for the whole weekend. NB: The hotel registration deadline is 6 September. If you really want to stay at the Wild Palms, I'd recommend you book early. :-) 3) Please fill out the Mentor Summit Preparation form [6] as soon as you have confirmed your hotel room. 4) We include the reimbursement for travel to the mentor summit and the mentor stipends in one PO to your organization. Please see the payment info page [7] for more detail on this. These POs will be issued to your org soon after it has made the payment request. 5) Flights should be purchased once you have a confirmed PO. All orgs pay for plane tickets ahead of time and then request reimbursement via invoice against the PO once you have receipts for the flights. 6) Please check out the wiki [8] and fill in your name if you're attending. Look around the rest of the site - it has lots of useful information for you about the event and what to expect. 7) In the unlikely event that your organization does not plan to attend the mentor summit at all, please fill out this form [9] to let me know. Please only fill this out if you are not sending *any* delegates to the summit. 8) We are doing session scheduling for this year's summit via Google Moderator. Please fill in your ideas for sessions on the webpage [10] by 27 September and vote for your favorite ideas! You can read more about how we're running session scheduling this year on the wiki [11]. 9) Please remember that any organization that misses two or more evaluation deadlines may not attend the summit. If you book travel and then get uninvited from the summit after the either the midterm or the final evaluations you will not be reimbursed for travel costs and your hotel stays will be cancelled. So don't miss those evaluations or you jeopardize missing the event! [0] - http://en.wikipedia.org/wiki/Unconference [1] - http://www.jdvhotels.com/hotels/siliconvalley/wild_palms [2] - A delegate is defined as either a mentor or org admin who participated in this year's GSoC program. We're sorry, but we can't accomodate other people from your organization who did not mentor or administer this year. Also, we will not accept any mentors who miss an evaluation deadline in this year's program. Please contact me if you have questions about if a person from your organization is on this
Re: joy.cpl icon
On Thu, Jun 6, 2013 at 2:15 AM, Joel Holdsworth j...@airwebreathe.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For some reason, since I send in my icon for joy.cpl, it doesn't appear in the control panel - still only the wine glass fallback icon. Does anyone know why this is? I guess it will be a one line fix. Unfortunately I don't have time do this myself, but if someone has time, I think it would be worth resolving before the release. Best Regards Joel Holdsworth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRsFMgAAoJEIsWlGmq62Igf70H/jE97ibCOk2j2BMizaGkGzyW nAGQD0R9E3GXfdnGaUxzn21OPq3cu3/FapiTw1eN5Ns7Ec4b1cBLJ+ana1ElLIrO bz+yYGedqD0bYZq0D80MPE7t9S6jGy7939XGvkNLSMcZVOaBy8E2iroVnAILMNSB w1zbPhDXQGjHjRyBuYHZMhXTPhDz73s8+6JS7lZvCTaMmnF/dzZ6tW7DyTUIBdwx u3zUXn/j4nTNuNw3xGtK5wSYUZdNWxEx8RvQ1JrfuR9CWwLILTfFLB9d7OnSH/Rg 0sxBkjpSkOck25NN9gdQwdud0ERda1JurongrxUSHDXBBxghJ9BIk/gd+ZpP4cQ= =Hnk+ -END PGP SIGNATURE- http://source.winehq.org/git/wine.git/commitdiff/6528aff97ba74fad20571acae33228a893bb4a7f -- -Austin
Re: ntdll: Add stub for LdrResolveDelayLoadedAPI and reference it in kernel32
On Wed, Jun 5, 2013 at 7:10 PM, Dmitry Timoshkov dmi...@baikal.ru wrote:
André Hentschel n...@dawncrow.de wrote:
diff --git a/include/delayloadhandler.h b/include/delayloadhandler.h
new file mode 100644
index 000..e48e415
--- /dev/null
+++ b/include/delayloadhandler.h
I don't see such file in PSDK 7.1, where does it come from?
diff --git a/include/winnt.h b/include/winnt.h
index 171141e..393f5a7 100644
--- a/include/winnt.h
+++ b/include/winnt.h
@@ -3052,6 +3052,28 @@ typedef struct _IMAGE_RELOCATION
#define IMAGE_SIZEOF_RELOCATION 10
+typedef struct _IMAGE_DELAYLOAD_DESCRIPTOR
+{
+union
+{
+DWORD AllAttributes;
+struct
+{
+DWORD RvaBased:1;
+DWORD ReservedAttributes:31;
+};
+} Attributes;
+
+DWORD DllNameRVA;
+DWORD ModuleHandleRVA;
+DWORD ImportAddressTableRVA;
+DWORD ImportNameTableRVA;
+DWORD BoundImportAddressTableRVA;
+DWORD UnloadInformationTableRVA;
+DWORD TimeDateStamp;
+} IMAGE_DELAYLOAD_DESCRIPTOR, *PIMAGE_DELAYLOAD_DESCRIPTOR;
+typedef const IMAGE_DELAYLOAD_DESCRIPTOR *PCIMAGE_DELAYLOAD_DESCRIPTOR;
Same question here about IMAGE_DELAYLOAD_DESCRIPTOR. Besides, the structure
contains namesless structure which is not compatible with some compilers and
needs to be fixed.
--
Dmitry
Widl handles nameless structs fine:
http://source.winehq.org/git/wine.git/commitdiff/76693d52c7b2d199df9d1f0e6051b2ffa333b8e1
--
-Austin
Re: api-ms-win-core-localregistry-l1-1-0: add stub dll
On Tue, Jun 4, 2013 at 5:05 PM, Charles Davis cdavi...@gmail.com wrote: On Jun 4, 2013, at 12:15 PM, Austin English wrote: diff --git a/dlls/api-ms-win-core-localregistry-l1-1-0/api-ms-win-core-localregistry-l1-1-0.spec b/dlls/api-ms-win-core-localregistry-l1-1-0/api-ms-win-core-localregistry-l1-1-0.spec new file mode 100644 index 000..cc15d4e --- /dev/null +++ b/dlls/api-ms-win-core-localregistry-l1-1-0/api-ms-win-core-localregistry-l1-1-0.spec @@ -0,0 +1,40 @@ +@ stub RegCloseKey Why don't you just forward them to their implementations in advapi32? Is there something oddly different about these functions that I don't know about? Chip Michael pointed that out as well, fixed in try 2 sent earlier today. -- -Austin
GSoC 2013 has begun!
Howdy, Wine has accepted 4 student proposals for Google Summer of Code 2013: George Stephanos, Registry - implement merging between HKCR and HKCU\Software\Classes mentored by Detlef Riekenberg Jactry Zeng, Implement ITextDocument in Richedit mentored by Huw Davies John Chadwick, MSXML - Implement XPATH without libxml2 mentored by Nikolay Sivov Zhan Jianyu, Improve and add missing feature of vbscript component mentored by Jacek Caban Welcome to Wine and good luck on your projects! As a reminder, here are the next few big dates: May 27th - June 17: community bonding period. Students/mentors should use this time to iron out details of the project, learn the code base and get to know others on the project. June 17: coding officially begins July 29th - Aug 2nd: mid-term reviews are submitted. Mentors/students, please feel free to contact me or André Hentschel if you have any GSoC administrative/procedural questions. Otherwise use wine-devel or ask your mentor for help with learning the Wine development process/codebase/etc. -- -Austin
Re: dinput: Update existing joystick values after setting the range property
On Sun, Apr 14, 2013 at 2:25 PM, Bassi, Gurmail gurmail.ba...@mottmac.com wrote: ePSXe polls the joystick immediately after setting the axis range property, and uses the returned values as its 'centered' calibrated values - therefore the existing joystick state values must be remapped to the new range (or else the joystick may not have the full range of motion) This patch has been tested on Ubuntu 12.04.1 LTS x86-64, and the behaviour confirmed to match Microsoft's DirectInput implementation on Windows XP 32-bit (Microsoft's DirectInput seems to update the existing joystick values to the new range prior to polling even if the joystick hasn't been moved) --- dlls/dinput/joystick.c | 47 +++ 1 file changed, 47 insertions(+) Hi Gurmail, This appears to have caused a regression, see http://bugs.winehq.org/show_bug.cgi?id=33496 (normally I'd cc you on the bug, but you don't seem to have a bugzilla account). -- -Austin
Re: GSoC 2013 has begun!
On Tue, May 28, 2013 at 2:50 PM, Austin English austinengl...@gmail.com wrote: Howdy, Wine has accepted 4 student proposals for Google Summer of Code 2013: George Stephanos, Registry - implement merging between HKCR and HKCU\Software\Classes mentored by Detlef Riekenberg Jactry Zeng, Implement ITextDocument in Richedit mentored by Huw Davies John Chadwick, MSXML - Implement XPATH without libxml2 mentored by Nikolay Sivov Zhan Jianyu, Improve and add missing feature of vbscript component mentored by Jacek Caban Welcome to Wine and good luck on your projects! As a reminder, here are the next few big dates: May 27th - June 17: community bonding period. Students/mentors should use this time to iron out details of the project, learn the code base and get to know others on the project. June 17: coding officially begins July 29th - Aug 2nd: mid-term reviews are submitted. Mentors/students, please feel free to contact me or André Hentschel if you have any GSoC administrative/procedural questions. Otherwise use wine-devel or ask your mentor for help with learning the Wine development process/codebase/etc. -- -Austin A quick follow up. If anyone would like to assist mentoring any of the accepted projects, please let me know and I'll add you as an additional mentor. -- -Austin
Re: Regression for bash.exe redirection of ctest.exe for wine-1.5.30 compared to wine-1.5.19
On Wed, May 22, 2013 at 2:03 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Generally I have found in still fairly limited testing that MSYS bash.exe redirection is fine on wine-1.5.30 (which I have now been able to build in 32-bit mode on Debian wheezy x86_64 thanks to the 32-bit library symlink trick discussed in my previous recent thread). However, I have just discovered a puzzling case where MSYS bash.exe redirection now fails for ctest.exe compared to wine-1.5.19. To reproduce this regression download the Windows binary version of cmake-1.8.10.2 (which includes cmake.exe and ctest.exe) and install it. Also download and install MinGW/MSYS. In the past, I have found results depend very much on how you get into the MSYS bash.exe environment. In my case I execute wineconsole --backend=curses MinGW_4.7.0/msys/1.0/bin/bash.exe to do that, and then from that interactive environment execute the commands below. Here is how I try the --version option for cmake and ctest with redirection under bash.exe. bash.exe-3.1$ cmake --version cmake_version.out bash.exe-3.1$ ctest --version ctest_version.out For Wine-1.5.19 bash.exe-3.1$ head *.out == cmake_version.out == cmake version 2.8.10.2 == ctest_version.out == ctest version 2.8.10.2 For Wine-1.5.30 bash.exe-3.1$ head *.out == cmake_version.out == cmake version 2.8.10.2 == ctest_version.out == N.B. note the incorrect empty ctest_version.out file for Wine-1.5.30. For both Wine-1.5.19 and Wine-1.5.30 if I don't redirect the output I simply get the following results bash.exe-3.1$ cmake --version cmake version 2.8.10.2 bash.exe-3.1$ ctest --version ctest version 2.8.10.2 So somehow bash.exe redirection for ctest (but not cmake and a small number of other commands I have tried) generates an incorrect empty file for Wine-1.5.30. I never have had trouble with bash.exe redirection for any command (including ctest) on either Linux bash or MSYS bash.exe on Wine-1.5.19. So it is likely there is some minor (but probably standard) variation in how ctest handles its stdout that is triggering this Wine-1.5.30 regression compared to Wine-1.5.19. So there might be other commands as well where bash.exe redirection doesn't work for Wine-1.5.30. If it is already known that MSYS bash.exe redirection is sometimes problematic with Wine-1.5.30 compared to earlier versions, is there some patch I could try to see if it fixes this specific issue? My primary motivation is developing my own free software. Therefore, I only have limited time to help figure out wine bugs although I am willing to report the ones I discover here (and on the bug tracker once discussed here to reduce bug tracker noise). That said, it does appear that git-bisect would be an ideal way to find which commit between Wine-1.5.19 and Wine-1.5.30 caused the bash.exe redirection issue with ctest.exe. Unfortunately, I have zero experience with git-bisect. However, if somebody could give me some step-by-step instructions I could follow by rote that would be great. Ideally, those instructions would be a simple template bash script I could run unattended overnight from Linux that used git-bisect to detect the first commit between Wine-1.5.19 and Wine-1.5.30 where ctest --version ctest_version.out produces an empty file under MSYS bash.exe. I can fill in the parts of that template script concerning the wine build for each git commit that is being tested since I have such builds (including necessary *.so links for later wine versions) largely automated now. But I am not sure about how you get into MSYS bash.exe directly (my normal method using wineconsole as above appears to be interactive rather than something you could run unattended) from a Linux bash script so I would need advice about that. Alan This is better suited for the forum, but: http://wiki.winehq.org/RegressionTesting#head-a7150fa43baeaab304403f27a930647ea13648b7 -- -Austin
Re: Regression for bash.exe redirection of ctest.exe for wine-1.5.30 compared to wine-1.5.19
On Wed, May 22, 2013 at 4:19 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-05-22 14:31-0700 Austin English wrote: This is better suited for the forum, but: http://wiki.winehq.org/RegressionTesting#head-a7150fa43baeaab304403f27a930647ea13648b7 Hi Austin: Thanks for that reference which is helpful for a git newbie like myself. I had some additional questions, but I think I have worked those out. In particular, I have finally figured out how to run ctest.exe --version with redirection under bash.exe under wine from a Linux shell script. I will try to put this all together for an automated overnight run, and hopefully I will be able to report the offending commit to the list tomorrow if git-bisect works as advertised. Please file a bug at http://bugs.winehq.org instead of reporting them to wine-devel. -- -Austin
Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy
On Tue, May 21, 2013 at 6:17 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2013-05-21 21:22+0200 André Hentschel wrote: To finally answer this: pure wine64 can't run 32-bit applications, you need wine32 or a wow64 setup for this. Thanks for that important clarification. That means I always need 32-bit as standalone or as part of wow64. So regardless of that choice I have to figure out the 32-bit library configuration issues that have been introduced since wine-1.5.19. To answer another responder (Ričardas Barkauskas), my system is almost entirely 64-bit with many 64-bit development packages installed so I can build lots of different 64-bit packages on Linux. But wine is the exception since from the above answer to my question, 32-bit wine is always going to be needed, and that requires installation of 32-bit libraries (which I only do because of my 32-bit wine needs). Before, I straightforwardly built wine32 (e.g., for wine-1.5.19) with minimal issues with linking to a relatively small number of 32-bit libraries that were required at that time. However, somewhere between wine-1.5.19 and wine-1.5.30 (which I have patched as instructed for the libwine creation issue that came up early in this thread for 1.5.30) much more stringent requirements for 32-bit libraries were introduced for the 32-bit build, and this is a problem for Debian wheezy because many Debian wheezy library -dev packages (which create *.so symlinks to the shared libraries and which typically also provide static libraries) are not multiarch aware. The only way to beat this that I am aware of is convert to a 32-bit system (which I definitely don't want to do) or create the *.so symlinks to the 32-bit libraries myself. I have created a script to do that (in the user's standalone build tree to avoid contaminating system areas). After running that script (attached if anybody else reading this thread in the future finds it to be useful) I also execute export LDFLAGS=-L$(pwd) so those symlinks in the build tree are accessible to the linker. The 32-bit wine-1.5.30 configure script results are now much better; I have reduced the number of missing 32-bit libraries from ~30 to 5. The associated configure messages are configure: OpenCL 32-bit development files not found, OpenCL won't be supported. configure: libdbus 32-bit development files not found, no dynamic device support. configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled configure: WARNING: libjpeg 32-bit development files not found, JPEG won't be supported. configure: WARNING: libpng 32-bit development files not found, PNG won't be supported. At least I now have access to the 32-bit version of libfreetype which allows fonts to be generated. I did the normal 32-bit build after that configure step, and it looks like the result passes some minimal tests such as being able to run winecfg. However, when I tried running the Cygwin setup.exe from wineconsole, there were lots of warning messages about no png. As a result, I plan to work some more to get access to the 32-bit version of the png library before configuring and building the 32-bit version of wine-1.5.30 again. If that search for a way to get access to the 32-bit png library is a success, the missing libraries will be reduced to 4. In the past for 32-bit builds I have gotten by without opencl and jpeg (according to my dated notes) so I am not going to worry about them (unless someone here advises me they have some importance I am unaware of). Can somebody advise me about the importance (or not) of the remaining two missing 32-bit libraries (libdbus and gstreamer)? For example, are they worth some extraordinary measures such as downloading the binary i386 -dev package and extracting the static 32-bit versions separately from that package? For your purposes, libdbus/gstreamer probably aren't important. You should be aware that cygwin doesn't work terribly well under Wine, however. There are several open bugs: http://bugs.winehq.org/show_bug.cgi?id=12104 http://bugs.winehq.org/show_bug.cgi?id=19800 http://bugs.winehq.org/show_bug.cgi?id=19801 http://bugs.winehq.org/show_bug.cgi?id=19858 http://bugs.winehq.org/show_bug.cgi?id=19859 http://bugs.winehq.org/show_bug.cgi?id=21424 http://bugs.winehq.org/show_bug.cgi?id=24018 -- -Austin
Re: [PATCH 6/6] d3d9/tests: d3d9ex video memory accounting tests
On Wed, May 15, 2013 at 3:32 AM, Henri Verbeet hverb...@gmail.com wrote: On 14 May 2013 23:46, Stefan Dösinger ste...@codeweavers.com wrote: These tests have the potential to break on Windows when other applications create or release a large number of video memory resources while the test is running. Yeah, maybe we don't really need this to be in the tree, although it's good to see for reference. It seems like a good candidate for if(winetest_interactive) -- -Austin
Re: Participate in GSoC
On May 15, 2013 10:32 PM, Adam Chyła a...@chyla.org wrote: Hi all, I'm a student who would like to participate in GSoC with task Tools - Winetest Graphical User Interface. What should I do? Adam Ch. It is too late to apply for this year, you'll have to wait until next year. That gives you plenty of time to get up to speed with Wine though :)
Re: [PATCH] wined3d: Only display a fixme when software processing is requested in wined3d_device_set_software_vertex_processing.
On Thu, May 16, 2013 at 2:26 PM, Christian Costa titan.co...@gmail.com wrote:
Also remove fixme in wined3d_device_get_software_vertex_processing since it
does what it is supposed to do.
---
dlls/wined3d/device.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 47da78b..89fc525 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -4281,9 +4281,9 @@ void CDECL
wined3d_device_set_software_vertex_processing(struct wined3d_device *
TRACE(device %p, software %#x.\n, device, software);
-if (!warned)
+if (software !warned)
{
-FIXME(device %p, software %#x stub!\n, device, software);
+FIXME(Software vertex processing not supported. Fake it and use
harware one.);
warned = TRUE;
Typo, should be hardware.
--
-Austin
Re: Clang static analyzer results / wine-1.5.28-66-g6899279
On Wed, Apr 24, 2013 at 10:39 AM, Austin English austinengl...@gmail.com wrote: On Wed, Apr 24, 2013 at 3:28 AM, Ken Thomases k...@codeweavers.com wrote: On Apr 24, 2013, at 5:10 AM, Jacek Caban wrote: On 04/24/13 11:35, Frédéric Delanoy wrote: Although, one can sort/filter by file, or if it's really that annoying, a quick script removing tr elements containing /tests should be easy enough. Well... that's far from perfect, but could work. Would it work to do two runs and have two different result sets? I think that make install rather than make avoids building the tests without requiring --disable-tests. (You can set DESTDIR to some temp directory in your home or /tmp.) After that, a plain make will make just the tests. -Ken If people find results with the tests enabled useful, I can certainly run it twice, yes. -- -Austin [austin@localhost ~]$ sha1sum scan-build-2013-04-24-with-tests.tar.bz2 9dfd540f2ac2bd656ab326bc9c5fff7240f966b6 scan-build-2013-04-24-with-tests.tar.bz2 [austin@localhost ~]$ du -h scan-build-2013-04-24-with-tests.tar.bz2 54Mscan-build-2013-04-24-with-tests.tar.bz2 http://www.mediafire.com/?jtiqxdq8fql2b9l These results are also against wine-1.5.28-66-g6899279. -- -Austin
Re: Clang static analyzer results / wine-1.5.28-66-g6899279
On Wed, Apr 24, 2013 at 3:28 AM, Ken Thomases k...@codeweavers.com wrote: On Apr 24, 2013, at 5:10 AM, Jacek Caban wrote: On 04/24/13 11:35, Frédéric Delanoy wrote: Although, one can sort/filter by file, or if it's really that annoying, a quick script removing tr elements containing /tests should be easy enough. Well... that's far from perfect, but could work. Would it work to do two runs and have two different result sets? I think that make install rather than make avoids building the tests without requiring --disable-tests. (You can set DESTDIR to some temp directory in your home or /tmp.) After that, a plain make will make just the tests. -Ken If people find results with the tests enabled useful, I can certainly run it twice, yes. -- -Austin
Re: Clang static analyzer results / wine-1.5.28-66-g6899279
On Fri, Apr 19, 2013 at 1:52 AM, Michael Stefaniuc mstef...@redhat.com wrote: On 04/19/2013 12:43 AM, Austin English wrote: With wine-1.5.20 and clang 3.2, the test suite is in the same state on my Fedora 18 machine as gcc-4.7.2 llvm version: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179768 91177308-0d34-0410-b5e6-96231b3b80d8 clang version: git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179771 91177308-0d34-0410-b5e6-96231b3b80d8 ./configure --disable-tests was used to reduce noise Static analyse of the tests is important as well. Over the years I found bad tests that didn't test what they were supposed to test. And even cases where the Wine code was bad due to that as it passed the tests. bye michael That was suggested by Jacek, see http://www.winehq.org/pipermail/wine-devel/2012-January/094059.html -- -Austin
Re: msvcr110: forward __crtSetUnhandledExceptionFilter to kernel32.SetUnhandledExceptionFilter (try 3)
On Wed, Apr 17, 2013 at 6:06 PM, Dmitry Timoshkov dmi...@baikal.ru wrote:
Austin English austinengl...@gmail.com wrote:
+LPTOP_LEVEL_EXCEPTION_FILTER
MSVCR110__crtSetUnhandledExceptionFilter(LPTOP_LEVEL_EXCEPTION_FILTER
filter)
+{
+return SetUnhandledExceptionFilter(filter);
+}
msvcrt APIs need an explicit calling convention specifier.
--
Dmitry.
Thanks, not sure how I missed that. Resent.
--
-Austin
Re: Fun with GCC 4.8
On Thu, Apr 18, 2013 at 1:32 AM, James Eder jimpor...@gmail.com wrote: On Mon, Apr 15, 2013 at 3:58 PM, Marcus Meissner mar...@jet.franken.dewrote: On Mon, Apr 15, 2013 at 02:37:27PM -0600, James Eder wrote: As many of you no doubt know, GCC recently released 4.8.0. This new version introduces a new optimization level enabled by -Og with the following description (from the man page): Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. Of course I had to try it out. I found that building Wine lead to GCC dieing with ... dlls/kernel32/console.c:1691:1: internal compiler error: Segmentation fault I also found ... dlls/kernel32/computername.c:701:1: internal compiler error: Segmentation fault I eventually stumbled my way into the enclosed patch which lets GCC build Wine with -Og. I'm not sure if this change (or something similar) makes sense for Wine. I'm fairly certain some changes make sense for GCC (I suspect that GCC should not segfault). I haven't submitted a bug for GCC because I suspect they'll want me to provide something simpler to compile than the Wine source tree. I certainly won't be upset if someone beats me too it. I'm not sure how much time in the near future I'll spend on it. Eventually is probably the word that fits. At any rate, I wanted to at least share my experiences in case anyone is interested in heading down the same path. You copy and paste the failing commandline and add --save-temps, like e.g.: gcc -c -I/home/marcus/projects/wine/dlls/kernel32 -I. -I/home/marcus/projects/wine/include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_NORMALIZE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -gdwarf-2 -gstrict-dwarf -Wpointer-arith -Wlogical-op -I/usr/include/freetype2-Wall -g -fstack-protector -o console.o /home/marcus/projects/wine/dlls/kernel32/console.c -Og --save-temps it will generate a console.i file in the currenct directory. The console.i file and above commandline are a start for the gcc bug. Ciao, Marcus Looks like the bug is fixed and should be in for GCC 4.8.1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56992 -- Jim FWIW, this is separate from http://bugs.winehq.org/show_bug.cgi?id=33307, which is still present in gcc trunk (both master and the gcc_48 branch. -- -Austin
Clang static analyzer results / wine-1.5.28-66-g6899279
With wine-1.5.20 and clang 3.2, the test suite is in the same state on my Fedora 18 machine as gcc-4.7.2 llvm version: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17976891177308-0d34-0410-b5e6-96231b3b80d8 clang version: git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@17977191177308-0d34-0410-b5e6-96231b3b80d8 ./configure --disable-tests was used to reduce noise [austin@localhost ~]$ sha1sum scan-build-2013-04-18-2.tar.bz2 51e28c96a04ebe9ef937678149f9e7e3ed4cb20f scan-build-2013-04-18-2.tar.bz2 [austin@localhost ~]$ du -h scan-build-2013-04-18-2.tar.bz2 35Mscan-build-2013-04-18-2.tar.bz2 http://www.mediafire.com/?xwb05d6er0aclfe -- -Austin
Re: Application for GSoC 2013
On Wed, Apr 17, 2013 at 9:38 AM, larmbr zhan nasa4...@gmail.com wrote: Hi all, I'm a junior student from a non-famous college, I apply to parcitipate in GSoC , to help do some vbscript module implementation. I've just submitted a patchset on this. Howdy Zhan, While your college may not be famous, it's still nice information to have (and let's us get to know you better). You're going to have to be (much) more specific with your application, what modules do you plan to implement, what applications does this help (if you know of any), etc. Sending a patchset to start is definitely a plus though :) -- -Austin
Re: We're in GSoC 2013
On Tue, Apr 9, 2013 at 1:21 PM, paulo lesgaz jeremielapu...@yahoo.frwrote: Hello, can the project Implementing a vertex pipeline be added for the possible GSOC projects? It would fix plenty of broken games (see bug 6955). Henri Verbeet said it could be a project, depending of skills of the student. David -- *De :* Austin English austinengl...@gmail.com *À :* Wine Devel wine-devel@winehq.org *Envoyé le :* Mardi 9 avril 2013 7h30 *Objet :* We're in GSoC 2013 If you're interested in mentoring, please apply at: https://www.google-melange.com/gsoc/org/google/gsoc2013/wine In either case, please take a look at http://wiki.winehq.org/SummerOfCodeand update/remove/any projects you're familiar with. If you have any questions, feel free to contact me. Thanks for your help everyone! -- -Austin I spoke to Henri about the project on IRC. It is probably out of scope for GSoC for someone unfamiliar with wined3d, so I don't think it's appropriate to list on the wiki page. If a student familiar with wined3d wants to apply for it, however, they're free to do so. -- -Austin
We're in GSoC 2013
If you're interested in mentoring, please apply at: https://www.google-melange.com/gsoc/org/google/gsoc2013/wine In either case, please take a look at http://wiki.winehq.org/SummerOfCodeand update/remove/any projects you're familiar with. If you have any questions, feel free to contact me. Thanks for your help everyone! -- -Austin
Re: [AppDB] -more spam-
On Tue, Apr 9, 2013 at 3:20 PM, Joerg Schiermeier n...@schiermeier-it.de wrote: Hi list, again a spammer used the AppDB for his nasty activities: 1.) Comment for 'Adobe Photoshop CS3 (10.0)' added by tokoku12345 --- To reply to this email please use the link provided below. DO NOT reply via your email client as it will not reach the person who wrote the comment http://appdb.winehq.org/objectManager.php?sClass=versioniId=6584#Comment-84693 2.) Comment for 'ElsterFormular 12.0 (2010 + 2011)' added by tokoku12345 --- To reply to this email please use the link provided below. DO NOT reply via your email client as it will not reach the person who wrote the comment http://appdb.winehq.org/objectManager.php?sClass=versioniId=22570#Comment-84724 No. #2 is maintained by me, so I deleted the comment just some minutes ago. Is it possible, to mail to all maintainers to inform them about the actual mail food and to have an eye on their applications? If so please do it. -- Kindly regards Joerg Schiermeier Bielefeld/Germany I'm not aware of such a mechanism, but regarding spam, I'm usually on IRC (austin987) and you can ping me there to delete spam, if needed. -- -Austin
Re: [AppDB] Comment for 'Microsoft Outlook 2007' added by bayu
On Mon, Apr 8, 2013 at 9:41 AM, Joerg Schiermeier n...@schiermeier-software.de wrote: On Monday, April 8, 2013 at 07:49:47 an anonymous spammer wrote into the AppDB: Comment for 'Microsoft Outlook 2007' added by bayu http://appdb.winehq.org/objectManager.php?sClass=versioniId=7533#Comment-84637 (...garbage killed...) Could someone of AppDBs admin please kill this comment and the user 'bayu'. Thanks lot! -- Kindly regards Joerg Schiermeier Bielefeld/Germany I've deleted the comment, but trying to delete the user from the admin page just refreshes the page.. -- -Austin
Re: 64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
On Thu, Apr 4, 2013 at 6:39 PM, jordan triplesquaredn...@gmail.com wrote: Hey List, A few days ago, i posted to the list about possibly porting a winelib app to support x86_64. (currently supports x86). the original post is here (for those interested, but not entirely relevant to this post): http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to-support-64bit-td5750102.html moving on. So we have a simple test app, that successfully loads 64bit DLLs on my friend's Intel based machines, while on my AMD Phenom II 965 X4 - the code fails. - Successful on Intel: xj@xj:~/Muzyka/fsthost/trunk$ ./test64.exe ../../VST/ColourEQ_64.dll Load plugin ../../VST/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close So intel computers tested (2 that i know of) work just fine. - Failure on AMD: http://pastebin.com/x64pig3s and a little snippet: ./test64.exe '/home/ninez/Desktop/ColourEQ_64.dll' fixme:heap:HeapSetInformation 0x2c4000 0 0x23fce0 4 Load plugin /home/ninez/Desktop/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3d4000 0 0x23f5f0 4 Main entry: 0x1800077d0 Revive plugin wine: Unhandled page fault on read access to 0x at address 0x (thread 002a), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module snip fixme:dbghelp:elf_search_auxv can't find symbol in module Unhandled exception: page fault on read access to 0x in 64-bit code (0x). fixme:dbghelp:elf_search_auxv can't find symbol in module Register dump: rip: rsp:0023fa78 rbp:0023fbd0 eflags:00010246 ( R- -- I Z- -P- ) rax:003d8de0 rbx: rcx: rdx:0001 rsi: rdi:7f1205f559d0 r8: r9: r10:0001 r11: r12: r13:7f1205f50040 r14:7b86f920 r15:7fbe8000 Stack dump: 0x0023fa78: 000180007756 003d8de0 0x0023fa88: 7f1206ff14d3 00010ac1 0x0023fa98: 000d 0x0023faa8: 7f12 fffe 0x0023fab8: 0023fbd0 7f1205f559d0 0x0023fac8: 7f1205f55b09 2020202020202020 0x0023fad8: 00010ac1 7f1207324323 0x0023fae8: 2000 00ff 0x0023faf8: 00ff 00202020 0x0023fb08: 0001800077d0 00018000 0x0023fb18: 00010ac1 5b5b5b5b5b5b5b5b 0x0023fb28: 5b5b5b5b5b5b5b5b 2020202020202020 It's odd that it is working on Intel H/W, but not my AMD system. ~ what could be a possible reason for this? We've made s simple test app that doesn't require jackd, or FSThost functions, to simplify things. The source code can be found here: https://sourceforge.net/p/fsthost/code/171/tree/ SVN code required: svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code the test app source code is called 'test64-most-simple.c' The test app can be compiled with; $ make -f Makefile64-most-simple then $ ./test64.exe /path/to/64bitVST a tester can be found here: http://www.ddmf.eu/freeware.php grab 'ColourEQ' (contains both 32bit and 64bit versions... and obviously use the 64bit version to try/test.) anyway, i am not sure what the problem is, maybe someone here has an idea or two? ... i've been wondering if there is some sort of misalignment/compiler issue, that is causing the problem...but i want to rule out Wine64 being an issue, first - if possible. any help is appreciated. Thanks Jordan Are y'all using the same OS/distro/kernel/gcc/libc versions? -- -Austin
Fwd: GSoC 2013 Ideas Page
I cleaned this up a couple months ago and removed completed/obsolete projects, but it needs further improvements (mostly new ideas). Please contribute any ideas that you have. Thanks! -Austin -- Forwarded message -- From: Carol Smith car...@google.com Date: Tue, Apr 2, 2013 at 1:41 PM Subject: GSoC 2013 Ideas Page To: Carol Smith car...@google.com Hi there, You're receiving this email because we've reviewed your application for GSoC 2013. We're currently disappointed with the quality of your Ideas Page and would like to give you an opportunity to improve it and your chances of getting into GSoC this year. Please review the FAQs on Ideas Pageshttp://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#3._What_is_an_Ideas_list as well as the Mentor Manual section about creating an ideaspagehttp://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/ . You have 24 hours from now to improve your ideas page.We will review it again tomorrow. Please let me know if you have any questions. Cheers, Carol -- -Austin
Re: GSoC 2013 Ideas Page
On Tue, Apr 2, 2013 at 2:31 PM, Austin English austinengl...@gmail.comwrote: I cleaned this up a couple months ago and removed completed/obsolete projects, but it needs further improvements (mostly new ideas). Please contribute any ideas that you have. Thanks! -Austin -- Forwarded message -- From: Carol Smith car...@google.com Date: Tue, Apr 2, 2013 at 1:41 PM Subject: GSoC 2013 Ideas Page To: Carol Smith car...@google.com Hi there, You're receiving this email because we've reviewed your application for GSoC 2013. We're currently disappointed with the quality of your Ideas Page and would like to give you an opportunity to improve it and your chances of getting into GSoC this year. Please review the FAQs on Ideas Pageshttp://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#3._What_is_an_Ideas_list as well as the Mentor Manual section about creating an ideaspagehttp://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/ . You have 24 hours from now to improve your ideas page.We will review it again tomorrow. Please let me know if you have any questions. Cheers, Carol -- -Austin Forgot the wiki url: http://wiki.winehq.org/SummerOfCode -- -Austin
Re: d3dx9 [patch 1/2, try 3]: Implement D3DXSHEvalSphericalLight
On Tue, Mar 26, 2013 at 6:04 PM, Michael Mc Donnell mich...@mcdonnell.dk wrote: On Tue, Mar 26, 2013 at 7:07 PM, Nozomi Kodama nozomi.kod...@yahoo.com wrote: Why are they not committed yet? Alexandre is on vacation so that might explain why :-) Well, he was last week, back now, but there is a backlog of patches to go through.. Patches were committed today/yesterday: http://source.winehq.org/git/wine.git/shortlog -- -Austin
Re: Parameterizing the places Wine suggests people report bugs
On Mon, Mar 18, 2013 at 5:18 PM, Josh DuBois dubo...@codeweavers.com wrote: Hi all, There are a couple of places wine suggests that people report bugs to wine-devel. The crash reporting dialog in winedbg suggests this, and a couple of places in code refer to wine-devel@winehq.org in error messages. I assume you meant http://bugs.winehq.org for the winedbg dialog, since that's what I get/the po files refer to: Report-Msgid-Bugs-To: http://bugs.winehq.org\n; The configure script has a PACKAGE_BUGREPORT macro which could be used to allow someone building wine to redirect those errors somewhere else. At least for wine's crash dialog, an alternate approach for a repackager to redirect bug reports would be to read the url / email address for where to send bugs from the registry. Would Wine accept a patch for making winedbg read the 'destination' for bug reports from the registry or some other runtime variable? Or would the project prefer to have all the bug reports routed directly to winehq, so that a repackager who wants to re-route bugs would have to build that facility on its own? I can't speak for Alexandre, of course, but speaking with my bugzilla hat on, if a packager wants to override that, I don't see the harm. I'd rather see wine bugs reported upstream (i.e., http://bugs.winehq.org), but if the packager wants to override that, I assume they have a good reason (building wine with custom/hacky patches, changing default registry settings, etc.). How many packagers will actually use that feature though, and how many users would notice the difference, is the ultimate question, of course :). -- -Austin
Re: [GSoC] My proposal for GSoC 2013
On Wed, Mar 20, 2013 at 11:35 AM, Gediminas Jakutis gedimi...@varciai.lt wrote: Hello! For GSoC, I am suggesting my own idea. In case this idea is not good, I am open to changing it, thinking of a new one, or adopting one. My idea: I have noticed that Wine's virtual desktop feature is very limited - if the first program on a prefix starts without a virtual desktop, all programs launched during the same session also start without a VD, disregarding any VD settings and/or requests with environment variables. And vice versa - if the first program starts inside a VD, all other programs in that sessions start in the VD. Often, this can be worked around by using separate Wine prefixes. Yet sometimes, this workaround is not possible. A good example: steam and games that only run properly in a VD. This forces the user to start steam in a VD and makes steam itself unusable while a game is running, especially if the game does not support the steam overlay. I would like to fix this limitation and make it possible to properly choose to run different programs on one prefix with or without a VD regardless what was chosen to programs already running in that prefix. I can already see this requiring changes in the winecfg utility, by the way. In addition to Vincent's comments, note that you _can_ set up virtual desktops for certain apps but not others within a single WINEPREFIX (though Steam may not like this, I haven't tried it myself). There's a bit more info at http://wiki.winehq.org/FAQ#head-dba86ae589dca54a116a3fc21f6237af45e8119c. This has been in Wine for quite a while...a significant part of Summer of Code is researching potential ideas before proposing them. Though you did start early, so you have plenty of time to find other ideas :). -- -Austin
Re: iphlpapi: Let C look like C.
On Feb 6, 2013 11:13 PM, Michael Stefaniuc mstef...@redhat.de wrote:
---
dlls/iphlpapi/ipstats.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dlls/iphlpapi/ipstats.c b/dlls/iphlpapi/ipstats.c
index f8191ba..966d24e 100644
--- a/dlls/iphlpapi/ipstats.c
+++ b/dlls/iphlpapi/ipstats.c
@@ -693,7 +693,7 @@ DWORD WINAPI GetIcmpStatisticsEx(PMIB_ICMP_EX stats,
DWORD family)
}
ret = GetIcmpStatistics(ipv4stats);
-if SUCCEEDED(ret)
+if (SUCCEEDED(ret))
{
stats-icmpInStats.dwMsgs = ipv4stats.stats.icmpInStats.dwMsgs;
stats-icmpInStats.dwErrors =
ipv4stats.stats.icmpInStats.dwErrors;
--
1.7.6.5
Minor nitpick, Make C look like C would be a more proper title, imho.
Re: [PATCH] Support for game DRM which overwrite the GS segment selector
On Jan 31, 2013 8:15 AM, Alessandro Pignotti alexpigna@gmail.com
wrote:
Hi again,
I've quickly implemented the aforementioned idea of fixing the segment
in the segfault handler when needed. I'm attaching my proposed patch.
Alessandro
Il giorno mer, 30/01/2013 alle 16.44 +0100, Alessandro Pignotti ha
scritto:
Hi everyone,
I'm trying to get a specific game which employs a seemingly custom
protection scheme to work. The DRM does various bad things as usual, but
a very bad one is manipulating to GS segment selector and setting it to
a NULL segment. The GS segment is used by libc though in various ways
(stack protection and syscall support, and probably others).
I managed to get the activation procedure to go further and further by
enclosing each offending syscall using the following 2 macros.
#define SAFE_GS_START \
do { \
wine_set_gs(ntdll_get_thread_data()-gs); \
do
#define SAFE_GS_END \
while(0); \
} while(0)
Still, this method is very cumbersome since system calls happens in many
places even outside of ntdll. Fixing the GS is also needed to support
sigsetjmp which is used by wine's exception handling.
I'd like to ask for feedback about what would be a sane way of
supporting this application. A possible solution would be to modify
wine's segfault handler to check if the instruction has a GS prefix
(0x65 IIRC) and try to execute the instruction again after fixing the
GS.
Please keep me in CC since I'm not subscribed to the ML.
Regards,
Alessandro Pignotti
Out of curiosity, what game is this? What protection does Protection ID
show it uses?
Re: include: flesh out d3d11.idl (try 2)
On Fri, Jan 11, 2013 at 8:42 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: Austin English austinengl...@gmail.com wrote: +/* Forward declarations */ You've copied too much from the PSDK version, better leave it to someone else, and do it step by step when particular functionality gets implemented. The forward declarations are necessary due to the convoluted nature of the interfaces. My end goal is to add a stub for D3D11CreateDevice, which fixes http://bugs.winehq.org/show_bug.cgi?id=32520 (so users don't have to disable d3d11). However, adding a stub requires ID3D11Device and ID3D11DeviceContext, which are 158 and 413 lines respectively. If I only add what is needed, it saves ~600 lines (1650 vs 2230), so I went ahead and added the rest. I meant that you not only copied structures, declarations and definitions without even slight attempt to make them a bit different from PSDK, but also copied the comments. That approach clearly is not acceptable. Indentation was changed to match other wine headers / make it different from the PSDK. The interface formats were also changed (quite a bit) to match d3d10.idl. There's only so many ways to word 'forward declarations'. -- -Austin
Re: include: flesh out d3d11.idl (try 2)
On Thu, Jan 10, 2013 at 8:18 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: Austin English austinengl...@gmail.com wrote: Try 2: Remove L suffixes, C++ comment. +/* Forward declarations */ You've copied too much from the PSDK version, better leave it to someone else, and do it step by step when particular functionality gets implemented. The forward declarations are necessary due to the convoluted nature of the interfaces. My end goal is to add a stub for D3D11CreateDevice, which fixes http://bugs.winehq.org/show_bug.cgi?id=32520 (so users don't have to disable d3d11). However, adding a stub requires ID3D11Device and ID3D11DeviceContext, which are 158 and 413 lines respectively. If I only add what is needed, it saves ~600 lines (1650 vs 2230), so I went ahead and added the rest. -- -Austin
Re: [PATCH] loader: Build with -fno-builtin.
On Mon, Dec 24, 2012 at 10:38 AM, Charles Davis cdavi...@gmail.com wrote: This prevents Clang from optimizing wld_memset() into a memset(3) call. --- loader/Makefile.in | 1 + 1 file changed, 1 insertion(+) diff --git a/loader/Makefile.in b/loader/Makefile.in index 41d69c7..ece07c3 100644 --- a/loader/Makefile.in +++ b/loader/Makefile.in @@ -1,4 +1,5 @@ DEFS = -D__WINESRC__ $(EXTRADEFS) +MODCFLAGS = -fno-builtin C_SRCS = \ main.c \ -- 1.7.12.4 I can confirm it works. -- -Austin
Re: wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole
On Dec 23, 2012 7:22 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so. I would be happy to supply more details if there is any difficulty replicating this reversion. Alan Please run a regression test and file a bug at http://bugs.winehq.org.
Clang static analyzer results / wine-1.5.19-186-g1cd0c4a
Now that http://source.winehq.org/git/wine.git/commitdiff/4adfb787f4e8c36a37ce1d53a7e6df16d03ecd8a is in (and clang has improved), several wine/clang bugs are fixed. For those curious, there is one remaining test failure on my machine, with clang instead of gcc: http://bugs.winehq.org/show_bug.cgi?id=25828 The static analyzer results were made with: llvm: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170295 91177308-0d34-0410-b5e6-96231b3b80d8 clang: git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170294 91177308-0d34-0410-b5e6-96231b3b80d8 wine: wine-1.5.19-186-g1cd0c4a ./configure --disable-tests was used to reduce noise austin@debian-home:~$ du -h wine-1.5.19-186-g1cd0c4a.tar.bz2 39M wine-1.5.19-186-g1cd0c4a.tar.bz2 austin@debian-home:~$ sha1sum wine-1.5.19-186-g1cd0c4a.tar.bz2 bf86469ab3929faf996b76d4a8e533edcf24fd29 wine-1.5.19-186-g1cd0c4a.tar.bz2 Available at http://www.mediafire.com/?0gioifbgw363az3 -- -Austin
Re: winex11.drv: give a better warning for broken drivers on 64-bit OS's
On Sun, Dec 16, 2012 at 2:31 PM, Austin English austinengl...@gmail.com wrote: -- -Austin Wrong macro, please ignore. -- -Austin
Re: msvcrt: implement _ftol in msvcrt instead of forwarding to ntdll (1/2)
On Thu, Dec 13, 2012 at 2:04 AM, Piotr Caban piotr.ca...@gmail.com wrote:
On 12/13/12 02:57, Austin English wrote:
+ * Based on MSVCRT__ftol in dlls/ntdll/misc.c
+ */
+#if defined(__GNUC__) defined(__i386__)
+LONGLONG CDECL MSVCRT__ftol(void)
+{
+@ cdecl -ret64 _ftol() MSVCRT__ftol
+@ cdecl -ret64 _ftol2() MSVCRT__ftol
This will not work on 64-bit build or when __GNUC__ is not defined. I don't
see _ftol function in native 64-bit msvcrt, maybe it should not be exported
there.
Yeah, that's what ntdll was doing, I've sent an updated patch.
--
-Austin
Re: d3d11: add a stub dll
On Tue, Dec 11, 2012 at 5:15 AM, Henri Verbeet hverb...@gmail.com wrote: On 11 December 2012 04:16, Austin English austinengl...@gmail.com wrote: + * Copyright 2012 The Wine Project I don't think that kind of thing really makes sense unless you also define The Wine Project as some kind of legal entity somewhere. It's also done in some headers/other files. I didn't want to put my name on it for so little code, but that's a trivial thing to change. +TRACE((0x%p, %d, %p)\n, hinstDLL, fdwReason, lpvReserved); 0x%p is just wrong, and %d is at least questionable for a DWORD. I suspect this was just copied from somewhere else though. The stub was created using winedump. -- -Austin
Re: RFC: Remove auto-scan of ALSA devices from winealsa.drv
On Tue, Dec 11, 2012 at 9:39 AM, Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: On 12/11/2012 10:46 AM, Henri Verbeet wrote: On 11 December 2012 16:05, joerg-cyril.hoe...@t-systems.com wrote: Cost to users: Users with a working ALSA device default should experience no drawback, only benefits. I believe this is the vast majority of users. Users that edit their ~/.asoundrc to define other devices without simultaneously overriding !default will have to additionally edit the Wine registry to name their working ALSA capture and render devices, e.g. asnoop and amix. It will also pretty much just remove device selection on setup with multiple audio devices, which is actually fairly common these days with USB audio devices and HDMI outputs on graphics cards. I think the correct approach would to work with upstream ALSA to fix things, instead of just removing device enumeration. I do not think this is a particularly good idea. I do have two sound systems on my machine and I have assigned each to different roles. That seems to work quite well. What does not work well is leaving the role set to 'default'. That results in the selection of the highest latency device with corresponding stutters and over-runs. The current requirement for selecting an output device is mildly annoying, but no where near as annoying as being forced to use a faulty device. You'd still be able to select a different device in the registry. -- -Austin
Re: xapofx1_3.dll?
On Tue, Oct 30, 2012 at 6:11 AM, joerg-cyril.hoe...@t-systems.com wrote: Hi, why does Wine include a stub xapofx1_1.dll but no xapofx1_3.dll? Installing Wallace Gromit 102 The Last Resort / Urlaub unter Tage adds xapofx1_3.dll XAudio2_4.dll and X3DAudio1_6.dll to system32 (though IIRC I asked the installer not to care about DirectX). This app loads none of these libraries (well, I solely tested winecfg's default xp mode, not w7. Presumably those dlls are only relevant since Vista with mmdevapi and the app uses DSound on older systems). http://bugs.winehq.org/show_bug.cgi?id=27279 is about apps linked against this dll such that they won't even start. Regards, Jörg Höhle It looks like no one ever sent a patch for it, at least according to my email archives and a quick google search. -- -Austin
Re: [PATCH] winmm: Load winealsa if winepulse is found
On Tue, Oct 16, 2012 at 5:10 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: From: Maarten Lankhorst maarten.lankho...@canonical.com Fixes midi on winepulse --- dlls/winmm/lolvldrv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/dlls/winmm/lolvldrv.c b/dlls/winmm/lolvldrv.c index f387323..3b1be27 100644 --- a/dlls/winmm/lolvldrv.c +++ b/dlls/winmm/lolvldrv.c @@ -543,7 +543,10 @@ static void MMDRV_Init(void) drvA = HeapAlloc(GetProcessHeap(), 0, size); WideCharToMultiByte(CP_ACP, 0, pv.u.pwszVal, -1, drvA, size, NULL, NULL); -MMDRV_Install(drvA, drvA, FALSE); +if (!strcasecmp(drvA, winepulse.drv)) +MMDRV_Install(winealsa.drv, winealsa.drv, 0); +else +MMDRV_Install(drvA, drvA, FALSE); HeapFree(GetProcessHeap(), 0, drvA); PropVariantClear(pv); -- 1.7.11.3 Shouldn't this be part of the winepulse patch itself? It will never get used in Wine, as is... -- -Austin
Re: gdiplus: fix font test when liberation fonts are installed
On Wed, Oct 17, 2012 at 7:54 PM, Dmitry Timoshkov dmi...@baikal.ru wrote: Austin English austinengl...@gmail.com wrote: +ok(!lstrcmp(lf.lfFaceName, Arial) || + !lstrcmp(lf.lfFaceName, Liberation Sans), wrong face name %s\n, lf.lfFaceName); The tests are supposed to reflect Windows behaviour, what Windows version does return Liberation Sans in this test? Obviously none, though it seems to a reasonable adjustment, since the Liberation team can't use the Arial name. We already do something similar in dlls/gdi32/freetype.c for liberation mono/sans/serif fonts. -- -Austin
Re: [PATCH] user32: Add tests showing that MapWindowPoints, ClientToScreen and ScreenToClient never fail.
On Tue, Oct 16, 2012 at 11:12 AM, Christian Costa titan.co...@gmail.com wrote: ... +wnd = CreateWindowA(static, NULL, 0, 0, 0, rect.right / 2, rect.bottom / 2, 0, 0, 0, 0); +//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom / 2, 0); Leftover debug code. Cheers, Austin
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa titan.co...@gmail.com wrote: Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : Christian Costa titan.co...@gmail.com wrote: Indeed that would be great to be able to download some files along with the test. Typically for me avi files and dlls (or .drv) would be great ! :D Just do what other tests do: embed all the required data into the test: be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. That way the tests don't depend on any external files, or abilities in the tested environment to download them. It seems a bit complicated for a test I will run only once and not intended to be part of the test suite. You could use a self extracting exe. -- -Austin
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, Oct 15, 2012 at 12:28 PM, Christian Costa titan.co...@gmail.com wrote: Le 15/10/2012 21:16, Austin English a écrit : On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa titan.co...@gmail.com wrote: Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : Christian Costa titan.co...@gmail.com wrote: Indeed that would be great to be able to download some files along with the test. Typically for me avi files and dlls (or .drv) would be great ! :D Just do what other tests do: embed all the required data into the test: be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. That way the tests don't depend on any external files, or abilities in the tested environment to download them. It seems a bit complicated for a test I will run only once and not intended to be part of the test suite. You could use a self extracting exe. Why not if I can make it run the test after the extraction. That said why not improving test bot download extra files? Is there a specific reason for that? I'm not against improving the testbot, it was just a suggestion. -- -Austin
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, Oct 15, 2012 at 12:45 PM, Christian Costa titan.co...@gmail.com wrote: Le 15/10/2012 21:29, Austin English a écrit : On Mon, Oct 15, 2012 at 12:28 PM, Christian Costa titan.co...@gmail.com wrote: Le 15/10/2012 21:16, Austin English a écrit : On Mon, Oct 15, 2012 at 12:14 PM, Christian Costa titan.co...@gmail.com wrote: Le 15/10/2012 18:07, Dmitry Timoshkov a écrit : Christian Costa titan.co...@gmail.com wrote: Indeed that would be great to be able to download some files along with the test. Typically for me avi files and dlls (or .drv) would be great ! :D Just do what other tests do: embed all the required data into the test: be it a PE executable, TIFF/GIF/PNG/etc image, or even a RIFF/AVI file. That way the tests don't depend on any external files, or abilities in the tested environment to download them. It seems a bit complicated for a test I will run only once and not intended to be part of the test suite. You could use a self extracting exe. Why not if I can make it run the test after the extraction. That said why not improving test bot download extra files? Is there a specific reason for that? I'm not against improving the testbot, it was just a suggestion. It's a good one.I will file a bug in bugzilla for the test bot and try your suggestion. Do you know any simple tool that enables to do that? 7-zip, look into its -sfx option. -- -Austin
Re: wined3d: recognize Radeon HD 6670
On Fri, Oct 5, 2012 at 6:54 PM, Henri Verbeet hverb...@gmail.com wrote: On 5 October 2012 22:12, Austin English austinengl...@gmail.com wrote: Fixes http://bugs.winehq.org/show_bug.cgi?id=31891 That doesn't look right (and doesn't do what you think it does anyway), did you verify this against the Windows driver? It probably just needs an entry to map HD 6670 to CARD_AMD_RADEON_HD6600, although it's a bit curious that most of the existing entries for NI have generic strings like HD 6600. No, as I don't have the card to test against on windows. I'll drop the patch then, feel free to fix it however you feel is appropriate. Cheers, Austin
Re: ole32: Fix dwClsContext parameter of a CoCreateInstance call in DefaultHandler_Run. (try 2)
On Tue, Oct 9, 2012 at 4:27 AM, Roman Dadkov rom...@etersoft.ru wrote: This patch change dwClsContext parameter of a CoCreateInstance call in function DefaultHandler_Run. Because even if there is some clsid in the registry, the function will not be able to run the newly created object. Unfortunately, the test for this case can't be added to Wine, because it leads a crash. You could put the test inside if(0), so that it's still documented, see, for example, dlls/ole32/tests/stg_prop.c or dlls/user32/tests/input.c. Cheers, Austin
Re: msls31: Add stub dll.
On Tue, Sep 11, 2012 at 9:32 AM, Josh DuBois dubo...@codeweavers.com wrote: Presence of a stub of msls31.dll allows Visio 2003 to open .svg files, which it fails to do without the stub. Visio 2003 does complain that some values in the files are missing or of the incorrect data type when opening these files, but it will nonetheless open them and can edit them successfully when the stubbed .dll is present. @@ -0,0 +1,79 @@ +70 stub LssbFDoneDisplay +65 stub LsCompressSubline +1 stub LsCreateContext +3 stub LsCreateLine ..etc. Does it really need them by ordinal? The spec files are typically sorted alphabetically by function name, e.g.,: +@ stub LsCompressSubline +@ stub LsCreateContext +@ stub LsCreateLine +@ stub LssbFDoneDisplay ..etc. Some other minor things: A) you don't need to include the changes to configure, just configure.ac. B) Your comments are formatted a bit strange /* --- ** msls31.dll ** Copyright CodeWeavers, Inc. ** Created: 9/10/2012 by Josh DuBois for CodeWeavers. most files have: /* *msls31.dll * *Copyright 2012 Josh DuBois for CodeWeavers, Inc. * */ similar for your comment about preferring the native version. Welcome to Wine! -- -Austin
Re: Building winetest-latest.exe?
On Sun, Sep 2, 2012 at 9:52 PM, Vincent Povirk madewokh...@gmail.com wrote: As I understand it, you need to set up a mingw build as in http://wiki.winehq.org/CompilingDLLsUsingMingw Sort of. You don't need a separate build tree for building the tests. Just have mingw32 installed, run ./configure, then 'make crosstest'. -- -Austin
Re: Have there been any problems with Wine on GCC 4.7?
On Thu, Aug 23, 2012 at 12:56 PM, Eric Pouech eric.pou...@orange.fr wrote: -g was already the default. Most packagers (to my knowledge) provide a separate debug package, which isn't installed by default. i'm not especially speaking of packagers, but folks who compile wine themselves with something like: ./configure CFLAGS=-O2 and your patch forces -gdwarf2 (whatever -g is requested or not in CFLAGS) hence providing debug info when the user didn't ask for it A+ AJ's taken care of it: http://source.winehq.org/git/wine.git/commitdiff/ce48e2c8ab4537fb57e4416d03f6fdd0685262b8 -- -Austin
Re: Have there been any problems with Wine on GCC 4.7?
On Mon, Aug 20, 2012 at 11:55 PM, Eric Pouech eric.pou...@orange.fr wrote: http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191eae3879fc422e2d -- -Austin the trouble with this patch is that it enables debug info whatever the default configuration is... A+ -- Eric Pouech -g was already the default. Most packagers (to my knowledge) provide a separate debug package, which isn't installed by default. -- -Austin
Re: Have there been any problems with Wine on GCC 4.7?
On Mon, Aug 13, 2012 at 4:46 PM, Scott Ritchie sc...@open-vote.org wrote: On 8/13/12 12:55 PM, Eric Pouech wrote: diff --git a/configure.ac b/configure.ac index 4bd43d1..c80fd8a 100644 --- a/configure.ac +++ b/configure.ac @@ -1746,6 +1746,8 @@ then WINE_TRY_CFLAGS([-Wtype-limits]) WINE_TRY_CFLAGS([-Wunused-but-set-parameter]) WINE_TRY_CFLAGS([-Wwrite-strings]) + WINE_TRY_CFLAGS([-gdwarf-2]) + WINE_TRY_CFLAGS([-gstrict-dwarf]) dnl gcc-4.6+ omits frame pointers by default, breaking some copy protections case $host_cpu in would be simpler, unless I'm missing something. would work too (even if this would be preferable) + WINE_TRY_CFLAGS([-gdwarf-2 -gstrict-dwarf]) Or I could not patch Wine itself and instead patch it's build instructions in the package rules file. But if Wine indeed doesn't work with GCC's new default settings then it should probably be a Wine page (for every distro) http://source.winehq.org/git/wine.git/commitdiff/3f1dbaf3df0ae8ec2f0e86191eae3879fc422e2d -- -Austin
Re: Have there been any problems with Wine on GCC 4.7?
On Mon, Aug 13, 2012 at 2:29 PM, Eric Pouech eric.pou...@orange.fr wrote:
In the meantime, I suppose I could enable the -gdwarf-2 compiler option.
yes (but it's a bit more tricky than it sounds)
something like this will do
A+
diff --git a/configure.ac b/configure.ac
index 4bd43d1..2624dc1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -236,6 +236,12 @@ then
AC_SUBST(TARGETFLAGS,-b $host_alias $TARGETFLAGS)
fi
+dnl Check the debug format (force pure dwarf-2 debug format until we
correctly support other versions)
+tmp_cflags=$CFLAGS
+CFLAGS=`echo $CFLAGS | sed -e 's/-g\\/-gdwarf-2 -gstrict-dwarf/'`
+AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(int argc, char **argv) { return
0; }]])],
+ [], [CFLAGS=$tmp_cflags])
+
dnl Check for flex
AC_CHECK_PROGS(FLEX,flex,none)
if test $FLEX = none
diff --git a/configure.ac b/configure.ac
index 4bd43d1..c80fd8a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1746,6 +1746,8 @@ then
WINE_TRY_CFLAGS([-Wtype-limits])
WINE_TRY_CFLAGS([-Wunused-but-set-parameter])
WINE_TRY_CFLAGS([-Wwrite-strings])
+ WINE_TRY_CFLAGS([-gdwarf-2])
+ WINE_TRY_CFLAGS([-gstrict-dwarf])
dnl gcc-4.6+ omits frame pointers by default, breaking some copy protections
case $host_cpu in
would be simpler, unless I'm missing something.
--
-Austin
Wiki is down
Mind taking a look? :) Have a great weekend! -- -Austin
Re: Cannot run wineinstall
On Sun, Aug 5, 2012 at 2:05 PM, Carlos Tiba carlost...@gmail.com wrote: It displays the message: You are running wineinstall as root, this is not advisable. Please rerun as a user. Aborting. However it is not possible to install anything on Ubuntu Linux if you-re not root. You'll be asked for the password after compiling wine. The command: $ sudo ./wineinstall does not run after passwd enter because of the message above. How is it possible? You could use a premade package, or just run ./configure make sudo make install. In any case, these sort of questions belong on the forum, not wine-devel. Cheers, Austin
Fwd: [GSoC Mentors] [Announce] GSoC 2012 Mentors/Org Admins: Pencils Down and Final Evaluation Dates Approaching
-- Forwarded message -- From: Carol Smith car...@google.com Date: Mon, Aug 6, 2012 at 12:33 PM Subject: [GSoC Mentors] [Announce] GSoC 2012 Mentors/Org Admins: Pencils Down and Final Evaluation Dates Approaching To: Google Summer of Code Mentors List google-summer-of-code-mentors-l...@googlegroups.com Hi there, This is a friendly reminder that Monday, 13 August is our soft pencils down date. We suggest that students have completed their projects by this date and spend a week writing documentation and wrapping up their projects. We require that students stop all coding on 20 August. Monday, 20 August at 19:00 UTC is also when final evaluations open. Please consider this your reminder to submit your final evaluation by 24 August at 19:00 UTC so that you don't delay your students' final payments or possibly jeopardize your organization's attendance at the mentor summit. I have updated the code submission guidelines [0] and posted it on Melange for your reference. Code submission begins once students have received a passing grade on their final evaluations (after 24 August). The deadline is 14 September. One question students ask a lot is what portion of their code to submit if they made changes to an existing code base or their code interacts a lot with a system they didn't write. The answer is: use your best discretion. Have them submit the code that makes the most sense from a user's perspective. If students need help with code submission they should contact the Melange team at melange-soc-...@googlegroups.com. I have posted the questions for the final evaluations below as well for your reference. [0] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/codeguidelines Cheers, Carol How would you rate the student’s performance on his/her project since the midterm evaluations? It has improved since the midterm It has stayed the same since the midterm It has gotten worse since the midterm Considering your student’s original project proposal, how closely does the project produced reflect the project proposed? It’s almost exactly the same - there have been very few changes to the project It’s similar - there have been some changes over the course of the summer It’s different - we changed the goals or scope of the project It’s different - the student diverged from the project plan How much time have you spent on Google Summer of Code since the midterm evaluations (again, take into consideration both time mentoring the student and working on the program as a whole)? 10-15 hours per week 15-20 hours per week 20-25 hours per week 25-30 hours per week 30-35 hours per week 35-40 hours per week 40+ hours per week How does this amount of time spent on the program compare to before the midterms? It’s less than before the midterms It’s about the same It’s more than before the midterms How would you rate your student’s performance overall? Excellent - amongst the best performers I’ve ever worked with Strong, solid performance Okay Poor How would you rate your experience with the program overall? Excellent - one of the best programs I’ve ever participated in Very good Okay Poor Did you have a co-mentor in the program this year? If so, would you consider this a help or a hindrance? Why? What one thing would you tell mentors for your organization to do in the future to help the students’ experience with the program? What was the most rewarding and/or difficult part of the program for you this year? Anything else you’d like to tell us? -- You received this message because you are subscribed to the Google Groups Google Summer of Code Mentors List group. To post to this group, send email to google-summer-of-code-mentors-l...@googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en. -- -Austin
Re: GSoC mentor summit 2012
On Thu, Jul 26, 2012 at 8:07 AM, Owen Rudge o...@owenrudge.net wrote: It looks like the GSoC mentor summit for 2012 has been announced. Are any of the mentors this year interested in attending? It's happening on the 20th/21st October in Mountain View. Details are on the GSoC mentor wiki: http://gsoc-wiki.osuosl.org/index.php/2012 We're allowed two mentors (or if no/only one mentor goes, an admin can go). Once we decide who wants to go, please let me know so I can get you in contact with the Software Freedom Conservancy to work out the ticketing/payment process. -- -Austin
Re: Have there been any problems with Wine on GCC 4.7?
On Mon, Jul 23, 2012 at 7:06 PM, Scott Ritchie sc...@open-vote.org wrote: Wine is the last remaining package still depending on GCC 4.5 in the current Ubuntu alpha, it would be nice to drop GCC 4.5 and forward port Wine, however 4.6 is known to not work too well. But now we have 4.7 -- have there been any bugs attributed to its usage? Thanks, Scott Ritchie My understanding was that the problems introduced in 4.6 are still in 4.7. -- -Austin
Re: What's the right way to implement _wtoi_l?
On Sun, Jul 22, 2012 at 11:07 PM, Alex Henrie alexhenri...@gmail.com wrote: Dear Wine developers, Bug 24389 documents an application crash due to the unimplemented function msvcr90._wtoi_l. I have been looking into how to resolve this problem. I see three workable options: 1. Implement msvcr90._wtoi_l by copying the code from ntdll._wtoi to msvcrt, ignoring the locale parameter for now. 2. Forward msvcr90._wtoi_l to ntdll._wtoi via msvcr90.spec, ignoring the locale parameter for now. 3. Implement msvcr90._wtoi_l as a stub function in msvcrt that always returns 0. Any of these options would fix bug 24389. Which one should I work on? -Alex Judging by similar recent commits (http://source.winehq.org/git/wine.git/commitdiff/f320f6cf4843eab3d22b60674808e4e3de964b5a), 1 seems to be the way to go. -- -Austin
Re: wininet: Support ICU_ENCODE_PERCENT, ICU_ENCODE_SPACES_ONLY, and ICU_NO_META.
On Wed, Jul 18, 2012 at 6:33 PM, Alex Henrie alexhenri...@gmail.com wrote: Without this patch, Internet Explorer 6 produces a lot of messages like fixme:wininet:InternetCanonicalizeUrlW Unhandled flags 0x0400 Wine's wininet.h was missing ICU_ENCODE_PERCENT, which is present in the wininet.h from the Windows 7 SDK. Wine previously treated ICU_ESCAPE like ICU_DECODE. This is incorrect, MSDN and empirical tests agree that ICU_ESCAPE should be ignored: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384342(v=vs.85).aspx https://testbot.winehq.org/JobDetails.pl?Key=20155 Why didn't you include the tests in the patch? -- -Austin
Re: wininet: Support ICU_ENCODE_PERCENT, ICU_ENCODE_SPACES_ONLY, and ICU_NO_META.
On Thu, Jul 19, 2012 at 7:23 AM, Alex Henrie alexhenri...@gmail.com wrote: 2012/7/19 Austin English austinengl...@gmail.com: Why didn't you include the tests in the patch? The tests I wrote always fail in order to output the result of the function to the console for comparison by hand. ICU_ESCAPE is clearly not meant to be used with InternetCanonicalizeUrl, so I'm not sure a test for it is necessary. That said, if you would like me to include a few tests in the patch, let me know. You can set WINETEST_VERBOSE=1 to get the output, whether is passes or fails. Simply changing FALSE to TRUE shows all the tests pass, though you'd likely want to test some broken behavior as well. Of course, it's up to Alexandre if he wants to accept it without tests. I was mostly curious why you didn't submit them, since you already took the effort to write them :). -- -Austin
Re: some patches to read files faster (especially for baldur's gate and infinity engine games)
On Mon, Jul 9, 2012 at 2:06 PM, Emmanuel Anne emmanuel.a...@gmail.com wrote: Hello, I installed baldur's gate lately and noticed it was still slow in wine, especially if I install a few mods. See the description of the bug here : http://bugs.winehq.org/show_bug.cgi?id=17956 So after reading the page about case insensitive filesystems there http://wiki.winehq.org/CaseInsensitiveFilenames I decided that one possible solution was to have everything in lower case. So I made a 1st patch (see attachement). After this, installing a weidu mod in baldur's gate becomes faster, but loading a savegame is still very slow compared to windows. After some more investigation using strace, it's because the program uses NtQueryDirectoryFile to check if a file is present in the override directory instead of trying to open it directly, which produces a getdents call in linux, which is extremely unefficient. So I just added a short cut for this function : if the filename argument has no wildcard, then just use stat to return wether the file exists or not. This is in the 2nd patch. After this, loading savegames was extremely fast, comparable to windows speed, finally, and there are no more slowdowns in game, it runs smoothly all the time ! Well I am sure you'll find I didn't make them the right way, but I hope the ideas will be useful to you and that you'll merge them in one form or another into wine. Oh yes, after applying them, all the new files created by wine will be in lower case, but you'll eventually have to convert all the files to lower case in the wine directories (it's required at least in the baldur's gate 2 directory). Also having a wineprefix with mixed lower and upper case characters would create problems. But except that, it works excessively well ! :) So maybe you'll want this enabled only if the user explecitely chooses to enable it. For me I know I'll keep it ! I attach the simple perl script I used to convert everything to lower case. It would be great to document this patch at http://wiki.winehq.org/InterestingPatches. -- -Austin
Re: kernel32: implement IsValidLocaleName (as a wrapper around IsValidLocale)
On Tue, Jul 10, 2012 at 7:39 AM, Dmitry Timoshkov dmi...@baikal.ru wrote:
Austin English austinengl...@gmail.com wrote:
+BOOL WINAPI IsValidLocaleName( LPCWSTR locale )
+{
+LCID lcid;
+BOOL ret;
+
+TRACE( locale: %s\n, debugstr_w(locale) );
+lcid = LocaleNameToLCID( locale, 0 );
+ret = IsValidLocale( lcid, 0 );
+return ret;
+}
Avoiding (useless) intermediate variables along with the word 'locale'
in the trace would be better IMO.
--
Dmitry.
Fixed and resent the series, thanks for reviewing.
--
-Austin
Re: Policy for the Wiki?
On Wed, Jul 4, 2012 at 4:16 PM, Kyle Auble randomidma...@yahoo.com wrote: Hello all, I've been working on the wiki recently and noticed that a lot of out-of-date or redundant information is retained. For example, completed tasks on to-do lists are checked off and never removed. Isthere an unofficial policy of not deleting info, even if it may exist elsewhere (in the git repo history, wikipage revision history, etc)? Other instances might be stubs dedicated to features in development years ago, or pages on bugs that have already been fixed or triaged in Bugzilla.I know even page deletions can still be reverted, but I wanted to check first before cleaning things out more aggressively. If there are a few unwritten rules everyone likes the wiki to follow, I could add them somewhere as editing guidelines. The wiki tends to have some bit rot, and if you're willing to keep it clean, then I'd say you get more leeway in the editing guidelines. In general though, yes, old info should be updated/removed. Old taskslists, it's a bit more dependent. For instance, the 1.0 / 1.2 / 1.4 task lists are probably useful for old reference, but others could possibly go (may need some examples though). While the topic's up, I was also wondering how moinmoin was chosen as the wiki engine. I couldn't really find a discussion on the mailing lists so I figured it was the best option when the wiki was first started. I can appreciate that it doesn't require a database and it's written in python instead of php. Allowing only inline CSS in tables causes some headaches, but mainly it can be really slow sometimes, especially when editing, and unless using wikilinks or going directly to a page, navigation is tricky. Has the possibility of migrating the wiki to a different engine ever come up? Or does the Wine wiki code just need some tweaking and maybe some tools? To be honest, I don't know if there is a better alternative (MediaWiki is designed for a very different use case and has really messy code). It just seems like something is discouraging even basic upkeep on the wiki, which kind of defeats its whole purpose. -Kyle Dimi Paun (CC'ed) set up/runs the wiki, so he'd be the guy to ask. Other people have discussed MoinMoin/alternatives before, but to my knowledge, there hasn't been much effort put into changing it. -- -Austin
Re: include: fix mingw64 build
On Wed, Jul 4, 2012 at 8:13 AM, Jacek Caban ja...@codeweavers.com wrote: On 07/03/12 20:10, Jacek Caban wrote: On 06/29/12 03:35, Austin English wrote: On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam niko.le...@gmail.com wrote: 2012/6/29 Austin English austinengl...@gmail.com: Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 -- -Austin Hi Austin, I already tried to fix it on Wine side, see [1], but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, as it shouldn't include crtdefs.h by default. BTW, won't that break mingw32 build ? [1] http://source.winehq.org/patches/data/84070 -- Nicolas Le Cam Thanks for the info. Have you or anyone else discussed this with mingw64? I did a quick search on their bugtracker, but don't see anything.. http://sourceforge.net/search/?group_artifact_id=983354type_of_search=artifactgroup_id=202880words=crtdefs FWIW, here is my proposed patch to mingw-w64: http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/5db96424c7b9ac4aa5a66bd0e9724740624bf96f We will see if they like it. The (extended) fix is in mingw-w64 SVN now. Jacek Nice! Thanks. -- -Austin
Fwd: [GSoC Mentors] [Announce] 2012 GSoC Mentor Midterm Evaluations 9 July - 13 July
A friendly reminder for GSOC people. If you won't be able to submit your evaluation during the specified timeline, or have any other questions, please contact me privately. Cheers, Austin -- Forwarded message -- From: Carol Smith car...@google.com Date: Fri, Jun 29, 2012 at 11:41 AM Subject: [GSoC Mentors] [Announce] 2012 GSoC Mentor Midterm Evaluations 9 July - 13 July To: Google Summer of Code Mentors List google-summer-of-code-mentors-l...@googlegroups.com Hi GSoC 2012 Mentors and Org Admins, Per the program timeline [0], starting 9 July you will will be able to submit an evaluation of your student(s)' progress on their projects thus far. Here's some important info on midterm evaluations for those not familiar: Midterm evaluations are done via Melange [1]. Starting at 19:00 UTC on 9 July you will be able to submit an evaluation for your student(s).You can find the evaluation links on your dashboard under 'Evaluations', one for each student you are a mentor (or co-mentor) for. If you are curious about who can see evaluations after they are submitted, please check out the FAQ on Evaluations [2]. I have also pre-published the evaluation questions below in this email so you can prepare. The deadline is 19:00 UTC on 13 July. You may not submit your evaluation before or after the evaluation window. Please ask your org admin to submit your evaluation for you if you absolutely cannot submit yours during the time allotted. Primary mentors, co-mentors, and org admins may all submit evaluations of their students.**Students must have an evaluation on file from both themselves *and* their mentors in order to receive their midterm payments.** There is no excuse for missing the submission of a student's evaluation. You must submit an evaluation for every student you are the primary mentor for this year. You must fill out the entire survey in one session as there's no auto-save in Melange. You may submit, modify, and resubmit an evaluation as many times as you choose up until the deadline. Please note that failing a student at the midterm evaluation means *this student is immediately removed from the program.* There is no way to fail a student at the midterm and have the student continue with the program to try to make it up at the final. If your student fails, your student is out. You might find the FLOSS manual on GSoC evaluations [3] helpful as well. There's some excellent wisdom in there from your fellow mentors and org admins on the evaluation process. Finally, a reminder: This year we will not allow any mentor who misses an evaluation deadline to attend the mentor summit (assuming no one else submits the evaluation on the mentor's behalf before the deadline either). Also, any org that misses 2 or more evaluation deadlines (for the midterm, final, or midterm and final combined) will not be invited to attend the mentor summit this year. Please let me know directly if you have questions or concerns. [0] - http://www.google-melange.com/gsoc/events/google/gsoc2012 [1] - http://google-melange.com [2] - http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs#evaluations [3] - http://www.booki.cc/gsoc-mentoring/evaluations/ Cheers, Carol How many years have you been a mentor for Google Summer of Code (Total - this doesn’t have to be consecutive)? This is my first year 2-3 years More than 3 years If you answered 2-3 years or more than 3 years, what years did you participate? How many years have you been a student in Google Summer of Code? I have never been a student 1 year 2 years 3+ years If you answered 1 year, 2 years, or 3+ years, what years did you participate? At what point did you first make contact with your student? Before the program was announced After my organization was selected to participate in Google Summer of Code During the student application/acceptance phase of the program During the community bonding period After the start of coding How often do you and your student interact? Daily Every few days Weekly Every few weeks Monthly How do you communicate with your student? (Check all that apply) Voice (phone, Skype, etc.) IM/IRC Private emails Mailing Lists Student blog updates In-person meeting(s) Google+ Hangout Other Of the communication methods listed above, which do you use most frequently? How much time do you spend on Google Summer of Code per week (take into consideration your interactions with your student as well as time working with your org and on your own). 1-5 hours 5-10 hours 10-15 hours 15-20 hours More than 20 hours per week How many time zones apart from your student are you? Less than 3 3-6 More than 6 How often do you require status updates from your student? Daily Every few days Weekly Only when explicitly asked for by me Please rate the quality of your interactions and communications with the student (consider his/her communication with you as well as your responses). Very Good (Student is regularly
Re: include: fix mingw64 build
On Thu, Jun 28, 2012 at 6:30 PM, Nicolas Le Cam niko.le...@gmail.com wrote: 2012/6/29 Austin English austinengl...@gmail.com: Fixes http://bugs.winehq.org/show_bug.cgi?id=30980 -- -Austin Hi Austin, I already tried to fix it on Wine side, see [1], but Alexandre told me on IRC that the bug needs to be fixed in mingw-w64, as it shouldn't include crtdefs.h by default. BTW, won't that break mingw32 build ? [1] http://source.winehq.org/patches/data/84070 -- Nicolas Le Cam Thanks for the info. Have you or anyone else discussed this with mingw64? I did a quick search on their bugtracker, but don't see anything.. http://sourceforge.net/search/?group_artifact_id=983354type_of_search=artifactgroup_id=202880words=crtdefs -- -Austin
Re: Testing regedit
On Wed, May 23, 2012 at 12:24 PM, Daniel Jelinski djelins...@gmail.com wrote: Hello, I just noticed that wine's regedit has a few interesting bugs that appear when running with native comctl32. Can I/should I file them in the bugzilla? Regards, Daniel What sort of bugs? In general, any bugs found with native dlls are suspect.. -- -Austin
Re: AppDB, ratings and native vs. builtin trouble
On Wed, May 16, 2012 at 5:14 AM, Alexey Loukianov mooro...@mail.ru wrote: With the recent release of Diablo III we're are at the same spot: game installer auto-installs vcrun2008 redist as a part of installation process, so end-user experience is like this game works out of a box. Problem is that D3 installed isn't working unless user patches Wine's AcceptEx implementation with Erichs patchset, so for vast majority of Wine's userbase installing D3 would be something like copy already installed D3 from other PC - and that would bring the problem of the game requiring native VC++ 2008 runtime on the surface. How should we treat/assign ratings for these cases? Copying an install form windows is unsupported and should be treated as such. -- -Austin
wine/clang warnings
Howdy,
I tried Wine with LLVM/Clang from svn recently, thought others may
like some of the results. I've also ran the static analyzer.
For reference, this is with:
wine-1.5.4-61-g8327e6f, plus the following patch:
diff --git a/include/windef.h b/include/windef.h
index 9cf98e7..e95388a 100644
--- a/include/windef.h
+++ b/include/windef.h
@@ -53,7 +53,7 @@ extern C {
#ifndef __stdcall
# ifdef __i386__
# ifdef __GNUC__
-# ifdef __APPLE__ /* Mac OS X uses a 16-byte aligned stack and not
a 4-byte one */
+# if defined (__APPLE__) || defined (__clang__) /* Mac OS X uses a
16-byte aligned stack and not a 4-byte one */
#define __stdcall __attribute__((__stdcall__))
__attribute__((__force_align_arg_pointer__))
# else
#define __stdcall __attribute__((__stdcall__))
see http://wiki.winehq.org/Clang for more info. Wine was compiled using:
#!/bin/bash
export CC=clang
export CXX=$CC
export CFLAGS=-g -O0 -std=gnu89 -Wno-conversion -Wno-invalid-source-encoding
./configure
-Wno-invalid-source-encoding, because clang does not like our encoding
of strings in winex11/keyboard.c. There are 851 warnings of:
clang -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers
-Wstrict-prototypes -Wtype-limits -Wwrite-strings
-fno-omit-frame-pointer -Wpointer-arith -I/usr/include/freetype2-g
-O0 -std=gnu89 -Wno-conversion -o keyboard.o keyboard.c
keyboard.c:267:17: warning: illegal character encoding in string
literal [-Winvalid-source-encoding]
`,1!,2\,3A3,4$,5%,6^,7,8*,9(,0),-_,=+,
The static analyzer found 2231 bugs (--disable-tests was used).
http://www.sendspace.com/file/qsbv3k
austin@aw21 ~ $ du -h scan-build-2012-05-15-2.tar.bz2
42M scan-build-2012-05-15-2.tar.bz2
austin@aw21 ~ $ sha1sum scan-build-2012-05-15-2.tar.bz2
442cf6faddb45515792d116717c992282496dfbe scan-build-2012-05-15-2.tar.bz2
Cheers,
Austin
Re: GSoC Joystick Configuration Tools
On Thu, May 10, 2012 at 9:40 AM, Lucas Zawacki lfzawa...@gmail.com wrote: Hello all, I'll use this thread to post information and ask questions regarding my GSoC project. First there's a wiki which aggregates some information and lists tasks I'm working on: http://lfzawacki.heroku.com/wine/published/HomePage Then there's a github repo: https://github.com/lfzawacki/wine-joysticks In the repository you'll find the different tools I'll be implementing. They can be easily built and tested, even before they make it into wine. At the moment there's an intial version of the command line joystick tester. This tool is useful for listing connected joysticks, testing if they work correctly in wine, testing axis remapping, watching for dinput trace messages, etc... It's also the basis for the joystick testing GUI. I'll start cleaning up, splitting this code and commiting it to wine next week. For now I'll make a similar tool to this one that tests force feedback. I'll try to make it in the style of the Linux fftest program, but using the dinput interfaces so that a user can test the differences. Cheers, Lucas Any reason you're not using the wine wiki for that? -- -Austin
Re: Find Wine software installer
On Tue, May 1, 2012 at 13:49, Shanuka Wijekoon gihanshanuk...@gmail.com wrote: ha I have a problem that i need to track the software installation.that means I need to keep the location where the files are installed. Are there any place in wine source code to get help for my problem. thank you. You should use the forum for help with Wine. That said, 'wine control' will give you the add/remove programs menu. If you're looking for logs, try using WINEDEBUG=msi. -- -Austin
GSOC 2012 has started
Howdy, Google Summer of Code 2012 has started, and we have 5 students this year: Józef Kucia - Implement missing functions in D3DX9, mentored by Stefan Dösinger - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/jos/58002 Lucas Fialho Zawacki, mentored by Joystick configuration and testing applet Marcus Meissner - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/lfzawacki/36002 Magdalena Nowak - Control Panel, mentored by Owen Rudge - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/magdalena/12001 Marek K Chmiel - Encryption – digital signature security, mentored by Juan Lang - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/mkchmiel/16001 Qian Hong - GSoC project: Improve CJK font support, mentored by Aric Stewart - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/fracting/11001 Good luck everyone! -- -Austin
Re: Regression testing
On Thu, Apr 12, 2012 at 16:58, Daniel Jelinski djelins...@gmail.com wrote: 2012/4/12 Scott Ritchie sc...@open-vote.org: On 4/12/12 1:23 AM, Daniel Jeliński wrote: Hello all, I am trying to get Microsoft SQL Server Management Studio to work flawlessly under Wine. For the most part I create and triage related bug reports, but recently I also started tinkering with code, specifically with comctl library, which I am most familiar with. Back on subject. I thought I found a regression - on Wine 1.4 package downloaded from launchpad the New query button works fine, while on my compiled Wine it produces an error. So I did: git reset --hard wine-1.4 make and, surprisingly, I still had the problem with the compiled version. However after some combination of deleting leftover files, running make clean, make depend and make the button started working, so I started bisecting, hoping for the best. At some point I started getting bad versions, and every subsequent compile was bad - even after I ended bisecting and returned to wine-1.4, the button still did not work (and it still works under packaged Wine - I use the same install for all tests). This time make clean make depend make did not help. Packaged Wine might be different for a few reasons: 1) It is a hybrid 32+64 build, which you can't get in one step on Ubuntu 12.04 anymore 2) It uses GCC-4.5 (12.04 default is 4.6) 3) It has one small patch for fonts (shouldn't matter in your case) 4) It's built in a clean environment on the build daemon 5) It's installed and run out of tree. Thanks, Scott Ritchie I eventually compiled a wine version that behaves like the packaged one - git clean did the trick. Also I'm still on 11.10 (waiting for a final release of 12.04). By the way I've got the results of bisection. The first bad commit was atl80: New dll.. I guess this won't be an easy fix... Disable the dll in winecfg (or use a native dll and set it to native, builtin). -- -Austin
Re: GDI+ pageoffset
On Wed, Apr 11, 2012 at 10:23, Stepa Nick hired...@gmail.com wrote:
Hello. I have following code:
Bitmap * bmp = new Bitmap(500, 500, PixelFormat32bppARGB);
{
Graphics gr(bmp);
//FIRST LINE
PointF* local1PointF = new PointF(17.823631, 89.429169);
PointF* local2PointF = new PointF(17.823631, 87.577080);
//SECOND LINE
PointF* local3PointF = new PointF(14.933444, 89.429169);
PointF* local4PointF = new PointF(14.933444, 87.577080);
Pen * pen = new Pen(Color(255, 0, 0), 0.1);
gr.SetPageUnit(UnitMillimeter);
gr.SetPixelOffsetMode(PixelOffsetModeHalf); //PROBLEM!
gr.DrawLine(pen,(*local1PointF),(*local2PointF));
gr.DrawLine(pen,(*local3PointF),(*local4PointF));
}
When I run it without SetPixelOffsetMode i get equal line, but with it
line are not identical(first line is longer). I explore
dlls/gdiplus/graphics.c and i find this comment: /* FIXME: Pixel
offset mode is not used anywhere except the getter/setter. */. So, I
what to understand why I have different images(how pixeloffset affect
on drawing lines)? I try to run windbg, run
`WINEDEBUG=gdiplus,gdi,ddraw,graphics wine ./my.exe`, but analyzing
output didn`t give my any results. Thanks!
Run with `WINEDEBUG=loaddll wine my.exe` and ensure that builtin
gdiplus is being used.
--
-Austin
Re: ws2_32/tests: Update hostent struct tests
On Tue, Apr 10, 2012 at 21:13, Bruno Jesus 00cp...@gmail.com wrote:
* Added a final required test for the h-h_addr_list[0] to show we
must put it in the right place.
* Removed the cached use of older gethostbyname result since the
memory is static and turned into garbage in windows if the current
call fails.
* Added a skip if we hit older OS allowing we to avoid using broken()
on each test.
+if(h-h_addr_list == addr.mem) /* = W2K */
+{
+skip(Skipping hostent tests since this OS is unsupported\n);
+return;
+}
+
You should use win_skip so that the tests will only be skipped on
windows (we'd want the failure to be exposed on wine).
--
-Austin
Re: ws2_32/tests: Update hostent struct tests
On Wed, Apr 11, 2012 at 13:27, Bruno Jesus 00cp...@gmail.com wrote: On Wed, Apr 11, 2012 at 15:05, Austin English austinengl...@gmail.com wrote: On Tue, Apr 10, 2012 at 21:13, Bruno Jesus 00cp...@gmail.com wrote: You should use win_skip so that the tests will only be skipped on windows (we'd want the failure to be exposed on wine). You mean I should use win_skip and remove the return so the flow goes on in wine? Will win_skip return automatically? No, just change the skip to win_skip. On windows, the test will be skipped, then you will return. On wine, the test will fail, so we can no that some behavior broke (from changed code or otherwise). You'll still return, but without that change, the failure will not be noticed. -- -Austin
Re: GDI+ pageoffset
On Wed, Apr 11, 2012 at 11:58, Stepa Nick hired...@gmail.com wrote: Run with `WINEDEBUG=loaddll wine my.exe` and ensure that builtin gdiplus is being used. I run `WINEDEBUG=loaddll wine my.exe` and get such output: trace:loaddll:load_builtin_dll Loaded LKERNEL32.dll at 0x7b81: builtin trace:loaddll:load_native_dll Loaded LZ:\\home\\user\\tmp\\test\\CalculateCPP.exe at 0x40: native trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\msvcrt.dll at 0x7254: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\advapi32.dll at 0x6855: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\gdi32.dll at 0x684b: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\version.dll at 0x6e96: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\user32.dll at 0x6838: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\rpcrt4.dll at 0x70d0: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\ole32.dll at 0x685c: builtin trace:loaddll:load_native_dll Loaded LC:\\windows\\system32\\gdiplus.dll at 0x4ec5: native trace:loaddll:load_native_dll Loaded LC:\\windows\\system32\\MSVCR100.dll at 0x78aa: native trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\shlwapi.dll at 0x686c: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\comctl32.dll at 0x6872: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\msimg32.dll at 0x6881: builtin trace:loaddll:load_native_dll Loaded LC:\\windows\\system32\\mfc100u.dll at 0x785f: native trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\imm32.dll at 0x68bc: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\winex11.drv at 0x6898: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\uxtheme.dll at 0x68c1: builtin trace:loaddll:load_builtin_dll Loaded LC:\\windows\\system32\\dwmapi.dll at 0x68c4: builtin trace:loaddll:load_native_dll Loaded LC:\\windows\\system32\\MFC100ENU.DLL at 0x5d36: native fixme:heap:HeapSetInformation (nil) 1 (nil) 0 fixme:win:EnumDisplayDevicesW ((null),0,0x32f744,0x), stub! So, non-native gdiplus.dll used?! Hmm... Can I see into gdiplus.dll anyway? I really need to understand how pixeloffset works. We don't really encourage tracing native dlls, that could be interpreted as reverse engineering. You can force builtin gdiplus in winecfg, for what it's worth. I suppose gdi32 could also be at play, though I can't say that for sure. -- -Austin
