Partial phase out of *winehq.com addresses
As mentioned about a month ago, we were planning to phase out the winehq.com email addresses, and use winehq.org exclusively. It looks like the few holdouts have converted over for awhile now, so I added a filter to the mailman program to silently drop anything mailed to winehq.com. If Jeremy wants to set the MTA (or whatever) to reject those addresses, that might be better. Then anyone accidently mailing to the wrong address would (presumably) get a delivery error message. And it would take a small portion of the load off mailman.
Re: Sent a patch twice
Rene Kok wrote: I never submitted a patch before. It wasn't a patch I created just resubmitting it. However I accidentally sent it to the wine-patches mailing list twice. The first time I wasn't subscribed, which I prefer not to because the huge amount of mail I'll get when I do :-) You can go to your preferences, by going here: http://www.winehq.org/mailman/listinfo/wine-devel Fill in your email address in the last box and click the edit options button. Scroll down and there is an option for Mail delivery. Turn it off, and you can remain subscribed but not be sent the postings.
Proposal to phase out *winehq.com email addresses
Due to the rather large amount of spam sent to the *winehq.com email addresses (as opposed to *winehq.org), I would like to phase them out. I will state up front that this proposal benefits only me or any future moderator. Since I have been doing that for about 6 years now, hopefully I'll get a bit of sympathy ;) A cursory inspection of postings to this list show that almost everyone already posts to *winehq.org. I would propose that for a few weeks, I'll simply keep track of where people are posting to, and send private emails to the very few who post to .com. Once everyone is posting to the .org address, I'll implement a filter in mailman that simply drops the others. I have already done this as a test on the announce, bugs, and cvs lists, and this eliminates about half of the spam. And while I am at it, anyone who wants to help with the moderation and is willing to stick with it for the long term, let me know.
Re: Proposal to phase out *winehq.com email addresses
James Hawkins wrote: How about an automated response email for users that post to winehq.com telling them to report to winehq.org instead? I'm assuming spam bots aren't smart enough to read that reply and post to winehq.org themselves. No, we don't want automated responses, because much (or probably most) of the spam has fake email addresses. That would result in us spamming.
Re: [PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)
Dmitry Timoshkov wrote: Vitaly Budovski [EMAIL PROTECTED] wrote: Now that you got rid of sqrt calls usage of float numbers internally doesn't look justified (to me) anymore. Only because in this instance it is used with integer data. It doesn't need to be limited to just integer values. Besides, what would be gained by changing it to integers as you suggest? What would be gained is an additional speed. Since this code is supposed to be used to handle palette/color data there is no need to use floats at all. While I cannot vouch for the accuracy, this might be of interest: http://lua-users.org/wiki/FloatingPoint
Re: [xcopy]New Korean Resource
Hwang YunSong(ȲÀ±¼º) wrote: Firest release This might get accepted a little faster if you create them like this: diff -u /dev/null wine/programs/xcopy/Ko.rc xcopy-ko.diff Of course, you should be in the directory where you have your Wine tree, for that to work. Patches should not be created from within the subdirectory that contains the file being patched.
Re: WineD3D: Make CreateCubeTexture fail when not supported
Felix Nawothnig wrote: Not tested under Windows (does _anyone_ besides me have a Matrox? :) - would be nice if someone with either an MGA or an really ancient GPU could run the test on windows (if the pool=0 trace has an hr!=0 you got one of those ancient cards :). CCing to wine-devel for that reason. On a Matrox G550, Win2k, crosscompiled on Linux with MingW: I:\dlls\d3d8\testsd3d8_crosstest texture texture.c:122:texture caps: 0x41c7 texture.c:110:pool=0 hr=0x8876086c texture.c:110:pool=1 hr=0x8876086c texture.c:110:pool=2 hr=0x8876086c texture.c:110:pool=3 hr=0x texture: 57 tests executed (0 marked as todo, 0 failures), 0 skipped.
Re: SoC Idea: Improve bultin WordPad
Dan Kegel wrote: Alex wrote: closest I have gotten is some patches for Wine's WordPad implementation. Granted, it's less sexy than games, but you could learn more about C and Wine by building on that experience. There are lots of small and easy improvements that can be done get Wordpad up to par with native. Then come back next year to fix the games! That i s a good idea. :) I think I will go for it, unless anyone has objections to it. Sounds good to me. Suggestion: spend a day or two filing bugs or enhancement requests now for a bunch of things you'd like to fix / improve in wordpad. (I might even suggest broadening your proposal to include notepad; maybe there are a couple low-hanging fruit there.) Printing please! It needs lots of work. Wordpad doesn't have it, and notepad printing is terrible.
Re: some emails not arriving to wine-patches (was CMD.EXE resubmits)
Ann Jason Edmeades wrote: As an FYI I sent the same patchset to another email account (not on my ISP, just one of the free ones) and they all got through 4 times. It would start to point to the wine-patches side of things, but I have never seen anyone else have problems Note I am not seeing any rejection emails either You won't get rejection emails. The patches are not showing up in the moderation queue, and you only get rejections if they show up there. Though I don't know where they are going. I think a month or two ago Jeremy mentioned making some changes to limit the number of simultaneous email connections... or something like that. I really didn't understand it, so I didn't pay close attention.
Re: 32 bpp cursors?
Dan Kegel wrote: http://bugs.winehq.org/show_bug.cgi?id=4273 points to a patch set that implements 32 bit per pixel cursors and a bunch of other cursor stuff. Looks like the patch got dropped by the author, though, and since it makes server changes, it's going to be hard to get past Alexandre. Is anyone interested in picking this up? Well, no server changes are needed just to implement 32 bits per pixel. There are rather simple changes needed in the file dlls/winex11.drv/mouse.c in create_cursor(), and the places that need to be changed are cleverly marked by switch (ptr-bBitsPerPixel) ;) I tried installing Google Sketchup, but could not get that to install. That said, it looks like 32 bit pixels use 8 bits each of RGB, plus an extra 8 bits of alpha (which apparently controls transparency). So probably you could duplicate the 24 bit case, read out the extra 8 bits and just throw them away for now. Standard X cursors don't support alpha, AFAIK.
Re: [1/4] wined3d: Fix WINED3DPRESENT_PARAMETERS and use it instead of D3DPRESENT_PARAMETERS
H. Verbeet wrote: It looks like the patch might be a bit large for the list, here's a compressed version instead. Anything over 80K just gets caught in the mail queue. It should get through eventually.
Re: Window focus testing
Dmitry Timoshkov wrote: Duane Clark [EMAIL PROTECTED] wrote: Is it possible to do window focus testing in Wine conformance tests? Or does the windows not being mapped mean that this testing cannot be done? Or maybe I am doing something completely wrong; which is likely ;) Have a look at dlls/user32/tests/win.c,test_SetFocus(). Ah, ok. This test shows the window temporarily. Somewhere I had gotten the idea that we didn't do that. Thanks.
Window focus testing
Is it possible to do window focus testing in Wine conformance tests? Or does the windows not being mapped mean that this testing cannot be done? Or maybe I am doing something completely wrong; which is likely ;) I am specifically trying to test window focus in this bug: http://bugs.winehq.org/show_bug.cgi?id=7280 As mentioned in the bug, I turned the treeview conformance test into a standalone test with a mapped window, and added testing that does show focus behavior. But so far I have not been able to get it to give good results in a Wine conformance test.
Re: Test case for Bug 50 [Was: Bug 50]
Pedro Araujo Chaves Jr. wrote: I've just finished writing a test case for Bug 50, but I'm missing *a single thing* that prevents it from working under Windows: I still don't know how to get the width of the text output by ExtTextOutW(). GetTextExtentPoint32 For some examples in Wine, look at almost any control in comctl32.
Re: [AppDB] Langauge fixes for the FAQ
Kai Blin wrote: ... I think most native speakers just get the plural s and the 's genitive mixed up. Like their, there and they're. Of course, I'd have to ask a native speaker to confirm that. Or, while not an authoritative source, check out: http://en.wikipedia.org/wiki/English_plural As a native speaker, I would just use a plain s, as Wikipedia suggests.
Re: Questions concering an application I maintain
Jacob Alberty wrote: What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?). SPY++, at least older versions, work fine under Wine.
Re: Dapper, git, and version-stamp pain again
Dan Kegel wrote: On one of my dapper boxes (an old laptop), I got the error main.o: In function `check_command_line':/home/dank/wine-git/loader/main.c:89: undefined reference to `wine_version' today. Turns out the version-stamp rule in loader/Makefile is misbehaving; I had to hack that rule to not invoke git at all. Hmm. I remember having to do that before. Oh, yeah, it's coming back to me now: Dapper's git --version reports 1.1.3, and http://wiki.winehq.org/GitWine#head-f90aa63f963ccd6f1b34f59e4fdaafaecc72ad18 says that's too old. Grr. I guess I should submit a patch that checks git's version and doesn't break the build if it's only 1.1.3... it'd save me fifteen minutes next time I forget about this... - Dan At least with git 1.1.4, I seem to need the attached patch to create a valid wine_version. Subject: [PATCH] Seems to be needed. --- loader/Makefile.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 70e18f05992192ef78dc6e2eb3a5002ba804ca6c diff --git a/loader/Makefile.in b/loader/Makefile.in index f3e365f..9b256ab 100644 --- a/loader/Makefile.in +++ b/loader/Makefile.in @@ -68,7 +68,7 @@ clean:: $(RM) version.c version-stamp version-stamp: dummy - (GIT_DIR=$(TOPSRCDIR)/.git git-describe 2/dev/null || echo [EMAIL PROTECTED]@) | sed -e 's/\(.*\)/const char wine_version[] = \1;/' $@ || ($(RM) $@ exit 1) + (GIT_DIR=$(TOPSRCDIR)/.git git-describe master 2/dev/null || echo [EMAIL PROTECTED]@) | sed -e 's/\(.*\)/const char wine_version[] = \1;/' $@ || ($(RM) $@ exit 1) version.c: version-stamp @cmp -s version-stamp $@ || cp version-stamp $@ -- 1.1.4
Re: listview: Remove over constrained restriction on creating subitems.
Alexandre Julliard wrote: Duane Clark [EMAIL PROTECTED] writes: Changelog: Remove over constrained restriction on creating subitems. Subject: [PATCH] Remove over constrained restriction on creating subitems. This breaks the tests: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so listview.c touch listview.ok listview.c:305: Test failed: ret 1 make[2]: *** [listview.ok] Error 1 Rats. Well, a bit more testing on Windows shows that setting a LVIF_STATE on a subitem is actually valid. And the state setting of items in Wine in report mode is in general fairly broken. So I'll see if I can fix that up a bit and resubmit.
Re: comctl monthcalendar help
Vijay Kiran Kamuju wrote: Hi, I am trying to fix visual bug in comctl monthcalendar control. When I am using the control spy v2.0 for comctl5.0, I can see that current date is highled with grey background on windows xp. (similar to when we click a day in the calendar) But on wine its not happening. I am trying to find out, how we draw that highlighting. And also how we draw the default calendar. In general, drawing is done by the function Paint; in the case of the monthcal, by MONTHCAL_Paint. The default date is set in MONTHCAL_Create, with the call GetLocalTime(infoPtr-todaysDate); The decoration of the day, including highlighting, is done in MONTHCAL_DrawDay. The highlighting would be the calls hbr = GetSysColorBrush(COLOR_GRAYTEXT); hrgn = CreateEllipticRgn(r.left, r.top, r.right, r.bottom); FillRgn(hdc, hrgn, hbr);
Re: msvcrt: fread: fill buffer on small reads
Markus Amsler wrote:
Duane Clark wrote:
Alexandre Julliard wrote:
Markus Amsler [EMAIL PROTECTED] writes:
+ /* fill empty buffer on small reads */
+ if(!file-_cnt rcnt = MSVCRT_BUFSIZ) {
+MSVCRT__filbuf(file);
+/* reset internal buffer */
+file-_cnt++;
+file-_ptr = file-_base;
+ }
You need to handle errors properly, and MSVCRT__filbuf is probably not
the most appropriate thing to use here, a simple read would be
better.
Are you referring to _read() or read_i()? Those don't have an
associated internal file buffer/cache (I guess because they don't have
an associated file-_cnt and _ptr). Or were you referring to some
other read call?
fread already does a _read() once it determines the current buffer is
empty.
I'm also not sure which read you mean. But i assumed some sort of
stripped down inline MSVCRT__filbuf with read_i.
You probably want to continue to use _read(), since that handles the
difference between text and binary file operations. Go ahead and take a
shot at an implementation.
Make sure to run the file tests in the tests directory to verify that
they all still pass.
Re: msvcrt: fread: fill buffer on small reads
Alexandre Julliard wrote:
Markus Amsler [EMAIL PROTECTED] writes:
+ /* fill empty buffer on small reads */
+ if(!file-_cnt rcnt = MSVCRT_BUFSIZ) {
+MSVCRT__filbuf(file);
+/* reset internal buffer */
+file-_cnt++;
+file-_ptr = file-_base;
+ }
You need to handle errors properly, and MSVCRT__filbuf is probably not
the most appropriate thing to use here, a simple read would be
better.
Are you referring to _read() or read_i()? Those don't have an associated
internal file buffer/cache (I guess because they don't have an
associated file-_cnt and _ptr). Or were you referring to some other
read call?
fread already does a _read() once it determines the current buffer is empty.
Re: EnumServicesStatusA - Typical return structure contents with a working internet LAN connection
Nick Law wrote: I've never written anything under MS windows otherwise I would write a small application myself that calls EnumServicesStatus figure it out myself. In fact maybe I will have to get myself a copy of visual C++ so I can do these tests. Have you looked at creating a conformance test to include with Wine? That would be preferable. http://www.winehq.org/site/docs/winedev-guide/testing I guess you would create a new test file dlls/advapi32/tests/service.c with a test of this behavior. Take a look at the other tests already there to get an idea of how it is done. Included there are instructions for cross compiling a Windows executable in Linux using MinGW. No need to get and learn visual C++. Regards Nick Law PS I'm new to this debugging without access to the applications source code, so any hints tricks would be appreciated. It looks like I may have to learn Intels assembler instruction set as well!, which I don't mind. The last time I wrote an assembly language program was 25 years ago on a PerkinElmer 3220 mini computer! So this should be fun. Ack... assembler? Hopefully that won't be required ;)
Re: Finding a regression
Doug Laidlaw wrote: I may be on the wrong list. A program I use has shown a backward step in graphics between Wine 0.9.15 and 0.9.16, and I am trying to find the change responsible. I currently have Wine set as at 2006-06-21 16:21:20 CDT, it is identifying as 0.9.16, and the fault is present. The Web site says to get the CVS history from the mailing list archives, but the archive is only up to mid-2005. If you want to continue with CVS, you are apparently looking at the old CVS archive, at: http://www.winehq.org/hypermail/wine-cvs/2005/05/index.html The new one is current, and at (pipermail vs hypermail): http://www.winehq.org/pipermail/wine-cvs/2006-August/thread.html Also, if you like a newsreader interface: news://news.gmane.org/gmane.comp.emulators.wine.cvs
Re: msvcrt: In text mode a ctrl-z signals EOF
Duane Clark wrote: Changelog: In text mode a ctrl-z signals EOF Spotted by David Hagood with test suggested by Dan Kegel Howdy David. Any chance you could try out this patch? I added a conformance test, as suggested by Dan, and it looks like any data after a ctrl-z is stripped. Of course, it may be that in the real world there will never be anything other than additional ctrl-z characters, in which case your version would be fine (and more efficient). http://www.winehq.org/pipermail/wine-patches/2006-August/029544.html
Re: Printing to a file
Detlef Riekenberg wrote: My direction to fix printing in wine is from low-level to high-level. Print-Monitors are already managed in git-HEAD, and they are loaded and used in my tree (Port-Functions). Afterwards, the Printer-Functions will be updated and then gdi.exe (16-Bit) is no longer required for printing. Ok, I'll leave this part alone for awhile then.
Printing to a file
Currently, using the Wine supplied print dialog, printing to a file
results in a file named FILE:. In Windows (at least Win2k) a simple
one line dialog box is put up where the filename can be typed in. I
don't see a reason why a full Save As dialog would not be preferable;
some programs override the standard dialog with a full Save As dialog.
It looks to me like the correct place to do this is in gdi/printdrv.c
CreateSpoolFile(). So I have tried adding the attached patch to the
function to play with, adding comdlg32 to the libraries in the makefile.
But the call to GetSaveFileNameW(ofn) crashes. I guess the first
question is whether it is ok to call that from printdrv. And if so, is
there an example of how to do it correctly?
Index: dlls/gdi/printdrv.c
===
RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v
retrieving revision 1.47
diff -u -p -r1.47 printdrv.c
--- dlls/gdi/printdrv.c 23 May 2006 12:47:58 - 1.47
+++ dlls/gdi/printdrv.c 16 Jul 2006 22:43:03 -
@@ -50,6 +50,7 @@
#include wine/debug.h
#include gdi.h
#include gdi_private.h
+#include commdlg.h
WINE_DEFAULT_DEBUG_CHANNEL(print);
@@ -470,6 +471,26 @@ static int CreateSpoolFile(LPCSTR pszOut
}
if (!psCmd[0] !strncmp(LPR:,pszOutput,4))
sprintf(psCmd,|lpr -P%s,pszOutput+4);
+else if (!psCmd[0] !strncmp(FILE:,pszOutput,5)) {
+OPENFILENAMEW ofn;
+WCHAR szFile[MAX_PATH];
+WCHAR szDir[MAX_PATH];
+static const WCHAR ps_files[] = { '*','.','p','s',0 };
+
+ZeroMemory(ofn, sizeof(ofn));
+GetCurrentDirectoryW(sizeof(szDir)/ sizeof(*szDir), szDir);
+lstrcpyW(szFile, ps_files);
+ofn.lStructSize = sizeof(OPENFILENAMEW);
+ofn.lpstrFile = szFile;
+ofn.nMaxFile= sizeof(szFile)/ sizeof(*szFile);
+ofn.lpstrInitialDir = szDir;
+ofn.Flags = OFN_OVERWRITEPROMPT;
+if (GetSaveFileNameW(ofn)) {
+WideCharToMultiByte(CP_ACP, 0, szFile, -1, psCmd, 1024, NULL, NULL);
+TRACE(Save to filename %s\n, psCmd);
+}
+
+}
TRACE(Got printerSpoolCommand '%s' for output device '%s'\n,
psCmd, pszOutput);
Re: Printer fonts
Duane Clark wrote:
It looks like, when printing via CUPS, if the PPD file for an installed
printer does not contain entries (usually at the end of the file) like:
*DefaultFont: Courier
*Font AvantGarde-Book: Standard (001.006S) Standard ROM
*Font AvantGarde-BookOblique: Standard (001.006S) Standard ROM
... (lots more)
...
It seems to me that Wine probably should work in this case. Would it be
acceptable to supply the defaults used in Wine's generic PPD file if
they are not in the one being used? I could take a shot at trying to
code that if it would be acceptable. Otherwise, I could change the error
message to perhaps better explain what the problem is.
Attached is a proposed patch that uses *Font entries from Wine's
generic.ppd file if the printer PPD file does not have them. Would
something along these lines be acceptable?
Index: dlls/wineps.drv/init.c
===
RCS file: /home/wine/wine/dlls/wineps.drv/init.c,v
retrieving revision 1.3
diff -u -p -b -r1.3 init.c
--- dlls/wineps.drv/init.c 15 Jun 2006 16:08:37 - 1.3
+++ dlls/wineps.drv/init.c 15 Jul 2006 17:57:26 -
@@ -529,6 +529,7 @@ PRINTERINFO *PSDRV_FindPrinterInfo(LPCST
const char *ppd = NULL;
DWORD ppdType;
char* ppdFileName = NULL;
+char* generic_ppdFileName = NULL;
HKEY hkey;
BOOL using_default_devmode = FALSE;
@@ -604,17 +605,18 @@ PRINTERINFO *PSDRV_FindPrinterInfo(LPCST
res = GetPrinterDataA(hPrinter, PPD File, ppdType, (LPBYTE)ppdFileName, needed, needed);
}
}
-/* Look for a ppd file for this printer in the config file.
+/* Look for a ppd file for this printer in the registry.
* First look under that printer's name, and then under 'generic'
*/
/* @@ Wine registry key: HKCU\Software\Wine\Printing\PPD Files */
if((res != ERROR_SUCCESS) !RegOpenKeyA(HKEY_CURRENT_USER, Software\\Wine\\Printing\\PPD Files, hkey))
{
const char* value_name;
+LONG retval = ERROR_SUCCESS+1;
if (RegQueryValueExA(hkey, name, 0, NULL, NULL, needed) == ERROR_SUCCESS) {
value_name=name;
-} else if (RegQueryValueExA(hkey, generic, 0, NULL, NULL, needed) == ERROR_SUCCESS) {
+} else if ((retval=RegQueryValueExA(hkey, generic, 0, NULL, NULL, needed)) == ERROR_SUCCESS) {
value_name=generic;
} else {
value_name=NULL;
@@ -622,10 +624,36 @@ PRINTERINFO *PSDRV_FindPrinterInfo(LPCST
if (value_name) {
ppdFileName=HeapAlloc(PSDRV_Heap, 0, needed);
RegQueryValueExA(hkey, value_name, 0, ppdType, (LPBYTE)ppdFileName, needed);
+#ifdef HAVE_CUPS_CUPS_H
+generic_ppdFileName=HeapAlloc(PSDRV_Heap, 0, needed);
+if (retval == ERROR_SUCCESS)
+RegQueryValueExA(hkey, value_name, 0, ppdType, (LPBYTE)generic_ppdFileName, needed);
+else if (RegQueryValueExA(hkey, generic, 0, NULL, NULL, needed) == ERROR_SUCCESS)
+RegQueryValueExA(hkey, value_name, 0, ppdType, (LPBYTE)generic_ppdFileName, needed);
+#endif
}
RegCloseKey(hkey);
}
+#ifdef HAVE_CUPS_CUPS_H
+if (!generic_ppdFileName)
+{
+const char *data_dir, *filename;
+
+if ((data_dir = wine_get_data_dir())) filename = /generic.ppd;
+else if ((data_dir = wine_get_build_dir())) filename = /dlls/wineps.drv/generic.ppd;
+else
+{
+res = ERROR_FILE_NOT_FOUND;
+ERR (Error %li getting PPD file name for printer '%s'\n, res, name);
+goto closeprinter;
+}
+generic_ppdFileName = HeapAlloc( PSDRV_Heap, 0, strlen(data_dir) + strlen(filename) + 1 );
+strcpy( generic_ppdFileName, data_dir );
+strcat( generic_ppdFileName, filename );
+}
+#endif
+
if (!ppdFileName)
{
const char *data_dir, *filename;
@@ -753,6 +781,20 @@ PRINTERINFO *PSDRV_FindPrinterInfo(LPCST
pi-next = NULL;
pi-Fonts = NULL;
+#ifdef HAVE_CUPS_CUPS_H
+/*
+ * Some manufacturer supplied PPD files do not have the *Font and *DefaultFont sections.
+ * In this case, use the entries from the Wine supplied generic.ppd file.
+ */
+if (!(pi-ppd-InstalledFonts) generic_ppdFileName) {
+PPD *generic_PPD;
+TRACE(No fonts in supplied PPD. Using fonts from generic PPD.\n);
+generic_PPD = PSDRV_ParsePPD(generic_ppdFileName);
+pi-ppd-InstalledFonts = generic_PPD-InstalledFonts;
+if (!(pi-ppd-DefaultFont))
+pi-ppd-DefaultFont = generic_PPD-DefaultFont;
+}
+#endif
for(font = pi-ppd-InstalledFonts; font; font = font-next) {
afm = PSDRV_FindAFMinList(PSDRV_AFMFontList, font-Name);
if(!afm) {
Printer fonts
It looks like, when printing via CUPS, if the PPD file for an installed printer does not contain entries (usually at the end of the file) like: *DefaultFont: Courier *Font AvantGarde-Book: Standard (001.006S) Standard ROM *Font AvantGarde-BookOblique: Standard (001.006S) Standard ROM ... (lots more) Then when Wine goes to create the registry entries for the printers, it prints out messages like: To use WINEPS you need to install some AFM files. fixme:winspool:AddPrinterW DocumentPropertiesW on printer 'Li560' fails To use WINEPS you need to install some AFM files. And printing with Wine won't work to that printer. It looks like the PPD files supplied with CUPS contain those entries, so this is not normally a problem. However, some manufacturers supply PPD files that do not have them. In particular, Canon supplies a nice package of files designed for installation into CUPS under Linux: ftp://download.canon.jp/pub/driver/bj/linux The package bjcups-2.4.0 contains this, including PPD files. But the supplied PPD files do not contain the above mentioned entries. Simply copying those entries from, for example, the Wine supplied generic.ppd into the Canon supplied PPD file allows the printer to be installed correctly in Wine and print: http://www.winehq.org/pipermail/wine-users/2006-July/022856.html Looking at the PPD spec version 4.3, the *Font entries are not part of the required entries (listed at the beginning of section 5, page 41). The same section does say that Every feature of the device that can be described by a PPD keyword should be included in the PPD file. So it would appear that Canon perhaps should supply them. On the other hand, the CUPS supplied cupstestppd flags the file as PASS. It seems to me that Wine probably should work in this case. Would it be acceptable to supply the defaults used in Wine's generic PPD file if they are not in the one being used? I could take a shot at trying to code that if it would be acceptable. Otherwise, I could change the error message to perhaps better explain what the problem is.
Re: indented relay traces
James Hawkins wrote: On 6/24/06, Eric Pouech [EMAIL PROTECTED] wrote: this won't work for a multithreaded program tools/examine_relay does what you want, plus some other goodies (calls that didn't return...) Ah, didn't know about that tool. You learn something new every day. It is also not immediately obvious that it will indent in two slightly different formats. Add a flag to the end of the command line to get different formatting: tools/examine_relay wine.log -f
Re: bugzilla report changes
Saulius Krasuckas wrote: I just have submited an additional attachment on my report page [*]. After this bugzilla said to me: Changes Submitted -- Attachment #2466 to Bug #2082 Created Email sent to: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Excluding: [EMAIL PROTECTED] Well, I don't understand, why this hasn't been sent to [EMAIL PROTECTED] Did that happen by a design? New bugs are assigned by default to [EMAIL PROTECTED], and so any additional postings get sent there. When a bug is reassigned to someone else, it is necessary to move the [EMAIL PROTECTED] to the CC list in order for the postings to continue to be sent out (at least that is the way it used to be, and apparently it has not changed). In the past, several moderators have attempted to catch these changes. But inevitably some will get missed. I suppose this could be fixed by subscribing [EMAIL PROTECTED] Would someone like to give that a try?
Re: Newbie question clipboard
Thomas Hehl wrote: 2. I haven't found a user32.c and have found many, many hits in the source for GetClipboardData that I'm trying to sort through? How do I find the source code for that call? I'll just add one other simple method, since others did not mention it. In: http://source.winehq.org/ident You can just type in GetClipboardData, and it will find it for you.
A bit more on edit control margins
I went ahead and took a bunch more measurements of font margins in the edit control. These are all taken on real Win2k using traces added to the conformance test test_margins_font_change, and cross compiled with MinGW. So here they are for posterity. The results are rather confusing to me. But there seems to be a general trend. If MinA MinC, then the trend seems to be something close to: left = (- MinA - MinC) / 2 right = (- MinA - MinC) / 2 if MinA = MinC left = (- MinA) / 2 right = (- MinC) / 2 edit.c:807:Font:Verdana height=6 ave width=3 max width=7 edit.c:818:ABC MinA=-1, minC=-3 edit.c:825:Margins left=0, right=1 edit.c:807:Font:Verdana height=8 ave width=3 max width=9 edit.c:818:ABC MinA=-1, minC=-4 edit.c:825:Margins left=0, right=2 edit.c:807:Font:Verdana height=12 ave width=5 max width=13 edit.c:818:ABC MinA=-1, minC=-5 edit.c:825:Margins left=0, right=3 edit.c:807:Font:Verdana height=16 ave width=7 max width=19 edit.c:818:ABC MinA=-1, minC=-7 edit.c:825:Margins left=1, right=4 edit.c:807:Font:Verdana height=20 ave width=9 max width=25 edit.c:818:ABC MinA=-2, minC=-9 edit.c:825:Margins left=1, right=5 edit.c:807:Font:Verdana height=22 ave width=9 max width=27 edit.c:818:ABC MinA=-2, minC=-9 edit.c:825:Margins left=1, right=5 edit.c:809:Font:Verdana height=23 ave width=10 max width=28 edit.c:825:ABC MinA=-1, minC=-10 edit.c:832:Margins left=1, right=6 edit.c:807:Font:Verdana height=26 ave width=11 max width=33 edit.c:818:ABC MinA=-1, minC=-12 edit.c:825:Margins left=1, right=7 edit.c:807:Font:Verdana height=29 ave width=12 max width=36 edit.c:818:ABC MinA=-1, minC=-13 edit.c:825:Margins left=1, right=7 edit.c:811:Font:Verdana height=23 ave width=11 max width=29 edit.c:813:Italic=0 Cmded Weight=600 TM Weight=700 edit.c:815:otmEMSquare=15 edit.c:828:ABC MinA=-1, minC=-11 edit.c:835:Margins left=1, right=6 edit.c:811:Font:Verdana height=23 ave width=11 max width=34 edit.c:813:Italic=0 Cmded Weight=700 TM Weight=700 edit.c:815:otmEMSquare=15 edit.c:828:ABC MinA=-1, minC=-11 edit.c:835:Margins left=1, right=6 edit.c:807:Font:Arial height=12 ave width=4 max width=24 edit.c:818:ABC MinA=-4, minC=-2 edit.c:825:Margins left=2, right=2 edit.c:807:Font:Arial height=16 ave width=6 max width=35 edit.c:818:ABC MinA=-7, minC=-2 edit.c:825:Margins left=3, right=3 edit.c:807:Font:Arial height=19 ave width=8 max width=45 edit.c:818:ABC MinA=-7, minC=-3 edit.c:825:Margins left=4, right=4 edit.c:809:Font:Arial height=24 ave width=9 max width=56 edit.c:812:otmEMSquare=15 edit.c:825:ABC MinA=-10, minC=-2 edit.c:832:Margins left=6, right=5 edit.c:811:Font:Arial height=24 ave width=10 max width=53 edit.c:813:Italic=0 Cmded Weight=700 TM Weight=700 edit.c:815:otmEMSquare=15 edit.c:828:ABC MinA=-9, minC=-2 edit.c:835:Margins left=6, right=5 edit.c:807:Font:Bookman Old Style height=16 ave width=6 max width=18 edit.c:818:ABC MinA=-1, minC=-2 edit.c:825:Margins left=2, right=2 edit.c:809:Font:Bookman Old Style height=24 ave width=10 max width=32 edit.c:812:otmEMSquare=15 edit.c:825:ABC MinA=-2, minC=-2 edit.c:832:Margins left=4, right=4 edit.c:807:Font:Century Gothic height=24 ave width=10 max width=28 edit.c:818:ABC MinA=-2, minC=-2 edit.c:825:Margins left=4, right=4 edit.c:807:Font:Courier New height=24 ave width=13 max width=15 edit.c:818:ABC MinA=0, minC=-1 edit.c:825:Margins left=0, right=0 edit.c:809:Font:Garamond height=24 ave width=8 max width=26 edit.c:812:otmEMSquare=14 edit.c:825:ABC MinA=-2, minC=-2 edit.c:832:Margins left=3, right=3 edit.c:809:Font:Lucida Sans Unicode height=23 ave width=10 max width=40 edit.c:812:otmEMSquare=16 edit.c:825:ABC MinA=-12, minC=-2 edit.c:832:Margins left=6, right=6 edit.c:809:Font:Marlett height=24 ave width=23 max width=24 edit.c:812:otmEMSquare=24 edit.c:825:ABC MinA=0, minC=0 edit.c:832:Margins left=0, right=0 edit.c:809:Font:Math1 Bold height=24 ave width=10 max width=34 edit.c:812:otmEMSquare=15 edit.c:825:ABC MinA=-2, minC=-10 edit.c:832:Margins left=2, right=6 edit.c:809:Font:Mathematica1 height=23 ave width=11 max width=35 edit.c:812:otmEMSquare=17 edit.c:825:ABC MinA=-2, minC=-11 edit.c:832:Margins left=3, right=6 edit.c:809:Font:Mathematica7 height=24 ave width=12 max width=24 edit.c:812:otmEMSquare=18 edit.c:825:ABC MinA=-1, minC=-1 edit.c:832:Margins left=0, right=1 edit.c:809:Font:Microsoft Sans Serif height=24 ave width=8 max width=34 edit.c:812:otmEMSquare=14 edit.c:825:ABC MinA=-1, minC=-2 edit.c:832:Margins left=0, right=0 edit.c:809:Font:MT Extra height=24 ave width=15 max width=24 edit.c:812:otmEMSquare=19 edit.c:825:ABC MinA=0, minC=-1 edit.c:832:Margins left=0, right=0 edit.c:809:Font:MT Symbol height=24 ave width=9 max width=23 edit.c:812:otmEMSquare=19 edit.c:825:ABC MinA=-3, minC=-4 edit.c:832:Margins left=3, right=4 edit.c:809:Font:Palatino Linotype height=24 ave width=8 max width=29 edit.c:812:otmEMSquare=13 edit.c:825:ABC MinA=-3, minC=-3 edit.c:832:Margins left=3, right=3 edit.c:809:Font:Symbol
Re: Wine fonts too big for their input fields.
Brian Vincent wrote: On 4/12/06, *Duane Clark* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I made the attached changes to the edit test. The results when run on Win2k are a bit strange (note that I only looked for the min in the first 1024 glyphs): edit.c:807:Font Microsoft Sans Serif first char=32, last=65532 edit.c:817:MinA=0, minC=0 edit.c:824:Left=0, right=0 Question: is there ever a situation where Left=0 and Right=0 is ok? If not, just bump it by 1. That's probably not the right solution, but this just seems like a corner case. Actually, those are the results on real Windows 2000. So they are (presumably) the correct values. Wine puts in margins, which it shouldn't in this case.
Re: Wine fonts too big for their input fields.
Huw D M Davies wrote: I had some fun with this a month or two ago. See the test_margins_font_change test and calc_min_margin_size in the actual code. The deal seems to be that for 'small' edit controls EC_USEFONTINFO results in no margin. 'Small' is currently defined to be smaller than the extents of the (four character) string '**', that's close but not quite how Windows does it. The fields in my case are 4 numbers. Another interesting thing is that when it does set margins they are often not symmetric left/right (although you tend to have to use larger font sizes to see this) - it's presumably using some pair of font metrics to set these and despite spending quite a while hunting I drew a blank. Now your problem could simply be that you don't have the font that the app wants to use in this edit control... What the right font should be is a bit of a mystery to me. From traces with the font and edit debug channels turned on, it appears to me the application was selecting MS Shell Dlg. So in my test app, I duplicated the selected font: afont = CreateFont(-11, 0, 0, 0, 400, 0, 0, 0, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, PROOF_QUALITY, DEFAULT_PITCH, MS Shell Dlg); SendMessage(g_hControl,WM_SETFONT,(WPARAM)afont,0); And indeed on Win2k, that produces an identical result to the Xilinx app. On Wine, the font appears to be similar but not identical. As far as the characters go, I can see that the '1' has an extra pixel to the right at the bottom. Most of the other characters appear to be pixel identical (though the '7' is rendered one pixel to the right of where it is on Win2k). The biggest difference though, is that the numbers are aliased on Wine, and not on Win2k. I'll see if I can figure out what fonts are actually being used; I don't really know offhand how to go about doing that.
Re: Wine fonts too big for their input fields.
Dan Kegel wrote: Duane Clark wrote: I also have an installer (for Xilinx) that exhibits this problem. I created a small application that creates a single line edit control (which is what the Xilinx installer uses). I notice that on Win2k the EM_GETMARGINS message returns zero for left and right messages, but on Wine it returns 2 for both margins. Would that be suitable for use as a conformance test? If I can figure out a bit more about what is going on and can come up with some new info, I'll try to add to the existing conformance test for margins.
Re: Wine fonts too big for their input fields.
Huw D M Davies wrote: MS Shell Dlg maps to either Microsoft Sans Serif or Tahoma depending on Windows version; the default wine.inf maps it to Tahoma so you should check whether you have tahoma.ttf installed. If in doubt a +font log will tell you what Wine picks for this font. In Win2k, it is picking MS Sans Serif, but in Wine configured for Windows 2000 it is picking Tahoma. And indeed, using my small test app, in Win2k with the Tahoma font, I can no longer type 4 numbers in the field, and the margins are both set to '3'. On the other hand, in both Win2k and WinXP, MS Shell Dlg seems to be mapping to MS Sans Serif. So is having Tahoma the default really the right thing to do?
Re: Wine fonts too big for their input fields.
Duane Clark wrote: ... Most of the other characters appear to be pixel identical (though the '7' is rendered one pixel to the right of where it is on Win2k). Actually, the '7' is correct. The problem is the '8' (I had typed 6789). Here are a couple of small images of the problem. The first, eights, shows the problem. The second, nines, is correct. On Win2k, the eights and nines with the Tahoma font render with the same spacing.
Re: Wine fonts too big for their input fields.
Duane Clark wrote: On the other hand, in both Win2k and WinXP, MS Shell Dlg seems to be mapping to MS Sans Serif. So is having Tahoma the default really the right thing to do? And to respond to myself once again, according to: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_4qcn.asp On Windows NT 4.0/2000/XP/Server 2003/Vista, both map to Unicode-based TrueType fonts. MS Shell Dlg uses Microsoft Sans Serif (which is distinct from MS Sans Serif)... MS Shell Dlg 2 simply uses the Tahoma font So perhaps we should be doing that?
Re: Wine fonts too big for their input fields.
Huw Davies wrote: I assume you mean Microsoft Sans Serif not MS Sans Serif. The former is a TrueType font (micross.ttf) the latter is a bitmap font (sserife.fon). Indeed it does look like[1] we should be using Microsoft Sans Serif for MS Shell Dlg at least for non-CJK locales. You are right, it is Microsoft Sans Serif. Testing more on Win2k shows that with Tahoma, the edit field sets margins that depend on the font size. Explicitely setting Microsoft Sans Serif gives me the correct font, and it is indeed True Type, but both margins remain zero regardless of the font size.
Re: Wine fonts too big for their input fields.
Huw Davies wrote: On Wed, Apr 12, 2006 at 11:28:21AM -0700, Duane Clark wrote: Testing more on Win2k shows that with Tahoma, the edit field sets margins that depend on the font size. Explicitely setting Microsoft Sans Serif gives me the correct font, and it is indeed True Type, but both margins remain zero regardless of the font size. Interesting, so to clarify, even a large edit control and a small Microsoft Sans Serif has a zero margin? Yep.
Re: Wine fonts too big for their input fields.
Huw Davies wrote: On Wed, Apr 12, 2006 at 12:26:07PM -0700, Duane Clark wrote: Huw Davies wrote: Interesting, so to clarify, even a large edit control and a small Microsoft Sans Serif has a zero margin? Yep. Fascinating. This will probably be a huge clue in working out exactly what Windows does here - unfortunately, at the moment, I have no idea what it means :-( Hmmm, well I found this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/editcontrols/editcontrols.asp where is says By default, the edit control margins are set just wide enough to accommodate the largest character horizontal overhang (negative ABC widths) for the current font being used in the edit control. I haven't quite figured out what that means, yet ;)
Re: Wine fonts too big for their input fields.
Duane Clark wrote:
Hmmm, well I found this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/editcontrols/editcontrols.asp
where is says By default, the edit control margins are set just wide
enough to accommodate the largest character horizontal overhang
(negative ABC widths) for the current font being used in the edit control.
I haven't quite figured out what that means, yet ;)
I made the attached changes to the edit test. The results when run on
Win2k are a bit strange (note that I only looked for the min in the
first 1024 glyphs):
edit.c:807:Font Verdana first char=32, last=64258
edit.c:817:MinA=-1, minC=-7
edit.c:824:Left=1, right=4
edit.c:807:Font Arial first char=32, last=65532
edit.c:817:MinA=-7, minC=-2
edit.c:824:Left=3, right=3
edit.c:807:Font Tahoma first char=32, last=65532
edit.c:817:MinA=-6, minC=-1
edit.c:824:Left=3, right=3
edit.c:807:Font Microsoft Sans Serif first char=32, last=65532
edit.c:817:MinA=0, minC=0
edit.c:824:Left=0, right=0
Index: dlls/user/tests/edit.c
===
RCS file: /home/wine/wine/dlls/user/tests/edit.c,v
retrieving revision 1.17
diff -u -p -r1.17 edit.c
--- dlls/user/tests/edit.c 22 Mar 2006 21:09:50 - 1.17
+++ dlls/user/tests/edit.c 13 Apr 2006 02:14:47 -
@@ -776,10 +776,14 @@ static void test_margins_font_change(voi
LOGFONT lf;
HFONT hfont, hfont2;
HDC hdc = GetDC(0);
+char the_font[]=Arial;
+TEXTMETRICW tm;
+HFONT old_font;
+ABC *lpabc;
-if(EnumFontFamiliesA(hdc, Arial, find_font_proc, 0))
+if(EnumFontFamiliesA(hdc, the_font, find_font_proc, 0))
{
-trace(Arial not found - skipping font change margin tests\n);
+trace(%s not found - skipping font change margin tests\n, the_font);
ReleaseDC(0, hdc);
return;
}
@@ -790,15 +794,34 @@ static void test_margins_font_change(voi
SetWindowPos(hwEdit, NULL, 10, 10, 1000, 100, SWP_NOZORDER | SWP_NOACTIVATE);
memset(lf, 0, sizeof(lf));
-strcpy(lf.lfFaceName, Arial);
+strcpy(lf.lfFaceName, the_font);
lf.lfHeight = 16;
lf.lfCharSet = DEFAULT_CHARSET;
hfont = CreateFontIndirectA(lf);
lf.lfHeight = 30;
hfont2 = CreateFontIndirectA(lf);
+
+hdc = GetDC(hwEdit);
+old_font = SelectObject(hdc, hfont);
+GetTextMetricsW(hdc, tm);
+trace(Font %s first char=%d, last=%d\n, the_font, tm.tmFirstChar, tm.tmLastChar);
+lpabc = HeapAlloc(GetProcessHeap(), 0, sizeof(ABC)*65536);
+if (GetCharABCWidthsW(hdc, tm.tmFirstChar, 1023, lpabc)) {
+int i, minA=20, minC=20;
+for (i=tm.tmFirstChar; i=tm.tmLastChar; i++) {
+if (lpabc[i].abcA minA)
+minA = lpabc[i].abcA;
+if (lpabc[i].abcC minC)
+minC = lpabc[i].abcC;
+}
+trace(MinA=%d, minC=%d\n, minA, minC);
+}
+SelectObject(hdc, old_font);
+ReleaseDC(hwEdit, hdc);
SendMessageA(hwEdit, WM_SETFONT, (WPARAM)hfont, 0);
font_margins = SendMessage(hwEdit, EM_GETMARGINS, 0, 0);
+trace(Left=%d, right=%d\n, LOWORD(font_margins), HIWORD(font_margins));
ok(LOWORD(font_margins) != 0, got %d\n, LOWORD(font_margins));
ok(HIWORD(font_margins) != 0, got %d\n, HIWORD(font_margins));
Re: Wine fonts too big for their input fields.
Tony Lambregts wrote: We now have at least three bugs[1] where the program will not accept the all the characters that are required if we do not use native fonts. The latest bug report was reported just today and the reporter resolved the bug as FIXED when he used Native fonts. So I have a couple of questions. Should we consider using native fonts a FIX or is it just a workaround? Or in other words can we fix our built in fonts to fix this. I also have an installer (for Xilinx) that exhibits this problem. I created a small application that creates a single line edit control (which is what the Xilinx installer uses). I notice that on Win2k the EM_GETMARGINS message returns zero for left and right messages, but on Wine it returns 2 for both margins. From a trace, the margins are getting set to 2 in EDIT_WM_SetFont(), with the call: EDIT_EM_SetMargins(es, EC_LEFTMARGIN | EC_RIGHTMARGIN, EC_USEFONTINFO, EC_USEFONTINFO, FALSE); Commenting out that single line makes the Xilinx installer work fine. Not that it is the correct fix ;)
Re: Wine tarball patched with DDraw/DX7 over WineD3D patches
Alexander N. Sørnes wrote: I have made a tarball with Wine CVS patched with the DirectDraw/DirectX... Your emails are not showing up on the list for awhile because you are not subscribed to wine-devel, at least not as alexsornes--at--yahoo.no. In that case, the email has to await moderation, and I at least am not checking them at 3AM my time ;) If you don't want postings sent to you (it looks like you might be reading the list via Google?) then go ahead and subscribe anyway. Once you are subscribed, you will have a personal preferences settings (it should be described in the welcome message). Turn off email delivery. Now your postings should show up on the list quickly.
Re: Wine release 0.9.7
Xtramind Autoresponder wrote: Sehr geehrte Damen und Herren, Herr Holger Stenzhorn ist nicht mehr im operativen Geschaeft der Xtramind Technologies GmbH taetig. Could someone tell me if that means he no longer works there? If so, I'll remove this email from the list.
Re: [winecfg] add sound driver test
Vincent Béron wrote: Le mer 16/11/2005 à 18:47, Robert Reif a écrit : What are the down sides of using a large wave file? A larger download size for the source/binary archives. 3MB is about 30% of the source package. Perhaps make downloading the file optional. Have the test check for the presence of the wav file in a specific location. If it is not present, the test is not run, and perhaps a message is printed out mentioning where the wav file can be obtained. Then only those who are interested in running the test need to bother downloading it.
Re: build errors
Michael Stefaniuc wrote: Phil Krylov wrote: On Mon, 26 Sep 2005 22:53:18 -0300 Marcelo Duarte [EMAIL PROTECTED] wrote: To fix the problem for me, instead of clean, I__d do the folowing command in wine tree: rm */*/*.spec.* Thanks, it works. But isn't make clean supposed to do this job? Yes and it would have worked if you have done the make clean before the cvs update. I know for sure I did make distclean a few days ago, and it did not work. I cannot swear that I tried make clean, but I think I did. The problem is specifically with the *.spec.c files that were left around and needed to be deleted. They were not deleted by make distclean.
Re: listview crash fix
Dimi Paun wrote: On Mon, 2005-09-26 at 03:29 +0200, Michael Jung wrote: Sorry, I'm currently on vacation in Peru and won't be able to test this for the next three weeks. It's OK, I guess it can wait until you come back, or maybe Phil can take it for a spin in the meantime. It seems to fix the problem for me.
Re: fix scollbar off by one error
Andreas Mohr wrote: Hi, On Mon, Sep 26, 2005 at 05:08:09PM +0530, Vijay Kiran Kamuju wrote: Changelog --- fix scrollbar off by one error (bug 765) r = *rect; if( vertical ) -r.bottom = r.top + arrowSize; +r.bottom = (r.top++) + arrowSize; else -r.right = r.left + arrowSize; +r.right = (r.left++) + arrowSize; Are you sure this is what you want? This will increment r.top and r.left, too! Even if it is exactly what you intend it to do, then this code is still confusing and should instead use more explicit notation. I don't think the patch is right. In many cases that I see, the scroll bars were already drawn correctly. Adding this patch makes them incorrect. For example, look at any listview (like a file dialog) with scrollbars. So I think that some more investigation is needed to see why they are drawn incorrectly in only certain cases.
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
Phil Krylov wrote: Hi Michael, On Thu, 8 Sep 2005 23:10:18 +0200 Michael Jung [EMAIL PROTECTED] wrote: Wouldn't it be enough to call notify_click after notify_itemactivate? I've attached a modification of your patch, which does just this. Seems to work fine for me. Probably, but what if some apps depend on order in which these notifications are sent? (assuming we already send them in the right order) Comparing the Listview control spy on Wine and Win2k, the notifications appear to be in the correct order in Wine: NM_RELEASEDCAPTURE NM_DBLCLK LVN_ITEMACTIVE
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
Duane Clark wrote: As of the current CVS, the problem seems to have disappeared for me. It is not clear to me what patch fixed it. Oops, spoke too soon. Still there.
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
Michael Jung wrote: On Monday 29 August 2005 18:09, Duane Clark wrote: I am seeing it now, using winecfg and browsing to Add application... in the Applications tab. And this entirely within wine drives. Are you saying you are not using the unix filesystem namespace and you are seeing the crash anyway? As of the current CVS, the problem seems to have disappeared for me. It is not clear to me what patch fixed it.
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
Michael Jung wrote: On Monday 29 August 2005 18:09, Duane Clark wrote: I am seeing it now, using winecfg and browsing to Add application... in the Applications tab. And this entirely within wine drives. Are you saying you are not using the unix filesystem namespace and you are seeing the crash anyway? It is a unix filesystem, but within a mapped wine drive. That is, I started winecfg from the fake drive C:, and navigated within drive C:
Re: Need help debugging a memory corruption bug in shfldr_unixfs.c
Phil Krylov wrote: On Fri, 26 Aug 2005 22:10:16 +0200 Michael Jung [EMAIL PROTECTED] wrote: 2) Did other people see this bug already? Yes, I confirm it. I am seeing it now, using winecfg and browsing to Add application... in the Applications tab. And this entirely within wine drives. The exact same crash though, always immediately after a double click on a folder. If I click once on a folder and click open, it works fine. So I suspect something being triggered by the double click. Backtrace: =1 0xe002 (0x4076ee80) 2 0x42028c55 abort+0x1d5 in libc.so.6 (0x4076efb0) 3 0x42021043 in libc.so.6 (+0x21043) (0x4076eff0) 4 0x40bf13be in comctl32 (+0x313be) (0x4076f074) 5 0x40bf906f notify_itemactivate+0x5f(infoPtr=0x40257e18, htInfo=0x4076f124) [/home/wine/dlls/comctl32/listview.c:791] in comctl32 (0x4076f104) 6 0x40bf614c LISTVIEW_LButtonDblClk+0x6c(infoPtr=0x40257e18, wKey=0x1, x=0x5, y=0x4d) [/home/wine/dlls/comctl32/listview.c:8100] in comctl32 (0x4076f150) 7 0x40bf7fa8 LISTVIEW_WindowProc+0x534(hwnd=0x10068, uMsg=0x203, wParam=0x1, lParam=0x4d0005) [/home/wine/dlls/comctl32/listview.c:9372] in comctl32 (0x4076f1b4) 8 0x40a5f6d3 WINPROC_wrapper+0x17 in user32 (0x4076f1d8) ...
Re: [Bug 3165] Patch available
Kevin DeKorte wrote: On Thursday 18 August 2005 03:24 am, Dripple wrote: Hi, I tested the patch submitted in http://bugs.winehq.org/show_bug.cgi?id=3165 Bugzilla page with Notes. Seems to fix the issue. Regards. Dripple. Well the patch does improve the cursor. I can now see it. Although it is only grey. It there any reason why the best cursor selection method always checks for bits == 1. What about color cursors? I don't really understand how the patch fixed things, but... Riven uses a bunch of color cursors (hands pointing various directions). Without the patch, only the standard pointer cursor was generated. This cursor appeared and disappeared normally (the cursor is supposed to disappear while some Quicktime clips are playing, and then reappear). With the patch, the color cursors reappeared and all are correct.
Re: Fix our waveout tests by adjusting for underrun conditions
Jeremy White wrote: On my VIA8237 sound card at work, the Wave tests for winmm have been failing for me with Alsa. Now, this patch Works For Me (TM), on both of my systems, but turning off the xrun mode seems like a big step to me; I'd appreciate testing by any concerned parties. This seems to cause severe problems for VirtualDub: http://virtualdub.sourceforge.net/ Here is the movie I am using: http://ftp.pub.cri74.org/pub/win9x/video/SampleMovie/ If you open and run the movie, it plays ok, including sound. But try clicking stop in the middle of playing. Or when the movie gets to the end, everything is stuck; it appears the program cannot tell that the movie has ended. This is on current CVS, with winealsa (I think, at least that is what is set in my config file), and RH9.
Re: Wine on Sparc
Chuck Hall wrote: Guess that means I need to learn autoconf and related stuff. I just want to make sure you understood that when Eric Frias wrote: ... Winelib only, of course, none of the emulation stuff is going to work on Sparc. What that means is that you won't be able to run Windows programs on your Sparc, unless of course you have the source code and recompile them. As long as you do realize that, then have fun...
Re: Benchmarking Wine againt XP
Tom Wickline wrote: Hello, Over the last couple weeks Ive been on a little benchmark craze and now that I'm done I thought I would share my results. All the benchmarks were run on my duel boot laptop under the same resolutions and I tried to choose the same settings in the test apps as well to keep everything as fair as possible. - I sent the results twice but our MODERATOR bounces the results! So if anyone is interested in this let me know or take it up with the MODERATOR! Because it was more than 1MB (which I mentioned it the rejection)! I will be happy to put it on the web if you don't have anyplace to put it.
Tooltips in own windows
I just wanted to make sure folks were aware of a tooltip regression, since I don't think I have seen mention of it here. It is easily seen in any Control Spy, but effects other apps (though not all, curiously). It manifests itself as a complete window border around tooltips. I have not tracked down where the regression occured, but could do so if no one else was looking at this.
Re: Datetime picker updown support
Rob Shearman wrote: This seems really wrong. You are destroying and creating the updown control on every size event?!?! That's really going to slow resizes down. Is there any evidence that the native version does it like this? No, I don't have evidence of that. On the other hand, it is unlikely the control will ever be resized, except once after creation. Looking through the messages that the updown control responds to, there are none that allow resizing that I can see. And while I have not verified this with Microsoft docs, it supposedly implements all documented functions (according to the header).
Re: Datetime picker updown support
Robert Shearman wrote: I have tested using ControlSpy Spy++ and indeed it isn't destroyed after each resize. Using SetWindowPos works for me. Can you make sure the app still works with the attached patch? Yep, that works fine.
Problems posting to wine-patches
Sorry about posting here, but... I seem to be having problems posting to wine-patches, and don't seem to be able to get through to Jeremy Newman either. Other people seem to be getting through okay. Am I the only one? Any ideas why? I know they are not getting stuck in the moderation queue; they seem to be disappearing without a trace that I can find.
Re: flexible-mmap breaks application
Walt Ogburn wrote: On Thu, 10 Mar 2005, Uwe Bonnes wrote: Setting /proc/sys/vm/legacy_va_layout, like proposed by Ingo, lets the app finally run. To Mark Knecht: If you have a copy of jack_fst without the special memory allocation hack, you might try it and see if this suggestion makes any difference. Maybe this is the same memory allocation issue. I don't think it is the same problem. Jack_fst had the problem on my RH9, kernel 2.4 system.
Re: flexible-mmap breaks application
Mike Hearn wrote: On Thu, 10 Mar 2005 19:15:34 +0100, Uwe Bonnes wrote: However nothing seems to have happened with regard to that problem until now. Could we revive that discussion? I think somebody needs to write a patch and send it to the kernel guys. What has to be done is fairly well defined (or at least, seems that way to me). Actually that is what Uwe did. I supplied a test to him demonstrating the problem, and he found the bug in the kernel, and sent the patch to fix it. By the way, this is related to http://www.winehq.org/hypermail/wine-devel/2003/08/0522.html
Re: flexible-mmap breaks application
Duane Clark wrote: Mike Hearn wrote: On Thu, 10 Mar 2005 19:15:34 +0100, Uwe Bonnes wrote: However nothing seems to have happened with regard to that problem until now. Could we revive that discussion? I think somebody needs to write a patch and send it to the kernel guys. What has to be done is fairly well defined (or at least, seems that way to me). Actually that is what Uwe did. I supplied a test to him demonstrating the problem, and he found the bug in the kernel, and sent the patch to fix it. By the way, this is related to http://www.winehq.org/hypermail/wine-devel/2003/08/0522.html Ugg, sorry. I was responding to the wrong thing. Please ignore this really dumb comment.
Fwd: Invitation to the mediation manual
Oops, I inadvertently deleted this from the queue, sorry. Robert Schuster wrote: Dear Wine developers, I wrote some guidelines that should help FOSS projects getting more lively and lowering the barrier for new developers to join. You can find them in form of a small manual here http://projects.mi.fu-berlin.de/w/bin/view/SE/ThesisFOSSIMMediationManual. These ideas are the result of work for my bachelor thesis and have been used successfully at the GNU Classpath project. If the topic is of interest to you, I would be happy to receive criticism and comments concerning the manual or the general idea. For further discussion I have set up a mailing-list (use http://lists.spline.inf.fu-berlin.de/mailman/listinfo/mediation_manual to subscribe or [EMAIL PROTECTED] to post unsubscribed). Please send your feedback to this list but if you have reasons to contact me directly then just reply to this mail. In case you answer to your project's mailing list please CC me. Best regards Robert Schuster
Re: mmtimer resolution question
Jeremy White wrote: When did that regression first start? The mmtime and ntdll/sync.c code has been this way since late last fall. I'll just mention that, assuming you are referring to this patch: http://cvs.winehq.org/patch.py?id=14198 it also causes a regression in Myst. Though I am not convinced the fault is in the patch, rather than the patch exposing some other problem. The Yield is, imho, correct, except that it exposes the fact that we don't correctly implement Windows priority schemes. That can create nasty conditions. But I wonder if something else changed that is causing this. I'm particularly surprised to find it on a 2.4 kernel; the 2.4 kernel quanta was ~ 40 ms, which made Linux a bit less sensitive to cpu hogging threads. Unfortunately, Myst appears to only work under Wine with rather old kernels. It works fine for me on RH7.3, kernel 2.4.18, as long as I back out that mmtime patch. But Myst fails to work on RH9, kernel 2.4.20, for reasons unrelated to the mmtime patch. However, it fails after the point where the above patch causes the regression (in the intro Quicktime sequence). So even on later kernels, Myst might be a good testbench, though I have not tried a later kernel. Surely everyone has an old copy of Myst around somewhere ;) It was discussed a bit more here: http://www.winehq.org/hypermail/wine-users/2005/01/0260.html
Re: Problems with wine-patches
Mike Hearn wrote: On Thu, 10 Feb 2005 13:14:19 +0100, Jonathan Ernst wrote: I have the same problem when I send patches that are too big. They never appear in wine-patches. I expect they're being held in the moderation queue, normally they'll be released shortly when that happens but you can always compress the patch or post a URL to it if it's really too big. Better way is to make the patches smaller of course ... Well, when I came in this morning for moderation, the wine-patches queue was empty. But it was the only one; rather unusual. So either someone else cleared out only the wine-patches queue, or wine-patches might indeed be broken.
Re: Problems with wine-patches
Jeremy White wrote: Tom asked me to let his opengl patch trough, so I did that list. Is it just a problem of upping the default 40K size? afair, that's the mailman default. Perhaps we should just raise it. The wine-patches list is 80KB, but the others are 40. The main reason I have left them that size is that occasionally someone's computer gets infected and starts spamming the list with legitimate from addresses. The size limit occasionally helps block them. I don't think the limit is causing problems; most people on the list understand how it works. Though I have no idea what happened to Paul's posts.
Re: Message Notify
M.hearn did not write: A virus It appears to me that you have not used this email address (m.hearn.at.signal.QinetiQ.com) for a long time, at least not for sending to this list. If it is no longer in use, would you mind unsubscribing it to eliminate at least this one source of viruses?
Re: No RichEdit20A window class
Krzysztof Foltman wrote: Mike McCormack wrote: ... so long as you are the sole author. That's where part of the problem is: as long as someone sends me just a Ctrl-arrow patch, I can always be suspected of stealing that patch. It puts me in a very uncomfortable position. Perhaps a suggestion... ask that for some period of time, people who submit patches against your code do so under a BSD or X11 license. Wine itself was under an X11 style license for quite a few years, so that probably won't scare too many people off. Be specific (and reasonable) about the period of time, though.
Re: Developer Cheatsheet formatting...
Dan Kegel wrote: http://www.winehq.com/site/developer-cheatsheet is 1.5 times as wide as my screen in Firefox and Mozilla. Seems like it needs a bit of adjustment... Yes, I frankly think that is a bug in Mozilla/Firefox, but it has been that way for a very long time. The width in the case of the above link is being caused by the string in the +relay section beginning: RtlEnterCriticalSection;RtlLeaveCriticalSection;... To make it display at a more reasonable width, the string needs to be shortened or split up.
Re: [LOSTWAGES] Re: Developer Cheatsheet formatting...
Brian Vincent wrote: On Mon, 15 Nov 2004 08:37:18 -0800, Duane Clark [EMAIL PROTECTED] wrote: Yes, I frankly think that is a bug in Mozilla/Firefox, but it has been that way for a very long time. The width in the case of the above link Actually, it will render that way in every browser because the line has no break in it. Attached patch is probably the easiest way to fix it. I think we can assume anyone reading this doc is intelligent enough to put it all on one line. -Brian Well, okay maybe bug is the wrong word. But I see it all the time, for example when looking at msdn.microsoft.com, and it is rather annoying. It seems to me that just because there is one object on the page that is wider than the browser window, that is no reason to render everything that wide. Then again, I'm not the one writing the code... :-)
Re: Miscellaneous UI Fixes
William Poetra Yoga H wrote: OK, but the size patch in menu.c and nonclient.c are actually a fix for a thing: the size of the menubar. So I think it should be sent in one mail, right? Then yes, they would be one email. While it is not real important, I think it is a little clearer in that case to combine the patches into a single attachment. You can do cvs diff dlls/user/menu.c windows/nonclient.c menu.diff and they will be combined for you.
Re: Miscellaneous UI Fixes
William Poetra Yoga H wrote: --- Dimitrie O. Paun [EMAIL PROTECTED] wrote: On Sat, Nov 06, 2004 at 10:14:36PM -0800, William Poetra Yoga H wrote: Reasons for sending the patch: 1. all at once: the patches are a group of related fixes (as said in the website). 2. one file per message: I don't know :-P 3. one file per item: it's one fix per patch (as said in the website) 3, as documented on the website, is the preferred method. Otherwise, we wouldn't have documented it as such :) -- Dimi. You mean 5 mails with one patch each? Or one mail with 5 diff files? Just to be clarify a bit more, a patch fixes one thing, or several closely related things. A patch can contain changes to multiple files, when multiple files need to be changed to fix something. After applying a single patch, Wine should be able to be recompiled and run, presumably with whatever was being fixed now working. In the case of your original email, where there is one attachment for menu size and one for nonclient size, they probably should be sent in separate patches/emails.
Re: Add time zone to TZ_Info
Roger Olson wrote:
RCS file: /home/wine/wine/dlls/ntdll/time.c,v
retrieving revision 1.51
diff -u -u -r1.51 time.c
--- dlls/ntdll/time.c 22 Oct 2004 19:54:17 - 1.51
+++ dlls/ntdll/time.c 31 Oct 2004 21:18:46 -
@@ -105,6 +105,9 @@
{AKDT,
{'A','l','a','s','k','a','n',' ','S','t','a','n','d','a','r','d',' ','T',
'i','m','e','\0'}, 480, 1},
+ {PST,
+{'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T',
+ 'i','m','e','\0'}, 480, 0},
{PDT,
{'P','a','c','i','f','i','c',' ','S','t','a','n','d','a','r','d',' ','T',
'i','m','e','\0'}, 420, 1},
Hmm... I don't know if anything actually uses the names, but I doubt
these are right. PDT would normally be referred to as Pacific Daylight
Time. Any chance of getting you to add some tests for these?
Re: Add time zone to TZ_Info
Roger wrote: I agree that PDT should say Pacific Daylight Time but whoever wrote this section refered to both ..DT and ..ST as Standard Time for some good reason.I assumed so I followed convention. It came up in an app I was running as a fixme since we switched to std time today and is used by TIME_GetTZAsStr(). If it appears beneficial, I'll be happy to change all the ..DT references to Daylight Time and resubmit. Not quite every place; MEST says daylight. It appears to me that the only place this is used is the function TIME_GetTZAsStr(), which appears to only be used in RtlQueryTimeZoneInformation(). So the question would be, what does that function return on Windows (and perhaps, does any program care).
Re: I'm getting two of every email post
Kevin R. Casper wrote: I must have done something wrong when I signed up for this list as an email list. I'm getting two of every message. Any idea what's wrong? If you send directly to me full headers of two of the posts, I could probably figure it out. Or take a look at the full headers and see who/how they are being sent to.
Re: Thread not detaching?
Alexandre Julliard wrote: BTW there is no call to MsgWaitForMultipleObjectsEx in X11DRV_SetWindowPos. Is that something you added, or is the debugger smoking crack? Oops :-[ I had added that so long ago I forgot about it. I took that out and the problem disappeared... sorry 'bout that. I'll definitely need to remember to remove customizations when debugging.
Re: Thread not detaching?
Alexandre Julliard wrote: Duane Clark [EMAIL PROTECTED] writes: err:ntdll:RtlpWaitForCriticalSection section 0x403f2580 syslevel.c: Win16Mutex wait timed out in thread 000b, blocked by 000a, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x408849c0 ../../windows/user.c: USER_SysLevel wait timed out in thread 000a, blocked by 000b, retrying (60 sec) It sounds like thread 000b is trying to get the Win16 lock while it holds the USER lock, this is a bug. You should get a backtrace of that thread to find out which function is getting the locks in the wrong order. Hmm... I'll have to look at this awhile to see if I can make sense of it. Anyway, here is a backtrace, along with a relay trace of the last things happening on thread b. kotao:~ winedbg Wine-dbginfo process pid threads parent executable (all id:s are in hex) 0008 3 'F:\Setup.exe' Wine-dbgattach 8 In 32 bit mode. 0xe002: -- no code accessible -- Wine-dbginfo threads process tid prio (all id:s are in hex) 0008 (D) F:\Setup.exe 000b0 == 000a0 00090 Wine-dbgbt 11 Backtrace: =1 0xe002 (0x40d76c58) 2 0x400a1f2f NTDLL_wait_for_multiple_objects+0x107(count=0x0, handles=0x0, flags=0x8, timeout=0x40d76d10) [/home/wine/dlls/ntdll/sync.c:587] in ntdll (0x40d76cf4) 3 0x400a092d usr1_handler+0x39(__signal=0xa, __context=0x33) [/home/wine/dlls/ntdll/signal_i386.c:1160] in ntdll (0x40d76d1c) 4 0x400488f8 __restore in libpthread.so.0 (0x410a55a8) 5 0x400a1f2f NTDLL_wait_for_multiple_objects+0x107(count=0x1, handles=0x410a5694, flags=0xc, timeout=0x410a56ac) [/home/wine/dlls/ntdll/sync.c:587] in ntdll (0x410a5644) 6 0x400a1f84 NtWaitForMultipleObjects+0x50(count=0x1, handles=0x410a5694, wait_all=0x0, alertable=0x0, timeout=0x410a56ac) [/home/wine/dlls/ntdll/sync.c:605] in ntdll (0x410a566c) 7 0x400a1fb9 NtWaitForSingleObject+0x25(handle=0x78, alertable=0x0, timeout=0x410a56ac) [/home/wine/dlls/ntdll/sync.c:615] in ntdll (0x410a568c) 8 0x40083866 RtlpWaitForCriticalSection+0x106(crit=0x403f2580) [/home/wine/dlls/ntdll/critsection.c:250] in ntdll (0x410a5714) 9 0x40083a85 RtlEnterCriticalSection+0x65(crit=0x403f2580) [/home/wine/dlls/ntdll/critsection.c:354] in ntdll (0x410a572c) 10 0x40372bf6 _EnterSysLevel+0x6e(lock=0x403f2580) [/home/wine/dlls/kernel/syslevel.c:111] in kernel32 (0x410a5748) 11 0x40372f92 RestoreThunkLock+0x2a(mutex_count=0x2) [/home/wine/dlls/kernel/syslevel.c:228] in kernel32 (0x410a5760) 12 0x407fb4ca MsgWaitForMultipleObjectsEx+0x13e(count=0x0, pHandles=0x0, timeout=0x0, mask=0x0, flags=0x0) [/home/wine/dlls/user/../../windows/message.c:599] in user32 (0x410a58f8) 13 0x40a59a23 X11DRV_SetWindowPos+0x27(winpos=0x410a5994) [/home/wine/dlls/x11drv/winpos.c:888] in x11drv (0x410a5988) 14 0x40811524 SetWindowPos+0xe4(hwnd=0x10024, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x57) [/home/wine/dlls/user/../../windows/winpos.c:1210] in user32 (0x410a59c0) 15 0x40a5a5f8 .L516+0x70 in x11drv (0x410a5a08) 16 0x40810a11 ShowWindow+0x65(hwnd=0x10024, cmd=0x5) [/home/wine/dlls/user/../../windows/winpos.c:852] in user32 (0x410a5a24) 17 0x4080c18f WIN_CreateWindowEx+0x51f(cs=0x410a5c20, classAtom=0xc007, type=0x1) [/home/wine/dlls/user/../../windows/win.c:1205] in user32 (0x410a5af4) 18 0x4080c65d CreateWindowEx16+0x16d(exStyle=0x4, className=0x408b81f4, windowName=0x4026281b, style=0x50020080, x=0x43, y=0x13, width=0x113, height=0x35, parent=0x22, menu=0x65, instance=0x1307, data=0x0) [/home/wine/dlls/user/../../windows/win.c:1288] in user32 (0x410a5c5c) 19 0x40824ade DIALOG_CreateControls16+0x11a(hwnd=0x10022, template=0x40262896, dlgTemplate=0x410a5d10, hInst=0x1307) [/home/wine/dlls/user/dialog16.c:171] in user32 (0x410a5cd8) 20 0x40825172 DIALOG_CreateIndirect16+0x272(hInst=0x1307, dlgTemplate=0x4026280c, owner=0x0, dlgProc=0x124f00ba, param=0x13670004, modal=0x0) [/home/wine/dlls/user/dialog16.c:421] in user32 (0x410a5d5c) 21 0x40825b6b CreateDialogIndirectParam16+0x3f(hInst=0x1307, dlgTemplate=0x402627f0, owner=0x0, dlgProc=0x124f00ba, param=0x13670004) [/home/wine/dlls/user/dialog16.c:764] in user32 (0x410a5d88) 22 0x40825ade CreateDialogParam16+0x86(hInst=0x1307, dlgTemplate=0x1d4c, owner=0x0, dlgProc=0x124f00ba, param=0x13670004) [/home/wine/dlls/user/dialog16.c:751] in user32 (0x410a5db4) 23 0x407df247 __wine_user_exe_CallFrom16_p_word_wtwll+0x3f(proc=0x40825a58, args=0x4025ab4e) [user.exe.spec.c:1058] in user32 (0x410a5dd8) 24 0x403819f8 __wine_call_from_16_word+0x94 in kernel32 (0x410a5e08) 25 0x125f:0x37d0 (0x1267:0x5078) 26 0x125f:0x0a48 (0x1267:0x5178) 27 0x0012:0x6700 (0x1267:0x5192) 28 0x0012:0x6636 (0x1267:0x51a0) 29 0x0012:0x660e (0x1267:0x) Wine-dbgbt 10 Backtrace: 1 0xe002 (0x40d74c58) 2 0x400a1f2f NTDLL_wait_for_multiple_objects+0x107(count=0x0, handles=0x0, flags=0x8, timeout=0x40d74d10) [/home/wine/dlls/ntdll
Thread not detaching?
I have an application that is hanging, apparently because a thread is not detaching: 000a:Call kernel32.ExitThread() ret=4077907f 000a:Call ntdll.LdrShutdownThread() ret=40376278 000a:Call PE DLL (proc=0x40ea2024,module=0x40ea Lmidimap.drv,reason=THREAD_DETACH,res=(nil)) 000a:Ret PE DLL (proc=0x40ea2024,module=0x40ea Lmidimap.drv,reason=THREAD_DETACH,res=(nil)) retval=1 000a:Call PE DLL (proc=0x40d4a02c,module=0x40d4 Lmsacm.drv,reason=THREAD_DETACH,res=(nil)) 000a:Ret PE DLL (proc=0x40d4a02c,module=0x40d4 Lmsacm.drv,reason=THREAD_DETACH,res=(nil)) retval=1 000a:Call PE DLL (proc=0x40d1405c,module=0x40d1 Lwineoss.drv,reason=THREAD_DETACH,res=(nil)) 000a:Ret PE DLL (proc=0x40d1405c,module=0x40d1 Lwineoss.drv,reason=THREAD_DETACH,res=(nil)) retval=1 000a:Call PE DLL (proc=0x407dc1d8,module=0x407d Luser32.dll,reason=THREAD_DETACH,res=(nil)) 000a:Call ntdll.RtlAllocateHeap(401e,,0080) ret=4080a08c 000a:Ret ntdll.RtlAllocateHeap() retval=4026cfd8 ret=4080a08c err:ntdll:RtlpWaitForCriticalSection section 0x403f2580 syslevel.c: Win16Mutex wait timed out in thread 000b, blocked by 000a, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x408849c0 ../../windows/user.c: USER_SysLevel wait timed out in thread 000a, blocked by 000b, retrying (60 sec) The place it is happening is in WIN_GetPtr(), in the call to USER_Lock(). It is getting to RtlpWaitForCriticalSection() and hanging forever: 000a:Call PE DLL (proc=0x407dc1d8,module=0x407d Luser32.dll,reason=THREAD_DETACH,res=(nil)) trace:ntdll:RtlEnterCriticalSection Here trace:ntdll:RtlEnterCriticalSection finished SpinCount trace:ntdll:RtlEnterCriticalSection done trace:ntdll:RtlEnterCriticalSection Here trace:ntdll:RtlEnterCriticalSection finished SpinCount trace:ntdll:RtlEnterCriticalSection done trace:win:WIN_DestroyThreadWindows Destroying windows 000a:Call ntdll.RtlAllocateHeap(401e,,0080) ret=4080a08c trace:ntdll:RtlEnterCriticalSection Here trace:ntdll:RtlEnterCriticalSection finished SpinCount trace:ntdll:RtlEnterCriticalSection done 000a:Ret ntdll.RtlAllocateHeap() retval=4026cff8 ret=4080a08c trace:win:WIN_DestroyThreadWindows Start trace:win:WIN_DestroyThreadWindows 0 : 0x10022 trace:win:WIN_IsCurrentThread here trace:win:WIN_GetPtr here trace:win:WIN_GetPtr 1 trace:syslevel:_EnterSysLevel (0x40885ae0, level 2): thread a count before 0 trace:ntdll:RtlEnterCriticalSection Here trace:ntdll:RtlEnterCriticalSection finished SpinCount trace:ntdll:RtlpWaitForCriticalSection Here err:ntdll:RtlpWaitForCriticalSection section 0x403f2580 syslevel.c: Win16Mutex wait timed out in thread 000b, blocked by 000a, retrying (60 sec) Any clues on what should be happening here?
Re: Thread not detaching?
Duane Clark wrote: I have an application that is hanging, apparently because a thread is not detaching: It might be worth mentioning that this is an installer and no windows have appeared yet.
Re: winecfg (was Re: W-A calls)
Joris Huizer wrote: Fine by me ;) where do I start then.. I can't find much on the winehq site about that (I found a http://sourceforge.net/projects/winecfg/ but it seems the last update was over a year ago..) What's there to do, how to... etc - kind find much documentation except for the fact it's mentioned as a Todo thing :-/ It appears that Mike has been doing a lot of work on this. http://www.winehq.org/hypermail/wine-devel/2004/09/0221.html So you probably first want to coordinate with him. I would start by running winecfg, and seeing what doesn't work, which is a lot. For example, on the very first tab, you can select a Windows Version, but changing the setting doesn't actually change anything (it should make/alter a registry entry). The winecfg code is in wine/programs/winecfg. A long discussion of things that are needed is in the thread starting: http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html In fact, you probably want to go to: http://www.winehq.org/hypermail/wine-devel/2004/08/index.html http://www.winehq.org/hypermail/wine-devel/2004/09/index.html And then search for all subjects containing winecfg. By the way, I really do like the look mentioned here: http://www.winehq.org/hypermail/wine-devel/2004/09/0220.html It is much improved over the current look. Hopefully that will become part of winecfg.
Re: W-A calls
Mike Hearn wrote: If you're just generally looking for things to do, W-A cleanup isn't the only task. You could help extend the test suite :) Or another possibility... since there is no longer a ~/.wine/config file installed, we really, really need some serious work on winecfg. That should be a fairly easy and self contained way to get into Wine.
Re: regression: listbox stays disabled in created dialog-window
Rein Klazes wrote:
I was too early, another problem popped up caused by this patch.
Un-maximized MDI child windows don't paint their non client area anymore
(I tried two MDI applications, both had it).
I don't know why that only showed up now, but I have a workaround that I
have been using for a long time on another MDI app with this problem,
and it seems to also fix the current problem with Pegasus.
Index: dlls/x11drv/winpos.c
===
RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v
retrieving revision 1.98
diff -u -r1.98 winpos.c
--- dlls/x11drv/winpos.c24 Aug 2004 18:49:34 - 1.98
+++ dlls/x11drv/winpos.c1 Sep 2004 16:00:19 -
@@ -1364,8 +1367,7 @@
if (!(win = WIN_GetPtr( hwnd ))) return;
-if ((win-dwStyle WS_VISIBLE)
-(win-dwStyle WS_MINIMIZE)
+if ((win-dwStyle WS_MINIMIZE)
(win-dwExStyle WS_EX_MANAGED))
{
int x, y;
@@ -1392,7 +1394,10 @@
WIN_SetStyle( hwnd, style );
WIN_ReleasePtr( win );
-SendMessageA( hwnd, WM_SHOWWINDOW, SW_RESTORE, 0 );
+/* The SW_SHOW is needed if WS_VISIBLE is false. It will trigger
+ X11DRV_ShowWindow, and pass the SW_SHOW parameter. Otherwise, it
+ does not hurt anything. */
+SendMessageA( hwnd, WM_SHOWWINDOW, SW_RESTORE, SW_SHOW );
SetWindowPos( hwnd, 0, rect.left, rect.top, rect.right-rect.left,
rect.bottom-rect.top,
SWP_NOZORDER | SWP_WINE_NOHOSTMOVE );
}
Re: regression: listbox stays disabled in created dialog-window
Rein Klazes wrote: Hi Duane. Unfortunately your patch does not change anything (that is cvs winpos.c + alexandre's patch + your patch). Maybe I did not explain clearly enough: these windows show alright but without painting the borders, caption, buttons etc. The defects also show in applications with a modern interface consisting of many floating/dockable/movable panes: no borders around the panes are painted. Oops, not enough coffee yet this morning. Actually, the problem I was having with Pegasus, that the patch attempts to fix, is with minimization. That is, I minimize and then attempt to restore Pegasus, and nothing shows up *except* the main window border (you don't have that?). Yes, I do also see the problem with the non-client areas of the internal windows.
Re: regression: listbox stays disabled in created dialog-window
Rein Klazes wrote: On Wed, 01 Sep 2004 10:02:43 -0700, you wrote: Oops, not enough coffee yet this morning. Actually, the problem I was having with Pegasus, that the patch attempts to fix, is with minimization. That is, I minimize and then attempt to restore Pegasus, and nothing shows up *except* the main window border (you don't have that?). Did you disable the option Place an Icon in the Windows System Tray under ToolsOptionsUser InterfaceReporting/Logging ? That does indeed fix it.
Re: developers-hints.diff
Ivan Leo Puoti wrote: I know, sorry about that, but in the wine-patches archives there appears to be an extra space amstream/ - MultiMedia Streams +atl/- Active Template Library avicap32/ - AVI capture window class but if I do the diffing on my pc I don't get this. But patching works with both your patch, that appears to have the extra space, but doesn't, and with my patch that doesn't appear to have an extra space. I have of what is going on. BTW the patch that I sent was edited manually, so had a missing space at every added line. It looks odd because the existing lines have tabs, but the added lines have 8 spaces instead.
Anyone writing COM tests?
Howdy, Debugging a problem I am having in COM (mentioned a few weeks ago), I think I know what the problem is but not where. So I figured some COM test would help me to understand how things should work. I was a bit surprised to see no COM tests, or at least I didn't find any in the ole* directories. So I figured if no one else is working on them, I might take a shot at it over the next few weeks/months. And maybe this would encourage some updates to the COM implementation.
Re: Anyone writing COM tests?
Jeroen Janssen wrote: I think writing (COM) tests is a great idea. I have 'hit' a few bumps in the road of wine COM in the past few weeks and I would appreciate it if I can help with writing (specific) testscenarios. It would be great to have a small 'com test framework' sample code to base specific tests upon. I'm wondering though if all can be build without problems : I'm used to VC6, but it would be better if things can be (cross) build with mingw and/or gcc + with winelib. I would be using mingw and gcc, since I don't have VC. It would certainly help to have someone else compiling on VC to make sure the code works there. Also generating proxy/stub code (without using midl) might be a problem at this point. I might try to getting an old copy of VC to get midl. It might be useful for tests comparing results with widl.
Re: Marshal bug
Mike Hearn wrote: What happens if you reinstall the app or reregister all the DLLs shipped with it (using regsvr32) ? Does that fix it ? Because of some reconfiguration on my end, I performed a new clean install in a fresh c: and fresh ~/.wine/config just a couple of days ago, with a CVS from then.
Re: Marshal bug
Mike Hearn wrote:
...
So you need to figure out why {402b4180-fa0c-40ee-ebf8-ee40f0ce5360} isn't
being registered, which may involve figuring out what it actually is :)
Okay, I'll see if I can make some sense out of that.
Good luck! If a more complete marshalling explanation would be useful, let
me know and I'll see what I can do in a few days.
There is no hurry, since it works fine if I back out the one patch. But
yes, I certainly would appreciate a more complete explanation.
Marshal bug
Howdy,
This patch:
http://www.winehq.org/hypermail/wine-cvs/2004/05/0283.html
causes a crash within Actel Designer (commercial FPGA design software).
Reverting the patch with current CVS fixes the application.
A trace and crash dump look like
wine /c/Actel/bin/designer.exe
trace:ole:DllMain 0x40ea 0x1 0x1
trace:ole:DllMain (0x4103,1,0x1)
trace:ole:OleInitialize ((nil))
trace:ole:CoInitializeEx ((nil), 2)
trace:ole:CoInitializeEx () - Initializing the COM libraries
trace:ole:RunningObjectTableImpl_Initialize ()
trace:ole:OleInitialize () - Initializing the OLE libraries
trace:ole:OLEClipbrd_Initialize ()
fixme:ole:CoRegisterMessageFilter stub
trace:ole:RegisterDragDrop (0x10040,0x41fc1ddc)
trace:ole:UuidCreate {8b881308-d111-11d8-8790-002078041c53}
trace:ole:__CLSIDFromStringA {A111826C-DB40-11d2-8D34-0008C7523E29} -
0x4073f218
trace:ole:WINE_StringFromCLSID
0x4073f218-{A111826C-DB40-11D2-8D34-0008C7523E29}
trace:ole:CoLoadLibrary (LC:\\Actel/bin/comdesign.dll, 0)
trace:ole:CoCreateFreeThreadedMarshaler (0x41fc6a60 0x41fc6a74)
trace:ole:__CLSIDFromStringA {4B95E7E3-6EC5-11D2-BA21-0008C7A01E5D} -
0x4073f870
trace:ole:WINE_StringFromCLSID
0x4073f870-{4B95E7E3-6EC5-11D2-BA21-0008C7A01E5D}
trace:ole:CoLoadLibrary (LC:\\Actel/bin/timingui.dll, 0)
trace:ole:__CLSIDFromStringA {F70AA652-C79A-11d2-BA4B-0008C7A01E5D} -
0x4073f66c
trace:ole:WINE_StringFromCLSID
0x4073f66c-{F70AA652-C79A-11D2-BA4B-0008C7A01E5D}
trace:ole:CoLoadLibrary (LC:\\Actel/bin/taiming.dll, 0)
err:toolbar:TOOLBAR_GetImageListForDrawing bitmap for ID 0, index 0 is
not valid, number of bitmaps in imagelist: 0
err:toolbar:TOOLBAR_GetImageListForDrawing bitmap for ID 0, index 0 is
not valid, number of bitmaps in imagelist: 0
err:toolbar:TOOLBAR_GetImageListForDrawing bitmap for ID 0, index 0 is
not valid, number of bitmaps in imagelist: 0
err:toolbar:TOOLBAR_GetImageListForDrawing bitmap for ID 0, index 0 is
not valid, number of bitmaps in imagelist: 0
trace:ole:CoMarshalInterThreadInterfaceInStream
({27a4f276-6452-11d2-ba1d-0008c7a01e5d}, 0x43932bf8, 0x4073f9e8)
trace:ole:CoMarshalInterface (0x402b4180,
{27a4f276-6452-11d2-ba1d-0008c7a01e5d}, 0x43932bf8, 3, (nil), 0)
trace:ole:_StubMgrThread Stub Manager Thread starting on
(\\.\pipe\WINE_OLE_StubMgr_0008)
trace:ole:CoCreateFreeThreadedMarshaler (0x41fc72f0 0x41fc7348)
trace:ole:IiFTMUnknown_fnQueryInterface
trace:ole:FTMarshalImpl_AddRef
fixme:ole:FTMarshalImpl_GetUnmarshalClass (), stub!
fixme:ole:FTMarshalImpl_MarshalInterface (), stub!
trace:ole:FTMarshalImpl_Release
trace:ole:CoInitializeEx ((nil), 2)
trace:ole:CoGetInterfaceAndReleaseStream (0x402b4180,
{27a4f276-6452-11d2-ba1d-0008c7a01e5d}, 0x46cb413c)
trace:ole:CoUnmarshalInterface
(0x402b4180,{27a4f276-6452-11d2-ba1d-0008c7a01e5d},0x46cb413c)
trace:ole:WINE_StringFromCLSID
0x46cb4014-{402B4180-FA0C-40EE-EBF8-EE40F0CE5360}
trace:ole:CoGetClassObject
CLSID: {402b4180-fa0c-40ee-ebf8-ee40f0ce5360},
IID:{0001---c000-0046}
warn:ole:CoGetClassObject class {402B4180-FA0C-40EE-EBF8-EE40F0CE5360}
not registred
trace:ole:WINE_StringFromCLSID
0x46cb4014-{402B4180-FA0C-40EE-EBF8-EE40F0CE5360}
trace:ole:WINE_StringFromCLSID
0x46cb4014-{402B4180-FA0C-40EE-EBF8-EE40F0CE5360}
fixme:ole:CoCreateInstance no classfactory created for CLSID
{402b4180-fa0c-40ee-ebf8-ee40f0ce5360}, hres is 0x80040150
fixme:ole:CoUnmarshalInterface Failed to create instance of unmarshaller
{402b4180-fa0c-40ee-ebf8-ee40f0ce5360}.
wine: Unhandled exception (thread 000d), starting debugger...
fixme:console:SetConsoleCtrlHandler (0x4066a5e0,1) - no error checking
or testing yet
WineDbg starting on pid 0x8
Unhandled exception: page fault on read access to 0x in 32-bit
code (0x6051b58f).
In 32 bit mode.
err:dbghelp_msc:pdb_process_file -Unable to peruse .PDB file
e:\users\ChiJ\objs\pc_4.0.3.5\timingui\msobj\timingui.pdb
0x6051b58f: movl0x0(%eax),%ecx
Wine-dbgbt
Backtrace:
=1 0x6051b58f (0x46cb4160)
2 0x40374e57 THREAD_Start+0xef(ptr=0x402b3dd8) [thread.c:107] in
kernel32 (0x46cb4234)
3 0x400a2f23 start_thread+0x147(info=0x402b05e0) [thread.c:199] in
ntdll (0x46cb4a70)
4 0x40043484 start_thread+0x64 in libpthread.so.0 (0x46cb4a94)
5 0x420df147 __clone+0x57 in libc.so.6 (0x)
Wine-dbg
Temporary moderator needed
Howdy, Someone is needed for the period June 30-July 5 to handle moderation of the Wine lists. If you are willing to do it, please email me off list. Thanks.
Re: OT: Issue with list unsubscribe
Gregory Hicks wrote: Guys, Sorry for this post. I have been trying to get off this list, to no avail. I get a reply stating that the user is unknown. Wish it was easy to fix. I tried via the web site, can we get the list admin to check for any mail addresses from the ihug.com.au domain, it may be a variant (eg [EMAIL PROTECTED]) instead of the regular one. You are off the list now.
Re: segfault at startup
Morten Welinder wrote: ... One more thing: about 1 in 5 runs it turns out that wine does start. Never under strace, though. /me smells a race condition. I'll just add a me too to that one. I have not tried putting numbers to it, so I don't know whether it is 1 in 5. But I have already gotten accustomed to just rerunning a program that doesn't start up. This on RH9.
Re: Additional downloads for winehq
Ivan wrote: ... and the link to the dcom95 download page is just too long. It's http://www.microsoft.com/downloads/details.aspx?familyid=d7a4de78-81a9-4db7-beb6-84ff99342172displaylang=en and we want to keep the error log short. You could use: http://tinyurl.com/ which I used to turn the above URL into: http://tinyurl.com/2h4fu
Re: Printing problem; RHEL3U1 (CUPS) with 20031118
Bill Medland wrote: On May 2, 2004 09:06 am, Duane Clark wrote: Bill Medland wrote: On May 1, 2004 08:50 am, Duane Clark wrote: Thanks for the continued help, Duane Oops, but I had not noticed we were continuing it on wine-devel. Let's move to wine-users, please.
Re: Printing problem; RHEL3U1 (CUPS) with 20031118
Bill Medland wrote: On May 1, 2004 08:50 am, Duane Clark wrote: Bill Medland wrote: (Yes, I know 20031118 is a little old) Anyone any ideas what is going on here or any simple tests I can do? I am trying to get our company's software running on Red Hat Enterprise Linux 3 Update 1. I am using the wine-20031118-1rh8winehq.i686.rpm I am printing to a SMB printer elsewhere on the computer. I can print the test page from the printconfgui I can print a text file from the command line (lp /etc/passwd) Wine expects to print with lpr and the corresponding syntax. Can you print on the command line with lpr instead of lp? Yes Then the next test is that Wine expects to be able to print a postscipt file via lpr, so the next thing to try is printing a postscript file via lpr. Hmm, and is printconfgui something other than CUPS, I take it? You might want to post the contents of /etc/printcap, windows/win.ini, and the sections of ~/.wine/system.reg that begin with: [System\\CurrentControlSet\\Control\\Print\\Printers
Re: Printing problem; RHEL3U1 (CUPS) with 20031118
Bill Medland wrote: (Yes, I know 20031118 is a little old) Anyone any ideas what is going on here or any simple tests I can do? I am trying to get our company's software running on Red Hat Enterprise Linux 3 Update 1. I am using the wine-20031118-1rh8winehq.i686.rpm I am printing to a SMB printer elsewhere on the computer. I can print the test page from the printconfgui I can print a text file from the command line (lp /etc/passwd) Wine expects to print with lpr and the corresponding syntax. Can you print on the command line with lpr instead of lp?
