Re: Pajama Sam's unmanaged window
Ori Pessach [EMAIL PROTECTED] wrote: Since this is probably not the case, perhaps it's better to check for the popup menu class in is_window_managed(), something like if (GetClassLongA(win-hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return FALSE; Ah ha! Exactly what I had in mind. After thinking about this, it seemed to me that is_window_managed() should examine the window's class, as well as its style bits, since the class will give a more accurate indication of what kind of window we're dealing with than just the style bits. Unfortunately this aproach does not work well in all cases, especially in the case of subclassed windows. -- Dmitry.
Re: C testing framewok. Updated. SystemParametersInfo unit test.
Andriy Palamarchuk [EMAIL PROTECTED] wrote: One more important change in C framework is support of Unicode in testing. Dimitry, can you look at it? See how it is used in sysparams.c, search for has_unicode function call. I'm interested in your comments. I would suggest to explicitly use A and W suffixes to avoid confusion: not just SystemParametersInfo, but SystemParametersInfoA. -- Dmitry.
Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...
Andriy Palamarchuk [EMAIL PROTECTED] wrote: I mean real Windows 95. Tests should be compiled and run on all the Windows platforms to insure their correctness. Is there a way to check whether given version of Win32 supports UNICODE? Probably some tests should be marked as expected to fail on 9x, NT4, 2000 to predict failures on particular version of windows. Please take into account that there are considerable number of API calls are not supported on one of Windows incarnations (unicode, thunks, crypto API, native APIs, additions to the server versions, etc.). -- Dmitry.
Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...
Uwe Bonnes [EMAIL PROTECTED] wrote:
Please let us know if you find some sensible way to test filesystem
functions. What I do now is
- export some filesystem tree with SMB(NCP)
- import it in Vmware with some drive letter
- use the same drive letter in the wine-config for the same filesystem tree
I don't think this solution is very sensible for a more generalized test...
Well, I thought about very simple test case like this one (in C):
#include assert.h
#include string.h
#include windows.h
int main(void)
{
UINT len, len_with_null;
char buf[MAX_PATH];
strcpy(buf, foo);
len_with_null = GetSystemDirectory(buf, 1);
assert(strcmp(buf, foo) == 0);
strcpy(buf, foo);
len = GetSystemDirectory(buf, len_with_null - 1);
assert(len == len_with_null);
strcpy(buf, foo);
len = GetSystemDirectory(buf, len_with_null);
assert(strcmp(buf, foo) != 0);
assert(len == strlen(buf));
assert(len == (len_with_null - 1));
return 0;
}
If anybody could provide some hints how to integrate it into the winetest
system, I and other people will certainly appreciate it.
--
Dmitry.
Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...
Uwe Bonnes [EMAIL PROTECTED] wrote: GetSystemDirectory seems easier then other filesystemn functions, as you know exactly what to get. Other functions, like GetLongPathname has zillions of possible combinations of dots, slashes and backslashes that complicates things enormous. I think only by comparing test output produced with Wine and Win32 we can see whether Wine behaves right. Exactly. Why just to not hardcode values retrieved from the running the test under Windows and compare them in the test run? To simplify things it should be possible to merge GetLongPathName with CreateFile and CreateDirectory in the single test case. That would give us completely predictable results. -- Dmitry.
Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...
Andriy Palamarchuk [EMAIL PROTECTED] wrote: Dmitry, I changed the your test to use the C testing framework I posted today. The test is attached. It looks good to me, but we should not forget to test both unicode and ANSI versions of functions. There are two approaches to accomplish this task: 1. Have two separate tests for A and W functions. 2. Have single test without using A or W suffix and choose appropriate test by [not] defining UNICODE before including windows.h. Does anybody have other suggestions or ideas? -- Dmitry.
Re: WinSpool Ordinal Addition
Mark G. Adams [EMAIL PROTECTED] wrote: Here's the message output on startup if those functions are not exported at the expected ordinals: err:win32:PE_fixup_imports No implementation for WINSPOOL.DRV.201 imported from C:\OmniMark\EnterpriseStudio6_1_1\OmniMark-Enterprise-Studio.exe, setting to 0xdeadbeef Unless i'm mistaken, that's an ordinal import. This application will not work either under win9x or win2000 because they have different functions assigned to ordinal 201: win95 OSR2 PE and win98 SE: StartDocPrinterA win2000: GetDefaultPrinterA It should be clear even for you, since you have submitted two different patches with ordinal 201 assigned to absolutely different functions and presumably both variants have worked for you. Apparently just adding 100 stub OrdinalBase should work for you too. Probably the right fix would be to add new parameter to the wine .spec files: ordinal base, because for WINSPOOL.DRV it's equal to 100 in all variants of that DLL for me. -- Dmitry.
Re: WinSpool Ordinal Addition
Mark G. Adams [EMAIL PROTECTED] wrote: The fact that it worked with different functions there did surprise me. My assumption (not having a good idea on how ordinal importing works) was that, at this point, it's just checking for the presence of a function but not executing it. Very little of the application works under WINE, so I'm not able to actually test out printing currently. Given the above, I agree there's no point in assigning ordinals to those two functions. Could you please test the attached patch which implements the ordinal base functionality in winebuild and sets ordinal base 100 for WINSPOOL.DRV? -- Dmitry. ordinals.diff Description: Binary data
Re: configure broken?
Oliver Sampson [EMAIL PROTECTED] wrote: Thanks! How does one know that it was this type of problem, as opposed to another type of problem? Well, just solve that type of problem at least twice... -- Dmitry.
Re: thread safing dlls
Michael Zayats [EMAIL PROTECTED] wrote: I have a dll that is not thread safe (i.e. has many global variables, about 500). I have the sources for the dll. The target is to make it thread safe. Moving all the variables to thread specific storage is very complicated. Making it thread safe on ansi C level is very, very complicated too. I guess that you thoroughly deal with PE format. Is there a way to play with executable sections, such that every thread will use it's own copy of the data? I know one guy, that claimed that he has achieved this with 20 lines of code by directly modifying smth in executable, he doesn't want to tell me what he has done :( I also heard of __attribute((section... in gcc that should do the work (I am generally talking about windoze platform only), can you explain me what does it do in gcc? All you need is to place all initialized data you want to make thread safe to a separate section and then place a pointer to that data in the PE header [IMAGE_FILE_THREAD_LOCAL_STORAGE]. Creating custom section is an easy part, but I don't know how to fulfill the second part with gcc. -- Dmitry.
Re: Another pack4 issue (fwd)
Francois Gouget [EMAIL PROTECTED] wrote:
[...]
What is really fun, that usage of FILETIME instead of LARGE_INTEGER leads
to differences in size of structures.
That's very strange. It would be good to understand why because this
should not happen.
Any ideas, why does it happen? Is it due to the LONGLONG usage?
-if (ft) *ft = info-LastWriteTime;
+if (ft) *ft = *(FILETIME *)info-LastWriteTime;
This cast should not be necessary. Both sides are FILETIMEs.
It's because according to ntddk.h from NT4 DDK info-LastWriteTime
is LARGE_INTEGER. Please look at my patch a bit carefully.
-FILETIME modif;
+LARGE_INTEGER modif;
-RtlSecondsSince1970ToTime( req-modif, modif );
+RtlSecondsSince1970ToTime( req-modif, (FILETIME *)modif );
Here I don't understant why you changed modif to a LARGE_INTEGER
since RtlSecondsSince1970ToTime takes a FILETIME*
Same comment as above.
+UINTtype;
+LPVOID pvFilter;
} HDITEMA, *LPHDITEMA;
I don't see these two fields on Windows. Same thing for the W
version. That's with the VC 6 headers.
It's in July 2000 PlatformSDK as well as in MSDN online.
typedef struct {
DWORD cb;
-BYTE DeviceName[32];
-BYTE DeviceString[128];
+CHAR DeviceName[32];
+CHAR DeviceString[128];
DWORD StateFlags;
+CHAR DeviceID[128];
+CHAR DeviceKey[128];
} DISPLAY_DEVICEA,*PDISPLAY_DEVICEA,*LPDISPLAY_DEVICEA;
Hmm, no. It is 'BYTE' on Windows. And I don't see the two extra
fields either.
Same comment as above.
+
+BYTEExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
} CONTEXT86;
I don't have this field in CONTEXT86, but it is there in
CONTEXT. It seems that it's our definition of CONTEXT which is wrong:
typedef CONTEXT86 CONTEXT;
Same comment as above.
typedef struct _IMAGE_BASE_RELOCATION
{
DWORD VirtualAddress;
DWORD SizeOfBlock;
+#ifdef __WINE__
WORD TypeOffset[1];
+#endif
} IMAGE_BASE_RELOCATION,*PIMAGE_BASE_RELOCATION;
Do we handle this correctly in the code? I.e. is there APIs where the
application gives us a pointer to a struct without the field and we
write to it? I wonder how this is supposed to work.
In winnt.h from the PlatformSDK it is just commented, but as you could assume
Wine loader uses this field to relocate images.
+#include pshpack4.h
typedef struct _LUID_AND_ATTRIBUTES {
LUID Luid;
DWORD Attributes;
} LUID_AND_ATTRIBUTES;
+#include poppack.h
Is this really necessary? LUID is 8 bytes so the DWORD should be
aligned just fine with or without the pack4...
Without pshpack4.h sizeof(LUID_AND_ATTRIBUTES)=16 instead of 12. Don't ask
me why. Both NT4 DDK (ntddk.h) and PlatformSDK (winnt.h) headers surround
LUID_AND_ATTRIBUTES definition by pshpack4.h/poppack.h pair.
Thanks for your comments.
--
Dmitry.
Re: Another pack4 issue (fwd)
Ulrich Weigand [EMAIL PROTECTED] wrote: Without pshpack4.h sizeof(LUID_AND_ATTRIBUTES)=16 instead of 12. Don't ask me why. Because the size of a structure is always padded to the next multiple of its alignment (so that in an array of structures, every element is properly aligned iff the array is). By changing the alignment, you therefore also sometimes change the size of a structure ... Ulrich, thanks for explanations. I believe that's the case for the FILETIME vs. LARGE_INTEGER issue too. -- Dmitry.
Re: LYES is a NO NO!!!
Francois Gouget [EMAIL PROTECTED] wrote:
Wine cannot use Unicode strings literals. When you write LYES this
is a 32bit Unicode string, not a 16bit unicode string. This means that
when you pass it to lstrcmpiW, which expects 16bit Unicode strings like
all the APIs in Wine, what it sees is this: Y\0E\0S\0\0\0. And this is
obviously different from YES.
I guess it pays to check the warnings form time to time!
Sure. Why not to change L'\0' to a simple 0 in your patch then?
@@ -447,10 +451,10 @@
switch (type) {
case REG_SZ:
data[9] = L'\0'; /* set end of string */
^^^
--
Dmitry.
Re: Don't TRACE NULL strings
François Gouget [EMAIL PROTECTED] wrote: - TRACE((%p %p %x)\n,pidl,szOut,uOutSize); + TRACE((%p %p %x)\n,pidl,debugstr_a(szOut),uOutSize); ^^ ^ Please recheck for pointer format vs. string argument mismatches. -- Dmitry.
Re: SHGetSpecialFolderPathA and CSIDL_FOLDER_MASK
Chris Green [EMAIL PROTECTED] wrote: I've been looking at this function, and I am starting to suspect we have the wrong definition of CSIDL_FOLDER_MASK (currently 0x00ff). What I've been seeing (eg. installing MS Office 97) seems to imply that only the lower 6 bits, rather than 8, are related to the folder, and the others are something else. Does anyone else think that the mask should be 0x003f? Yes, 0x3f seems to be reasonable according to ShlObj.h from the Platform SDK. -- Dmitry.
Re: err:edit:EDIT_LockBuffer no buffer ... please report
[EMAIL PROTECTED] wrote: Okay, I reported it, attached is an unexpurgated --debugmsg +edit trace of me trying to open the lcc-win/lccpub/bin/wedit.hlp file from ftp://ftp.mathematik.tu-darmstadt.de/pub/linux/bonnes/lcc-bin-alpha.tar.gz with wine's builtin winhelp program. Please let me know whether attached (untested) patch fixes it. Changelog: Defer edit style correction until EDITSTATE is fully initialized. -- Dmitry. edit.c.diff Description: Binary data
Re: OLEAUT32 patch
Andreas Mohr [EMAIL PROTECTED] wrote: this is a rewrite of OaBuildVersion(). Now we just return the highest version value possible (0x) and have a config file option to tweak the version value to return if this is causing problems. Added docu for it, of course. I suspect too much of extra RegCloseKey(hkey) statements in OLEAUT32_GetAppKey() implementation. -- Dmitry.
Re: _NET_WM_NAME support patch
Ilya Konstantinov [EMAIL PROTECTED] wrote: This patch adds a _NET_WM_NAME(UTF8_STRING) property to every window, storing it's title in non-ambigous UTF8 encoding. This is a part of the NET_WM standard. The UTF8 title feature is currently implemented only by KWin (KDE's window manager), but is adopted by both GNOME and KDE camps. @@ -746,12 +748,32 @@ BOOL X11DRV_SetWindowText( HWND hwnd, LP return FALSE; } WideCharToMultiByte(text_cp, 0, text, -1, buffer, count, NULL, NULL); + +count = utf8_wcstombs(text, strlenW(text), utf8_buffer, 0); Why didn't you use win32 call instead of a purely internal one? count = WideCharToMultiByte( CP_UTF8, 0, text, -1, NULL, 0, NULL, NULL ); utf8_buffer = HeapAlloc( GetProcessHeap(), 0, count ); count = WideCharToMultiByte( CP_UTF8, 0, text, -1, utf8_buffer, count, NULL, NULL ); -- Dmitry.
NG: Wine and cyrillic input and output ?
Hello all. This patch fixes a couple of problems with keyboard group switching reported in the news group: 1. Group switch had never worked before, if the keyboard has been switched outside of Wine. 2. I was clearly stated that Group switch is active if event-state 0x2000, not event-state 0x6000. Please test it on your local configurations and report back. If there will be no objections, I'll send it to wine-patches. Thanks. -- Dmitry. kbd_switch.diff
Re: NG: Wine and cyrillic input and output ?
Nerijus Baliunas [EMAIL PROTECTED] wrote: In my XF86Config-4 I have: Option XkbLayout lt Option XkbOptions grp:ctrl_shift_toggle - it means Ctrl+Shift switches layouts. I switched layouts 2 times in notepad. Without patch: err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) With patch: err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=5) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A (ISO_Prev_Group) : err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=2005) As you see, with patch state is different when switching layout second time. Sure. Wine corrects state according to its internal lpKeyState. Difference between internal and actual state value is due to the fact that Wine does not see (or better X does not show) some keyboard events. Since I also have grp:ctrl_shift_toggle I had seen the same state correction. Perhaps Wine should ignore ISO_Prev_Group/ISO_Next_Group keyboard events to not confuse users. -- Dmitry.
Re: GDI_CheckNotLock strikes again
Huw D M Davies [EMAIL PROTECTED] wrote: Does this help? Yes, it does. But application (a heavily modified MS glyph sample from 1993) doesn't show anything. I could send you the source code if you are interested to fix it. -- Dmitry.
Re: Win16 calls by Win32 functions
Patrik Stridvall [EMAIL PROTECTED] wrote: Noticing that you (Dimitry) have send in a few patch replacing Win16 calls by Win32 ones, I wish to point out that winapi_check can detect illegal calls from Win32 to Win16. Just do winapi_check --cross-call-win32-win16 Great! Why didn't you just make a patch and submit it? Unfortunately there is a bug in the CVS version of winapi_check (fixed in my tree) that makes this option output too many messages. However until it is updated just do grep 'illegal call' on the output. The result this is included below. Note that some of the fixes in your (Dimitry's) patches is not included in the result below because they are Win16 functions calling Win16 functions. I do not say this is nessary wrong, but are you (Dimitry) really sure this is how it should be? Well, as Alexandre already has pointed out, Win16 should be mostly implemented by using Win32. I agree with him that use of the 16-bit code should be eliminated as much as possible. Moreover, until now I just have replaced only obvious places: 16-bit functions which just thunk up to win32 without any argument processing. Sure it probably runs a little faster, but then Win16 applications on a modern computer are likely to be _very_ fast, so it is really worth risking potential compabillity errors because of some probably irrelavant speed differences. Not that functions like DeleteObject are likely to have such problems but still... I'm not going to blindly replace 16-bit calls by 32-bit. I look into the code and do think twice before submitting a patch. Anyway, thanks for your comments. -- Dmitry.
Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
Alexandre Julliard [EMAIL PROTECTED] wrote: While the idea of the patch is correct, I think it would be much better to fix the huge code duplication while everything is in the same file. The 16-bit stuff should be implemented on top of the 32-bit stuff, instead of duplicating most of it. Alexandre, you are right that that code should be revised and duplications must be remove. But since I'm not an expert in the win32 communications code, I can't do it without risk to break a working code. This patch was mostly inspired by the fact, that while USER exports 16-bit comm stuff, that stuff is not in the USER code. Instead of doing an ugly thing exporting 16-bit comm functions from KERNEL I decided to move the code around. Please consider the applying of the patch as it is now. Code duplication can be removed later. Thanks. -- Dmitry.
Re: PATCH: mirc dcc send
Marcus Meissner [EMAIL PROTECTED] wrote: + /* This might be a DOS device we do not handle yet ... */ + FIXME((%) not detected as DOS device!\n,devname); ^^^ Seems a typo to me.
Re: Add missing newline to WARN messages
Francois Gouget [EMAIL PROTECTED] wrote: * I scanned the source for TRACE/WARN/ERR/FIXME statements without a terminating newline. There are few cases where this is justified because of following DPRINTFs. But most of the time there should be a \n otherwise the trace will not be flushed to disk immediately and the logs will look bad. You forgot to remove redundant ' around %s in the traces when output is made by debugstr_a or debugstr_w. Actually you removed some of them, but not all.
Re: PATCH: wineps passthrough postscript
Marcus Meissner [EMAIL PROTECTED] wrote: It works now much better, except it somehow cannot upload fonts(?) and queries support for escapes 4568 and 4567 which are unknown to me. PlatformSDK July 2000 defines #define SPCLPASSTHROUGH2 4568 /* new escape for NT5 pscript driver */ From its name, it means HP PCL pass through mode. Apparently 4567 is defined in the Win2000 DDK.
Re: Quickbooks 5 and printing
Dan Engel [EMAIL PROTECTED] wrote: Okay, here are the traces. Here (ftp://sourceharvest.com/pub/wine_qb4.log.gz) is the QB4 trace. QB4 printing works. The other (ftp://sourceharvest.com/pub/wine_qb5.log.gz) is the QB5 trace. QB5 printing doesn't work. Please try the attached patch. It tries to solve the root of the problem: for now Wine Postscript Driver lives in wineps.dll, but should be in wineps.drv. Changelog: Rename wineps.dll to wineps.drv. Replace all occurences of wineps by wineps.drv in the sources and documentation. wineps.diff
Re: Quickbooks 5 and printing
Dan Engel [EMAIL PROTECTED] wrote: Using --debugmsg warn+all,+relay,+text,+string I found that it's trying to load wineps.drv.dll which translates into libwineps.drv.so. This doesn't work, and it appears that the QB code is what's adding the .DRV to the WINEPS print driver name. I hacked around that by checking for WINEPS.DRV at the beginning of BUILTIN_LoadModule and replacing it with WINEPS. First of all, you didn't tell what type of application is QB: 16 or 32 bit. 16-bit applications nearly always look for printer driver themself. They look at win.ini in the following sections: [devices], [PrinterPorts] or just [windows].device= Starting from Win3.1, where common dialogs were introduced, applications started just call common dialog, which allowed easy printer selection. Vast majority of 32-bit applications also use common dialogs, but some advanced (read - stupid) appications try do read registry or even use old Win3.x method described above. You should look at all places (win.ini and registry), find all references to WINEPS and remove any extension from it (be it .DRV or .DLL). If that will not help, post somewhere a +relay,+module trace.
Re: Virtual memory under Win95
Ulrich Weigand [EMAIL PROTECTED] wrote: VirtualQuery in Win95, however, appears to completely ignore the KERNEL32 list of views, but always calls the _PageQuery VMM service and returns VMM's opinion on the status of the pages. This explains why VirtualQuery shows the pages still present after UnmapViewOfFile. Perhaps applications which use assumptions about Win95 virtual memory management should be considered as broken? Or it is worth to support them? In my case installer works very well with -winver nt40 switch, but certainly there are other applications written for Win9x in mind only...
Re: Virtual memory under Win95
I wtote: Rein Klazes [EMAIL PROTECTED] wrote: win95 on a vmware machine. H:\test hMapping = 0005 p = 826DB000 VirtualQuery(826DB000) ret=0x1c BaseAddress = 826DB000 AllocationBase = 826DB000 AllocationProtect = 0x0001 RegionSize = 0x0400f000 State = 2000 Protect = 0001 Type = 0002 This means that Win95/98 doesn't free region allocated with SEC_RESERVE flag set. Could you please test other SEC_ flags? Is the result the same? Comment about SEC_RESERVE in memory/virtual.c tells enough, besides the fact that Win95 does not unmap regions allocated with that flag set. Attached patch makes the debugged installer proceed much further with -winver win95 switch now. Unfortunately currently there is no way to distinguish regions allocated with SEC_RESERVE flag set. Now installer DebugBreak's after another VirtualQuery call. Could you (or anybody else with a Win95 machine) add the following lines at the end of the previous test program and report the result? dwRet = VirtualQuery(p + 0x1, info, sizeof(info)); printf(VirtualQuery(%p) ret=0x%lx\n BaseAddress = %p\n AllocationBase = %p\n AllocationProtect = 0x%08lx\n RegionSize = 0x%08lx\n State = %08lx\n Protect = %08lx\n Type = %08lx\n, p + 0x1, dwRet, info.BaseAddress, info.AllocationBase, info.AllocationProtect, info.RegionSize, info.State, info.Protect, info.Type); As usually thanks in advance (to Uwe Bonnes too! He sent his result privately). virtual.c.diff
Re: Virtual memory under Win95
"Rein Klazes" [EMAIL PROTECTED] wrote: win95 on a vmware machine. H:\test hMapping = 0005 p = 826DB000 VirtualQuery(826DB000) ret=0x1c BaseAddress = 826DB000 AllocationBase = 826DB000 AllocationProtect = 0x0001 RegionSize = 0x0400f000 State = 2000 Protect = 0001 Type = 0002 This means that Win95/98 doesn't free region allocated with SEC_RESERVE flag set. Could you please test other SEC_ flags? Is the result the same?
Re: Strange crash
"Rein Klazes" [EMAIL PROTECTED] wrote: Exception occurs when pen-logpen.lopnWidth.x = 0 and dc-xformWorld2Vport.eM11 = 0.0 It's very strange. Attached patch helps to eliminate crash. But I don't understand where the source of problem. | 0x40897fde (X11DRV_PEN_SelectObject+0x8e [pen.c:69]): fldcw 0xfffe(%edx) This instruction loads the control status word with a new value. Bit 5 of the CW (0x20) ,PM Precision Mask , is the mask bit for this exception. Find out how this bit has become zero (disassembly of the instructions before the crash). If I put a breakpoint on the instruction above, the CW is loaded with 0x37f: all FP exceptions are off. I have attached full assembly listing of graphics/x11drv/pen.c produced by gcc. I removed -g option to reduce the output size and added -S -fverbose-asm. pen.s
Re: Traces: fs - tid
"Francois Gouget" [EMAIL PROTECTED] wrote: I noticed that fs was replaced by tid in relay (and snoop co too now). I propose a slightly different version based on the following premises: * when suspecting a threading problem it could be nice to tag each trace with the id of the thread that emits it * when there's no thread issue, then fs and tid are unnecessary and only clutter the traces by making lines longer and harder to read * I find that lines are more readable if the thread id comes first as it's always the same length and doesn't mess up the alignment of the other fields So this patch adds a debug channel called 'tid' which activates printing the tid as the first field of all traces. Actually, it might make sense to merge 'tid' with the 'thread' debug channel. The point was to be able to easy track down problems in multiprocess/multithreaded environment with just +relay trace. You never know, what surprise you will see analysing the traces from the news group. Besides that, at least I always start searching for the problem with +relay trace: it would be too late to add +tid (or whatever) to notice, that the actual problem is related to process/thread interaction. Regarding too long lines: it is not the actual problem (doesn't it?). I would complain about too large files with the trace logs :-)
Re: Make PostScript driver less loquacious
"Ian Pilcher" [EMAIL PROTECTED] wrote: Well, the only paper size missing is DMPAPER_11X17, presumable because it isn't mentioned in Adobe's documentation. For the bin types, if someone can tell me how to map the following PPD file bin types, I'll do it: Since we have a fairly limited set of available DMBIN_???, some approximation could be used. For all missing bins we could just assign some reasonable value, for instance DMBIN_AUTO: 2ndTray 3rdHCFTray 3rdTray 4thHCFTray 4thTray 500Sheet ASFbin1 ASFbin2 AUTO -- DMBIN_AUTO AnyLargeFormat -- DMBIN_LARGEFMT Auto -- DMBIN_AUTO AutoSelect -- DMBIN_AUTO Auto_Tray1 -- DMBIN_AUTO Auto_Tray2 -- DMBIN_AUTO Automatic -- DMBIN_AUTO Autoselect -- DMBIN_AUTO Autotray -- DMBIN_AUTO Bin1 Bin2 Bottom -- DMBIN_LOWER Bottomtray -- DMBIN_LOWER Bypass BypassHeavy BypassPaper BypassT1 BypassT2 BypassT3 BypassTransparency BypassTray BypassXHeavy CPF1 CPF2 Cassette -- DMBIN_CASSETTE Cassette1 -- DMBIN_CASSETTE Cassette2 -- DMBIN_CASSETTE Cassette3 -- DMBIN_CASSETTE Cassette4 -- DMBIN_CASSETTE Cassette5 -- DMBIN_CASSETTE EnvFeed -- DMBIN_ENVELOPE Envelope -- DMBIN_ENVELOPE EnvelopeFeeder -- DMBIN_ENVELOPE EnvelopeTray -- DMBIN_ENVELOPE Front FrontFeed FrontFeeder HCEF HCF HighCapTray1 -- DMBIN_LARGECAPACITY Hopper InsertSheet LCIT LargeCapacity -- DMBIN_LARGECAPACITY LargeCapacityTray -- DMBIN_LARGECAPACITY LargeLower -- DMBIN_LOWER LargeUpper -- DMBIN_UPPER Largesheet -- DMBIN_LARGEFMT Lower -- DMBIN_LOWER Lower1 -- DMBIN_LOWER Lower2 -- DMBIN_LOWER Lower250SheetFeeder -- DMBIN_LOWER Lower500SheetFeeder -- DMBIN_LOWER LowerCassette -- DMBIN_LOWER or DMBIN_CASSETTE LowerOptTray -- DMBIN_LOWER LowerTray -- DMBIN_LOWER Lowercassette -- DMBIN_LOWER or DMBIN_CASSETTE MBF MP -- DMBIN_AUTO MPF MPMF MPT -- DMBIN_AUTO MPTray -- DMBIN_AUTO MSI Main -- DMBIN_AUTO MainTray -- DMBIN_AUTO Manual -- DMBIN_MANUAL ManualBypass -- DMBIN_MANUAL ManualEnvelope -- DMBIN_ENVMANUAL ManualFeed -- DMBIN_MANUAL ManualFeedTray -- DMBIN_MANUAL ManualFeeder -- DMBIN_MANUAL ManualNormal -- DMBIN_MANUAL ManualOHP -- DMBIN_MANUAL ManualPaper -- DMBIN_MANUAL ManualThick -- DMBIN_MANUAL ManualTransparency -- DMBIN_MANUAL Medium -- DMBIN_MIDDLE Middle -- DMBIN_MIDDLE Middle250SheetFeeder -- DMBIN_MIDDLE Middle500SheetFeeder -- DMBIN_MIDDLE Middletray -- DMBIN_MIDDLE Multi-Feeder -- DMBIN_AUTO Multi-MediaFeeder -- DMBIN_AUTO Multi-Purpose -- DMBIN_AUTO MultiMediaFeeder MultiPurpose -- DMBIN_AUTO Multimedia Multipurpose -- DMBIN_AUTO MultipurposeTray -- DMBIN_AUTO NotSpec -- DMBIN_AUTO OnlyOne -- DMBIN_ONLYONE OptionalCassette -- DMBIN_CASSETTE OptionalCassette1 -- DMBIN_CASSETTE OptionalCassette2 -- DMBIN_CASSETTE OptionalTray Paper PaperDeck PaperTray Paper_Deck PrinterDefault -- DMBIN_AUTO Rear Roll RollFeed SecondCassette -- DMBIN_CASSETTE SideTray Slot0 Slot1 Slot2 Slot3 Slot4 Small -- DMBIN_SMALLFMT Standard -- DMBIN_AUTO StandardCassette -- DMBIN_CASSETTE StandardTray -- DMBIN_AUTO StandardTray -- DMBIN_AUTO Top -- DMBIN_UPPER Toptray -- DMBIN_UPPER Transparency Tray Tray0 Tray1 Tray2 Tray3 Tray4 Tray5 Tray6 Tray7 TrayManual -- DMBIN_MANUAL Tray_Auto -- DMBIN_AUTO Universal -- DMBIN_AUTO Upper -- DMBIN_UPPER UpperCassette -- DMBIN_UPPER or DMBIN_CASSETTE UpperOptTray -- DMBIN_UPPER UpperTray -- DMBIN_UPPER Uppercassette -- DMBIN_UPPER or DMBIN_CASSETTE Version2 Web
Re: Make PostScript driver less loquacious
"Ian Pilcher" [EMAIL PROTECTED] wrote: Is it really appropriate to spit out a FIXME every time we encounter a paper size or bin type that we don't recognize? I would agree with you, if you have added all regular possible values listed in wine/include/wingdi.h and only then replaced FIXME's by WARN's.
Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
"Alexandre Julliard" [EMAIL PROTECTED] wrote: I think it would be better to keep the existing support for native dlls, and simply fall back to loading the builtin library if SearchPath fails. Does the attached patch look as applicable? module.c.diff
Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
"Alexandre Julliard" [EMAIL PROTECTED] wrote: I think it's reasonable to give the native dll priority when doing LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the dll binary file and we are much better off giving it the 'real' thing in this case IMO. Perhaps version.dll code should use DONT_RESOLVE_DLL_REFERENCES instead of undesirable LOAD_LIBRARY_AS_DATAFILE? Will DONT_RESOLVE_DLL_REFERENCES work with built-in dlls somewhere in the future?
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed. It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32. Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think. Well, you can of course submit a patch for the oleaut32 version info. But it completely useless without loader/module.c modification if the requested built-in library was not yet loaded :-( I'll look at my patch ones more, split it into two distinct patches and submit them tomorrow.
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth? Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly. Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you? Yes. I can't promise it will work for other apps, and maybe in time we will have to go to "255.0" or something, but for now, 10.0 works for me. Great! #define WINE_FILEVERSION 10,0,0,0 #define WINE_FILEVERSION_STR "10.0" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" If you get this letter, it works. I'm sorry, I didn't focus you on the subject that FILEVERSION and PRODUCTVERSION are distinctly different things? How about to experiment with different WINE_FILEVERSION and PRODUCTVERSION (WINE_FILEVERSION_STR and WINE_PRODUCRVERSION_STR) numbers? Sorry, if it is not the same as you expected from me...
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth? Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly. Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed. It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32. Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think. Well, you can of course submit a patch for the oleaut32 version info. But it completely useless without loader/module.c modification if the requested built-in library was not yet loaded :-( I'll look at my patch ones more, split it into two distinct patches and submit them tomorrow.
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: Strange, I tested my patch with About.exe and it worked for me. From the trace you sent me directly my patch works just fine. You could try replace version.rc by the following version resource, and to see if it will help (even better try to use both and report the result): oleaut32.dll from the original win95: I am sorry, I can't work out just now how to get this into the source and make it compile. Maybe tomorrow I will be a bit cleverer. I can send a patch if you wish :-). Basically you should add #include "winver.h" as the very first line and then copy completely all other strings starting with FILEVERSION2,10,3024,1 ... etc. Since juno doesn't query some specific version value (according to your trace), but wants to get complete version info ... Ret version.1: GetFileVersionInfoA() retval=0001 ret=12032703 fs=008f Call version.12: VerQueryValueA(40dd0f40,1207c090 "\\",40576db4,40576d6c) ret=12032750 fs=008f trace:ver:VerQueryValueA (0x40dd0f40,"\\",0x40576db4,0x40576d6c) Ret version.12: VerQueryValueA() retval=0001 ret=12032750 fs=008f Call user32.226: GetActiveWindow() ret=120300c4 fs=008f Ret user32.226: GetActiveWindow() retval= ret=120300c4 fs=008f it would be great if you could experiment with changing version numbers: FILEVERSION 2,10,3024,1 --- (in Wine it is 1,0,0,0) VALUE "FileVersion", "2.1" --- (in Wine it is "1.0") and VALUE "ProductVersion", "2.1" --- (in Wine it is "1.0") Make sure to change them all simultaneously.
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: Nuts! Parse errors still, until I added VS_VERSION_INFO VERSIONINFO before it, then it compiles clean, but all values except Translation are null. So I tried with this dlls/oleaut32/version.rc, and it works (if you get this letter): #define WINE_FILEVERSION 2,20,4054,1 #define WINE_FILEVERSION_STR "2.20.4054" #define WINE_FILEDESCRIPTION_STR "Wine OLE dll" #define WINE_FILENAME_STR "oleaut32.dll" #include "wine/wine_common_ver.rc" Very good! Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth? Those numbers I lifted from the output of wine --dll oleaut32=n About.exe oleaut32.dll I am still not easy in my mind with --dll directly controlling version in this way. --dll controls dll loading. Is it so hard to understand? Version info is retrieved from resources of the already loaded dll then.
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth? Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly. Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: Could you please experiment some more and try to replace 2,20,4054,1 and "2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and so forth? Okay. 2.20.4054 is the minimum, it seems, but I'll try 2.21 and so on shortly. Perhaps we should use some bogus version value (say 10.0) for all wine built-in dlls? I just don't like an idea to hunt down all that cases when some application will want that strange version numbers. Will 10.0 work for you?
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote: I guess it doesn't look at all of it though. I will try later with 2.20.4055 if this is a minimum or it wants the one it installed. It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053, so I guess 2.20.2054 is its minimum oleaut32. Will you submit a patch for that, or should I? I haven't really looked at what you were doing with loader/module.c, but I've applied it and I don't see any harm from it, I think. Well, you can of course submit a patch for the oleaut32 version info. But it completely useless without loader/module.c modification if the requested built-in library was not yet loaded :-( I'll look at my patch ones more, split it into two distinct patches and submit them tomorrow.
Re: [PATCH] Version info for comctl32.dll
"gerard patel" [EMAIL PROTECTED] wrote: Getting the common controls to the 4.72 version at least is the *whole* purpose of the patch. There are applications testing the version number of the common controls - tons of them : all the apps written with modern Borland tools. Their behaviour change accordingly because Ms changed things quite a lot with 4.72. Wine does not emulate the old behaviour, so it's needed to return a recent version number to get some apps to work correctly. Sure. The same should be done at least for OLE dlls too. [...] Well, all right I'll do like it's done in include/wine. I did not search far enough, I used the file in commdlg as an example :-) I found another problem you missed btw, there is a special function to retrieve the dll version directly, it returns hard coded values; I'll add code to retrieve these from the resource. Thanks. On the related note: Lawson Whitney reported that juno 2.0.11 checks version info of oleaut32.dll and with my recent patch (which has disabled searching of version resources if dll was loaded but version resources were not found) refuses to load. Well, I added version info into built-in oleaut32.dll, but here another problem arised: LoadLibraryExA explicitly checks for LOAD_LIBRARY_AS_DATAFILE, and then uses SearchPathA to locate a dll. Since SearchPathA can't find built-in dlls LoadLibraryExA returns 0. With the attached patch my test program is now able to retrieve version info for built-in oleaut32.dll, but I didn't manage to avoid resolving imports for built-in dlls, because they are register themself from the code generated by winebuild. I tried to propagate 'flags' starting from BUILTIN_LoadLibraryExA, but failed. Now the question: How to load built-in dll without resolving its imports? res.diff
Re: [PATCH] Version info for comctl32.dll
[EMAIL PROTECTED] wrote:
Now the question: How to load built-in dll without resolving its imports?
Where's the harm in resolving the imports of the builtin?
In this case, the app has already loaded and used oleaut32 before it
gets around to asking about its version.
If the dll already loaded, then there is no harm at all. But if not,
there is huge penalty in performance and memory usage. Take into account
that currently built-in dlls are never unloaded. In the case of oleaut32,
ole32 and advapi32 also will be loaded. If an application doesn't use them,
but simply does query its version, there is more harm, than the good.
I tried this patch, and unreverted the GetFileVersionInfo(Size) patch,
but juno still isn't happy. With the native dll present, the app asks
for its version info and gets the builtin. The ver trace looks a little
strange to me - maybe it will make sense to you?
About.exe returns the builtin oleaut32 version, but _only_ if the native
oleaut32 is present (if I move it away, About.exe gets size 0), and only
if it is given the native dll's filename. Give it the builtin filename
and it gets size 0. I think the latter is probably not a problem, but
it seems strange to me.
Strange, I tested my patch with About.exe and it worked for me.
You could try replace version.rc by the following version resource, and
to see if it will help (even better try to use both and report the result):
oleaut32.dll from the original win95:
FILEVERSION2,10,3024,1
PRODUCTVERSION 2,10,3024,1
FILEFLAGSMASK 0x3F
FILEFLAGS 0x0
FILEOS VOS_NT | VOS__WINDOWS32
FILETYPE VFT_DLL
FILESUBTYPE0x0
{
BLOCK "StringFileInfo"
{
BLOCK "040904E4"
{
VALUE "CompanyName", "Microsoft Corporation"
VALUE "FileDescription", "Microsoft OLE 2.1 for Windows NT(TM) Operating
System"
VALUE "FileVersion", "2.1"
VALUE "InternalName", "OLEAUT32.DLL"
VALUE "LegalCopyright","Copyright c Microsoft Corp. 1993-1995."
VALUE "LegalTrademarks", "MicrosoftR is a registered trademark of Microsoft
Corporation.
Windows NT(TM) is a trademark of Microsoft Corporation."
VALUE "ProductName", "Microsoft OLE 2.1 for Windows NT(TM) Operating
System"
VALUE "ProductVersion","2.1"
VALUE "Comments", "Microsoft OLE 2.1 for Windows NT(TM) Operating
System"
}
}
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x409, 1252
}
}
oleaut32.dll from the win2000 SP1:
FILEVERSION2,40,4514,1
PRODUCTVERSION 2,40,4514,1
FILEFLAGSMASK 0x3F
FILEFLAGS VS_FF_PRERELEASE
FILEOS VOS_NT | VOS__WINDOWS32
FILETYPE VFT_DLL
FILESUBTYPE0x0
{
BLOCK "StringFileInfo"
{
BLOCK "040904E4"
{
VALUE "CompanyName", "Microsoft Corporation"
VALUE "FileVersion", "2.40.4514"
VALUE "InternalName", "OLEAUT32.DLL"
VALUE "LegalCopyright","Copyright c Microsoft Corp. 1993-1998."
VALUE "ProductVersion","2.40.4514"
}
}
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x409, 1252
}
}
Re: [PATCH] Version info for comctl32.dll
"gerard patel" [EMAIL PROTECTED] wrote: ChangeLog: * dlls/comctl32/rsrc.rc Add version info. [...] LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL + +1 VERSIONINFO +FILEVERSION 4, 72, 0, 0 +PRODUCTVERSION 4, 72, 0, 0 +FILEFLAGSMASK VS_FFI_FILEFLAGSMASK +FILEOS VOS_DOS_WINDOWS16 [...] + VALUE "FileVersion", "0.01\000" [...] + VALUE "ProductVersion", "1.00\000" I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls in ONE place. Besides that: 1. I believe that version numbers should be equal in both numerical field and in the string value (0.01 != 4.72 and 1.00 != 4.72). 2. There is no need for excessive \000 at the end of the string value. 3. All well behaving programs do read "VarFileInfo"/"Translation" before retrieving other version information. LANGUAGE does nothing here. 4. Did you try to use my sample application showing version info? 5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve as an example of adding version resources into built-in dlls.
Re: Edit control notification fix
"Andreas Mohr" [EMAIL PROTECTED] wrote: That hack cured the application, but Andreas Well, that's not exactly true. You did not do it "for edit control". You did it for *all* controls in DIALOG_GetControl16() (at least in the patch you sent me). That's why I objected. I just had to :) Sure :-) [...] OK. I can't really judge whether that's correct, as I'm not too much into these kinds of things. Hopefully it's correct :) Well, you can always write your own test app and prove or contest my patch :-) It is really not so hard as it seemed to be... First, using spy++ I discovered that ALL edit controls of that installer have 0x200 style under win2000: therefore style got not corrected or masked upon dialog creation. Second, I took some thought, and wrote test app. My test application sends WM_SETTEXT to the edit control (parent is dialog), then reparents that edit to button (!) in that dialog, makes edit size to be equal new parent client size, brings edit to front and then sends WM_SETTEXT to the edit again. Also I did editing of the text in that edit before and after change of parent, did change focus to and from edit using keyboard and mouse, did copy and paste... All messages to and from dialog and all its controls were spyed and analyzed. That's all.
Re: [PATCH] 16 bits print dialog
"gerard patel" [EMAIL PROTECTED] wrote:
As it's rather unlikely anyone will craft 16 bits specific resources now, I have
mapped the 32 bits resource into 16 bit ones
I did not test if 16 bits printing still works, but the print dialog box displays
again
at least.
There is also a minor fix to cast the return value for the 16 bits hook to 16 bits.
ChangeLog:
* dlls/commdlg/printdlg.c
maps 32 bits resource for 16 bits print dialog.
Gerard, your patch is fine, but I have one tiny comment:
in Win32 hInstance and hModule are the same thing, unlike in Win16.
So, instead of GetModuleHandleA("COMDLG32") you can safely use COMMDLG_hInstance32.
Re: New EnumPrinterDataEx
"Ian Pilcher" [EMAIL PROTECTED] wrote:
+
+/*
+ * The Win32 doc says that RegCloseKey and HeapFree can fail, but it's hard to
+ * imagine why either of them would. And what is the calling function supposed
+ * to do about it anyway?
+ */
+
+#define REGCLOSEKEY(X) \
+{ \
+DWORD ret; \
+ \
+ret = RegCloseKey (X); \
+if (ret != ERROR_SUCCESS) \
+ WARN ("RegCloseKey returned %li\n", ret); \
+}
+
+#define HEAPFREE(X,Y,Z) \
+{ \
+if (HeapFree ((X), (Y), (Z)) == 0) \
+ WARN ("HeapFree failed with code %li\n", GetLastError ()); \
+}
Certainly RegCloseKey and HeapFree can fail if someone will feed garbage to them,
but if you really know that parameters you pass are valid, there is no reason to
check the returned values. Please use simple RegCloseKey and HeapFree instead of
monster macros.
Re: Misc / Unicode
"Francois Gouget" [EMAIL PROTECTED] wrote: rant I checked the other cases and I have this question. Why does everyone use 0 instead of '\0', 0 instead of FALSE, and '\0' instead of NULL? MS even does the reverse and uses NULL in places where '\0' or 0 would have been more appropriate. Man, if you know what you're doing prove it and use the appropriate form: either 0, '\0' or NULL. I know this comes from from someone who just forgot to put a trailing '\0'. But still. /rant IMO it doesn't matter in the most cases, if you do not mix pointer data type (NULL) and others. '\0' == 0, and even better to use 0, because it automatically get casted by the compiler to the appropriate data type.
Re: psdrv: map Courier New to Courier
Gavriel State [EMAIL PROTECTED] wrote: It's at http://opensource.corel.com It hasn't been updated in quite a while, and the last import from WineHQ was back in December '99, I believe. In addition to the font/printing work, there may still be a few other outstanding fixes that haven't made it into the Wine tree - but the only way to tell is probably going to be manual inspection of the diffs. Yes, this is a pain to do for instance cvs log -N corelwine/windows/defwnd.c defwnd.c.log then inspect it for some interesting log message, then do cvs log -N -r1.3 corelwine/windows/defwnd.c defwnd.c.patch cvs diff -u -r 1.2 -r 1.3 corelwine/windows/defwnd.c defwnd.c.patch especially if the patch actually changed several files.
Re: Support for dead keys
Joao clemente [EMAIL PROTECTED] wrote: ... : 2. There are two approaches in implementing support for DK: : a. Do all the character composing in Wine itself, completely ignoring X. You mean, having to write something like those tables that exist to handle the keyboard? Not at all. Those tables already exist and widely used in Wine. I really don't approve that (I still haven't got why can't wine use the X11 keys). I think that using this aproach means having more trouble, having more source code, and depending on a lot of external help to get things to work with every keyboard that has deadkeys... You just don't know by yourself the DK that exist spread all over the world! Really all standard compositing pairs (defined by Unicode) will work. Any user-defined custom DKs will not. As far as I understand there is a possibility to define any character sequence and assign it to some DK. : b. Delegate all the character composing tasks to Xlib. This will allow the user : to have his/her familiar environment, but will lead to some cases, when I like this one better... I think that wine will need less source code to work, and one only needs to have X11 configured properly so that he has all keys working right. That way is ONE place do get the keyboard to work (at X11 keyb config), ONE less place to worry about maintenance of wine... On the one hand you are right. Having Xlib to do all DK composition is an easy way to go. But there are (at least in theory) another drivers. Having DK support in Wine itself will simplify creating those drivers, assuming that new driver should not worry about character composing, only deliver keystrokes. But such an internal support for DKs in Wine core should not affect any driver at all: driver just will never say "I have DK for processing", it just will silently process it itself. In other words, I think this is more "wine developer friendly" and "wine user friendly"
Bug report: LOAD_LIBRARY_AS_DATAFILE and accessing resources
Hello all. Some time ago, when I was testing standard USER controls with the new unicode stuff, I encountered the following problem not related to controls at all. One of my test applications is Adobe PageMaker 6.5. It loads its plugins and initializes menu with strings loaded from the plugin module resources and describes functionality of that plugin. Currently menu has only garbage. Investigation showed, that PM loads module with LOAD_LIBRARY_AS_DATAFILE and then does LoadStringA to retrieve needed data. The problem is that affected module has file alignment 0x200 and all resource functions in Wine use VirtualAddress instead of PointerToRawData. Moreover, currently there is no way in Wine to distinguish module loaded normally from module loaded as data file. Quick test in Win2000 shows that if no flags are specified, module gets loaded at address as in headers, if LOAD_LIBRARY_AS_DATAFILE is specified, module gets loaded at arbitrary base address and returned to application hModule is incremented by 1. I'll just not dare to fix this issue myself because too many places in Wine should be correctly addressed, but I'm not expert in the Wine PE loader.
Re: I've tried to change keyboard table.. No good...
"Joao clemente" [EMAIL PROTECTED] wrote: I was thinking of changing the keybord settings in X11 so that I try to find out something else about this matter... Do you think it's worth triying? ( lame question : I do that in Xf86config file, right?) Btw... do you think I can read some documentation on something so that I can be of more assistance for this? Maybe some X11 documentation or so? I think that XLookupString call should be replaced by XmbLookupString or even better by XwcLookupString. But I can not find good sample how to use them: information about input method and input context is missing in the man.
Re: I've tried to change keyboard table.. No good...
Ove Kaaven [EMAIL PROTECTED] wrote: [skipped] 2. Accent characters in different code pages has different mappings to unicode characters. Perhaps we just have to create internal table with mapping [combining character in code page] - [combining character in unicode]? Since the last deadkey is stored by the keyboard driver, it should have been possible to just use the X11 deadkey stuff instead of Unicode composition, but whatever... Sure, X11 should do it for us. Hints, please: what X11 dead-key stuff? I'll try to implement proper dead-key handling then...
Re: I've tried to change keyboard table.. No good...
Ove Kaaven [EMAIL PROTECTED] wrote:
Sure, X11 should do it for us. Hints, please: what X11 dead-key stuff?
That's a good question. I don't really know, and don't have time to read
the Xlib manual right now (have to catch a flight in a few hours), but I
suspect it might have something to do with this XComposeStatus parameter
to XLookupString.
Could anybody check, whether this tiny patch helps use dead keys?
--- cvs/wine/windows/x11drv/keyboard.c Wed Jan 3 06:39:15 2001
+++ wine/windows/x11drv/keyboard.c Thu Jan 18 23:22:12 2001
@@ -1469,6 +1469,7 @@
INT ret;
int keyc;
BYTE lpChar[2];
+static XComposeStatus cs;
if (scanCode==0) {
/* This happens when doing Alt+letter : a fake 'down arrow' key press
@@ -1525,7 +1526,7 @@
}
else TRACE("Found keycode %d (0x%2X)\n",e.keycode,e.keycode);
-ret = TSXLookupString(e, (LPVOID)lpChar, 2, keysym, NULL);
+ret = TSXLookupString(e, (LPVOID)lpChar, 2, keysym, cs);
if (ret == 0)
{
BYTE dead_char;
@@ -1599,7 +1600,7 @@
}
TRACE_(key)("ToUnicode about to return %d with char %x %s\n",
- ret, bufW ? bufW[0] : 0, bufW ? "" : "(no buffer)");
+ ret, (bufW ret) ? bufW[0] : 0, bufW ? "" : "(no buffer)");
return ret;
}
Re: I've tried to change keyboard table.. No good...
"Francois Gouget" [EMAIL PROTECTED] wrote: Well, I'm not in France but I do sometimes use my qwerty keyboard in 'US-International' mode so that I can get some of these French characters... via dead-keys. Of course it seems like half the Unix applications don't support dead keys and the other half don't support accents. Actually support for dead keys can be implemented now, since Alexandre added support for composite unicode characters. I even wrote several tests to prove the concept and do 2-1 and 1-2 character conversions in WideCharToMultiByte and MultiByteToWideChar. But I have some problems: 1. Actually I don't know how to generate dead key sequence that will modify next character, because cyrillic has no this "feature". 2. Accent characters in different code pages has different mappings to unicode characters. Perhaps we just have to create internal table with mapping [combining character in code page] - [combining character in unicode]? Then in x11drv.ToUnicode just do check: if previous pressed key was a dead key, then convert both characters to unicode and do WideCharToMultiByte to combine them into a single character and MultiByteToWideChar to convert combined character to unicode? P.S. It was my thoughts. It they are too messy for you, excuse me - I have no strong understanding of dead keys at all, just results of reading DDK and trial and error.
Bug report: command line for 16-bit application
Hello all. While working on the problems with scrolling in the 16-bit notepad, I tried to avoid loading file via File-Load-etc, but use command line instead: wine -debugmsg +edit,+scroll notepad -- new.txt ~/notepad.log. Unfortunately notepad seems to not correctly understand its command line and asks to create "ew.txt". I didn't look at it yet (perhaps later), but I'm using a workaround now: instead of new.txt I type " new.txt" and it works.
Re: Solve remaining problems with scroll messages in the edit control
"gerard patel" [EMAIL PROTECTED] wrote: Could you please add if(!(es-style ES_MULTILINE)) return; at the start of EDIT_UpdateScrollInfo and try that patch again? Yes, it works with this change; this is not surprising, do you intend this as a test or as a real fix ? It was suggested as a test for the sake of finding real fix. In the latter case, I have tried to do a small app creating a window with a scrollbar and create a multiline control with no scrollbar; in this specific case, the scrollbar is not disabled, but its range is changed - this does not happen with the same app under NT4. This means, that the whole fix for 16-bit notepad is a hack around bugs in 16-bit user.exe. Now I wonder how similar 16-bit test application will behave under 3.1/95/98/NT/2000. Perhaps my wishes are unreal. As it's a test app I wrote with Bcb4, I can send it to you if you want it. I want 16-bit test now. Could you make this one please? I'll try to find bc3.1 somewhere too.
Re: Solve remaining problems with scroll messages in the edit control
"gerard patel" [EMAIL PROTECTED] wrote: While your patch makes the scrolling behaviour of the edit control better, are you sure you could not get the same effect without this change ? Yes, all works fine with this line in place. Alexandre, please ignore this one-liner change for scroll.c. Or should I resend the whole patch?
Re: Solve remaining problems with scroll messages in the edit control
"gerard patel" [EMAIL PROTECTED] wrote: Wait, there is at least another problem with this patch. It's about the access to the edit's parent control. Try this with your patch : use any 32 bit program (I tested with the Word 97 viewer, this happens also with Forte Free Agent32) to open a file; select a file and click a second time, the file name is edited (the listview control creates an edit control to allow this). The scrollbar for the listview is immediately disabled. Could you please add if(!(es-style ES_MULTILINE)) return; at the start of EDIT_UpdateScrollInfo and try that patch again?
Re: Edit control 16 bits (was : Combobox fix)
This patch works fine for me. Could you please test it too?
--- cvs/wine/controls/edit.cFri Jan 5 15:21:35 2001
+++ wine/controls/edit.cTue Jan 9 22:13:46 2001
@@ -1482,25 +1482,22 @@
}
if (!es-text) {
CHAR *textA = NULL;
- INT countA = 0;
+ UINT countA = 0;
BOOL _16bit = FALSE;
if(es-hloc32W)
{
- /*TRACE("Locking 32-bit UNICODE buffer\n");*/
- es-text = LocalLock(es-hloc32W);
-
if(es-hloc32A)
{
TRACE("Synchronizing with 32-bit ANSI buffer\n");
- countA = LocalSize(es-hloc32A);
textA = LocalLock(es-hloc32A);
+ countA = strlen(textA) + 1;
}
else if(es-hloc16)
{
TRACE("Synchronizing with 16-bit ANSI buffer\n");
- countA = LOCAL_Size(wnd-hInstance, es-hloc16);
textA = LOCAL_Lock(wnd-hInstance, es-hloc16);
+ countA = strlen(textA) + 1;
_16bit = TRUE;
}
}
@@ -1511,7 +1508,31 @@
if(textA)
{
- MultiByteToWideChar(CP_ACP, 0, textA, countA, es-text,
es-buffer_size);
+ HLOCAL hloc32W_new;
+ UINT countW_new = MultiByteToWideChar(CP_ACP, 0, textA, countA, NULL,
+0);
+ TRACE("%d bytes translated to %d WCHARs\n", countA, countW_new);
+ if(countW_new es-buffer_size + 1)
+ {
+ UINT alloc_size = (countW_new * sizeof(WCHAR) + GROWLENGTH - 1)
+~(GROWLENGTH - 1);
+ TRACE("Resizing 32-bit UNICODE buffer from %d+1 to %d WCHARs\n",
+es-buffer_size, countW_new);
+ hloc32W_new = LocalReAlloc(es-hloc32W, alloc_size, LMEM_MOVEABLE
+| LMEM_ZEROINIT);
+ if(hloc32W_new)
+ {
+ es-hloc32W = hloc32W_new;
+ es-buffer_size = LocalSize(hloc32W_new)/sizeof(WCHAR) - 1;
+ TRACE("Real new size %d+1 WCHARs\n", es-buffer_size);
+ }
+ else
+ WARN("FAILED! Will synchronize partially\n");
+ }
+ }
+
+ /*TRACE("Locking 32-bit UNICODE buffer\n");*/
+ es-text = LocalLock(es-hloc32W);
+
+ if(textA)
+ {
+ MultiByteToWideChar(CP_ACP, 0, textA, countA, es-text,
+es-buffer_size + 1);
if(_16bit)
LOCAL_Unlock(wnd-hInstance, es-hloc16);
else
@@ -2140,25 +2161,60 @@
if (es-hloc32W) {
CHAR *textA = NULL;
BOOL _16bit = FALSE;
- INT countA = 0;
+ UINT countA = 0;
+ UINT countW = strlenW(es-text) + 1;
if(es-hloc32A)
{
+ UINT countA_new = WideCharToMultiByte(CP_ACP, 0, es-text, countW,
+NULL, 0, NULL, NULL);
TRACE("Synchronizing with 32-bit ANSI buffer\n");
+ TRACE("%d WCHARs translated to %d bytes\n", countW, countA_new);
countA = LocalSize(es-hloc32A);
+ if(countA_new countA)
+ {
+ HLOCAL hloc32A_new;
+ UINT alloc_size = (countA_new + GROWLENGTH - 1) ~(GROWLENGTH
+- 1);
+ TRACE("Resizing 32-bit ANSI buffer from %d to %d bytes\n",
+countA, alloc_size);
+ hloc32A_new = LocalReAlloc(es-hloc32A, alloc_size,
+LMEM_MOVEABLE | LMEM_ZEROINIT);
+ if(hloc32A_new)
+ {
+ es-hloc32A = hloc32A_new;
+ countA = LocalSize(hloc32A_new);
+ TRACE("Real new size %d bytes\n", countA);
+ }
+ else
+ WARN("FAILED! Will synchronize partially\n");
+ }
textA = LocalLock(es-hloc32A);
}
else if(es-hloc16)
{
+ UINT countA_new = WideCharToMultiByte(CP_ACP, 0, es-text, countW,
+NULL, 0, NULL, NULL);
TRACE("Synchronizing with 16-bit ANSI buffer\n");
+ TRACE("%d WCHARs translated to %d bytes\n", countW, countA_new);
countA = LOCAL_Size(wnd-hInstance, es-hloc16);
+ if(countA_new countA)
+ {
+ HLOCAL16 hloc16_new;
+ UINT alloc_size = (countA_new + GROWLENGTH - 1) ~(GROWLENGTH
+- 1);
+ TRACE("Resizing 16-bit ANSI buffer from %d to %d bytes\n",
+countA, alloc_size);
+ hloc16_new = LOCAL_ReAlloc(wnd-hInstance, es-hloc16,
+alloc_size, LMEM_MOVEABLE |
Re: Combobox fix
"gerard patel" [EMAIL PROTECTED] wrote:
Do you have an application that doesn't work after the edit control rewrite?
Notepad 16 bits. The version I use for testing was coming with Wfw 3.11 I think.
I have searched a bit and the problem seems to be the buffer length.
The problem is that current code doesn't synchronize the sizes
of external and internal unicode buffers.
Did you consider to keep an ansi buffer for ansi apps ? I don't know how easy
a double compilation would be to implement inside Wine (like it's done for
applications,
with a call like GetText generating GetTextA or GetTextW according to the state
of the UNICODE flag), but maybe it could have made the code simpler and somewhat
more efficient.
Really it was an approach that I've tried to implement first. But look,
there are multibyte characters out there. So working with multibyte buffer
is very ugly by CharNext() etc., and even more slower than simple synchronization
(WideCharToMultiByte and MultiByteToWideChar are quite fast).
Please try this patch (I have no 16-bit notepad):
--- cvs/wine/controls/edit.cFri Jan 5 15:21:35 2001
+++ wine/controls/edit.cMon Jan 8 18:28:28 2001
@@ -1482,14 +1482,12 @@
}
if (!es-text) {
CHAR *textA = NULL;
- INT countA = 0;
+ UINT countA = 0;
BOOL _16bit = FALSE;
+ UINT countW_new;
if(es-hloc32W)
{
- /*TRACE("Locking 32-bit UNICODE buffer\n");*/
- es-text = LocalLock(es-hloc32W);
-
if(es-hloc32A)
{
TRACE("Synchronizing with 32-bit ANSI buffer\n");
@@ -1509,6 +1507,22 @@
return;
}
+ countW_new = MultiByteToWideChar(CP_ACP, 0, textA, countA, NULL, 0);
+ if(countW_new es-buffer_size)
+ {
+ HLOCAL hloc32W_new;
+ UINT alloc_size = (countW_new * sizeof(WCHAR) + GROWLENGTH - 1)
+~(GROWLENGTH - 1);
+ TRACE("Resizing 32-bit UNICODE buffer to %d bytes\n", alloc_size);
+ hloc32W_new = LocalReAlloc(es-hloc32W, alloc_size, LMEM_MOVEABLE |
+LMEM_ZEROINIT);
+ if(hloc32W_new)
+ es-hloc32W = hloc32W_new;
+ else
+ WARN("FAILED! Will Synchronize partially\n");
+ }
+
+ /*TRACE("Locking 32-bit UNICODE buffer\n");*/
+ es-text = LocalLock(es-hloc32W);
+
if(textA)
{
MultiByteToWideChar(CP_ACP, 0, textA, countA, es-text,
es-buffer_size);
@@ -2140,18 +2154,39 @@
if (es-hloc32W) {
CHAR *textA = NULL;
BOOL _16bit = FALSE;
- INT countA = 0;
+ UINT countA = 0;
+ UINT countA_new = WideCharToMultiByte(CP_ACP, 0, es-text,
+es-buffer_size, NULL, 0, NULL, NULL);
if(es-hloc32A)
{
TRACE("Synchronizing with 32-bit ANSI buffer\n");
countA = LocalSize(es-hloc32A);
+ if(countA_new countA)
+ {
+ HLOCAL hloc32A_new;
+ TRACE("Resizing 32-bit ANSI buffer to %d bytes\n", countA_new);
+ hloc32A_new = LocalReAlloc(es-hloc32A, countA_new,
+LMEM_MOVEABLE | LMEM_ZEROINIT);
+ if(hloc32A_new)
+ es-hloc32A = hloc32A_new;
+ else
+ WARN("FAILED! Will Synchronize partially\n");
+ }
textA = LocalLock(es-hloc32A);
}
else if(es-hloc16)
{
TRACE("Synchronizing with 16-bit ANSI buffer\n");
countA = LOCAL_Size(wnd-hInstance, es-hloc16);
+ if(countA_new countA)
+ {
+ HLOCAL16 hloc16_new;
+ TRACE("Resizing 16-bit ANSI buffer to %d bytes\n", countA_new);
+ hloc16_new = LOCAL_ReAlloc(wnd-hInstance, es-hloc16,
+countA_new, LMEM_MOVEABLE | LMEM_ZEROINIT);
+ if(hloc16_new)
+ es-hloc16 = hloc16_new;
+ else
+ WARN("FAILED! Will Synchronize partially\n");
+ }
textA = LOCAL_Lock(wnd-hInstance, es-hloc16);
_16bit = TRUE;
}
Re: Edit control 16 bits (was : Combobox fix)
"gerard patel" [EMAIL PROTECTED] wrote: Please try this patch (I have no 16-bit notepad): snip edit patch I have tested it a bit, it seems to work fine as long as I edit text and use disk access; I have tried clipboard (pasting text from the clipboard into Notepad 16) and it was not pretty though (basically I got garbage; before the patch it seemed to work) I have to admit I have not yet investigated, not even tested very seriously. If you don't have a brillant idea on why, as far as I am concerned this problem can wait next until next week end. I'll try to find somewhere and borrow 16-bit notepad. If the problem will not be solved within this week, welcome to fix it yourself.
Re: Combobox fix
"gerard patel" [EMAIL PROTECTED] wrote: Do you have an unicode version of listbox in the works ? Yes, I'm working on it right now. After a general way of testing I'll send it to wine-patches. Since the combobox is unicode, cb_findtext* apis seem to have problems; I think it should not happen if listbox is unicode, but if an unicode listbox is not done in a near future, these could be fixed at the combobox level... After listbox will be unicoded, welcome to report any bugs... While talking about unicode... The edit control buffer is unicode now, are Ansi apps that are accessing the buffer directly (EM_GETHANDLE) supposed to work ? Even 16-bit EM_GETHANDLE16 should work. It works by allocating alias buffer on EM_GETHANDLE/EM_GETHANDLE16 call and does synchronization with external buffer every time when internal unicode buffer is accessed. Do you have an application that doesn't work after the edit control rewrite?
Re: [PATCH] clipboard
"gerard patel" [EMAIL PROTECTED] wrote: [...] - in X11DRV_IsClipboardFormatAvailable a call to CLIPBOARD_IsPresent had disappeared; adding it again get back the text exchange between Wine applications. X11 clipboard driver should call only exported win32 functions IMO. Driver doesn't need to know about internal clipboard cache at all. All it should do is to provide a way of setting clipboard data to the X buffer and a way of getting data from it. Not more not less. Anyway when driver is called, CLIPBOARD_IsPresent should be already tested. Except this your patch looks right for me.
Re: GlobalAlloc/GlobalReAlloc/GlobalLock fixes
"Alexandre Julliard" [EMAIL PROTECTED] wrote: GlobalAlloc/GlobalReAlloc: Make allocations with granularity 32 bytes. Clear error on success in GlobalLock as Windows does. What version does this? NT 4 definitely doesn't set last error on success (and it doesn't seem to round up the size either). I got this results running my test app that creates unicode and ansi edit controls and dumps their contents. Memory blocks are always 32-byte aligned. I explicitly check last error after EM_GETHANDLE and LocalLock on it. Both NT4 and Win2000 return 0 for GetLastError. Dmitry.
Re: GlobalAlloc/GlobalReAlloc/GlobalLock fixes
"Alexandre Julliard" [EMAIL PROTECTED] wrote: I got this results running my test app that creates unicode and ansi edit controls and dumps their contents. Memory blocks are always 32-byte aligned. Couldn't this be because the edit control does the rounding? I made another test and it confirmed that you are right. I'll send an update for the edit control. I explicitly check last error after EM_GETHANDLE and LocalLock on it. Both NT4 and Win2000 return 0 for GetLastError. This could be because it was already 0 before the call, or because some other function cleared it. LocalLock definitely does not set last error on my machine. You are right again. Test confirms that too. Probably I spent too many time with edit and forgot about simple things around... Dmitry.
Re: ANNOUNCE patch
Nerijus Baliunas [EMAIL PROTECTED] wrote: Sorry, I didn't know that. I thought it is/was the same [EMAIL PROTECTED] Updated patch: [...] -Patches should be submitted to "[EMAIL PROTECTED]". Please don't +Patches should be submitted to "[EMAIL PROTECTED]". Please don't Do you know that to post to wine-patches someone MUST be subscribed first? It is a bad idea to FORCE casual contributor to subscribe to a high traffic mailing list. I believe that the point was to avoid that.
Re: Locale Question
Jon [EMAIL PROTECTED] wrote: I'm having a problem implementing locale related functionality for crtdll. Basically, I need to get an LCID from a locale string, rather than from a locale id as used by the MAKELCID macro. Which crtdll function does need this? There doesn't appear to be a way to do this using the (documented) windows API. I think that Win32 API should satisfy nearly any crtdll function implementation. Looking in ole/ole2nls.c I see that GetUserDefaultLangID seems to do the processing I want, but it reads from environment variables instead of a passed in string. Given that I'm not supposed to call internal functions from the dll, does anyone have any ideas how best to do this? Is it OK to add a suitable function to ole2nls.c and then call it from crtdll? As Patrik already replied - no. Although functions in that file belong to kernel32, not to 16-bit ole2nls.
Re: Generate unicode CHAR messages
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OOPS, sorry. I have email only. Because there is www4mail, that means I have ftp (if I know where) and limited http. If I have wasted your time with a bug that ia already fixed, I am sorry, I really hoped I could help. And busted my arse to do it. But I would like to know, where is the patch I missed :-). Sorry, you have missed too many patches. To name one of them: ChangeSet ID: 974329997975647440180182 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard@wine2. 00/11/15 18:13:17 Modified files: include: winproc.h windows: message.c winproc.c Log message: Dmitry Timoshkov [EMAIL PROTECTED] Added mapping to/from unicode for WM_CHAR, WM_DEADCHAR, WM_SYSCHAR, WM_SYSDEADCHAR messages. Patch: http://cvs.winehq.com/patch.py?root=/opt/cvs-commitlogs=/opt/cvs-commit/CVSROOT/winecommitlogid=97 4329997975647440180182 Revision ChangesPath 1.6 +2 -2 wine/include/winproc.h 1.80 +4 -3 wine/windows/message.c 1.44 +60 -9 wine/windows/winproc.c --- Dmitry.
Re: Generate unicode CHAR messages
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 16 Nov 2000, Dmitry Timoshkov wrote: Hello. Changelog: Dmitry Timoshkov [EMAIL PROTECTED] Always generate unicode CHAR messages. Good day! This broke my mail app. I have been running with it 'til now, so I guess you could say it isn't very broke, but if I have to change my phone number I am SOL. It won't accept input in one text-entry item (?) of a dailog. I have before and after +message,+key,+text logs, but even after removing the beginning stuff and grepping out the GetTextExtentPoint they are still to big to mail, unless you don't mind gzipped and split. If I have missed a correction or some later patch that sets it right, please point it out. I just pick from wine-patches and hope for the best. Probably this is a case where ANSI - Unicode message conversions don't work correctly. I already mailed to Alexandre my preliminary patch (which doesn't work) for suggestions. CreateWindowExA/W should always allocate new window proc and subclass window in the case if class was registered with a not compatible function type (A instead of W and vice versa). IsWindowUnicode should return TRUE for windows created by CreateWindowExW without reference to by which version of RegisterClass (A or W) base class was registered. Currently in Wine winproc handling does something wrong. Right now I'm investigating it further. Until it will be fixed, switching to unicode of the internal USER classes risks break too many applications. But perhaps it is completely unrelated problem. Could you send me both traces: before and after my patch was applied (+relay,+key,+message)?
Re: DlgDirList() in civ2
Ove Kaaven [EMAIL PROTECTED] wrote: The first crash in civ2 that I didn't have a patch for goes like this: First, it creates (hidden) windows and stuff, and Call USER.100: DLGDIRLIST(0x01bc,0x07771dca "*.*",0x0064,0x,0x4000) ret=03e7:0ed8 ds=0777 ... (DDL_DRIVES) Ret USER.100: DLGDIRLIST() retval=0x0001 ret=03e7:0ed8 ds=0777 ... Someone know what must be done with DlgDirList() (LB_DIR) to make this work, or at least how it's supposed to behave? Apparently if only the DDL_DRIVES (0x4000) flag is set, nothing should be listed except drives (at least according to old bcw 3.1 doc)...
Re: Fix for selected bitmap menu items
Okay, things are simpler than they look. Eyes are afraid - hands are doing (russian byword). I have wrote a very simple sample that demonstrates bitmaps in the menu (mono and 16 colors, you can add your own of course). Selected color bitmaps are inverted in both win95 and win98, but monochrome look very different. Do we need *exact* emulation here? Dmitry. menu.zip
Re: a patch for supporting DBCS
TAKESHIMA Hidenori [EMAIL PROTECTED] wrote: ChangeLog: dlls/comctl32/datetime.c dlls/comctl32/header.c dlls/comctl32/rebar.c dlls/comctl32/status.c dlls/comctl32/toolbar.c dlls/comctl32/treeview.c dlls/commdlg/filedlg.c dlls/shell32/shlfolder.c dlls/shlwapi/path.c: fix for supporting DBCS. First, I should say that it is a wrong way to fix DBCS. You could note, that work in progress on converting the standard USER controls to unicode. The same should be done for a common controls dll. Second, you are somewhat strange mixing WtoA/AtoW functions (that should not be used at all IMHO) with WideCharToMultiByte/MultiByteToWideChar. Dmitry.
Re: PolyDraw implementation
mark dufour [EMAIL PROTECTED] wrote: Here's another implementation, for the PolyDraw function. Like AngleArc, this is NT-only. I installed NT for the occasion and tried out all possible situations I could think of. I also found a bug in my AngleArc implementation, so I'm submitting that one again in the same patch. My previous AngleArc patch hasn't made into the CVS tree yet, so I didn't know whether to send the full implementation again or not. + +if( dwRadius 0 ) return FALSE; Sorry, I have not pointed out to this earlier, but DWORD == unsigned long, and therefore just can't be 0. And it would be a good idea to not use C++ comments in the pure C code. Dmitry.
Re: ForteFreeAgent32 accelerators broken
Ove Kaaven [EMAIL PROTECTED] wrote: Gerard is from France. French keyboards don't have a QWERTY layout, they have AZERTY. I suspect Gerard just got the key reassigned to W... Ah! It expalains all of it! I should notice it earlier by examining more carefully the keyboard layouts (particularly main_key_FR). Sorry. Gerard, if you have no time to patch keyboard.c I'll send the patch tomorrow. Dmitry.
Re: Keyboard input and current locale: first attempt
Ove Kaaven [EMAIL PROTECTED] wrote: Some problems that I tried to solve: 1. I didn't find way to make to work XLookupString with setlocale(LC_CTYPE,""). I don't know exactly how this works, but what is your locale settings? I know that glibc and Xlib disagrees somewhat on the format of the strings, and that there are aliasing hacks to work around that... I tried nearly all possible settings and their combinations for LANG and LC_ALL: ru_RU, ru_SU, ru_RU.koi8-r, ru_SU.koi8-r, ru_RU.iso-8859-5, ru_SU.iso-8859-5 ... but without success. Does Wine need that setlocale()? All works without it fine. 2. I modified keyboard detection code to assign virtual key codes along with the found scan codes because virtual key codes are always the same for english keyboard layout and other (russian for me) keyboard layout in windows. But for some reason I doubt this is the case for DVORAK layouts, or German QWERTZ layouts, is it? (Admittedly, no DVORAK layouts have been added yet, but maybe someday someone wants to run Terminal Server Client using a DVORAK keyboard...) Good point. I definitely missed it. I suggest adding a couple of fields to the main_key_tab structure... - WORD x11_codepage, where you can put those cp20866 values. The ansi_codepage was supposed to be the Windows codepage and match the locale settings (although neither ansi_codepage nor oem_codepage is actually used for anything at the moment). I believe that keyboard layouts should have layout_cp field, that actually will replace those misleading ansi_codepage and oem_codepage, and possibly lang too. Perhaps all layouts should have name field or comment, which will be displayed in message "Your keyboard layout was not found... we will use "Polish (programmer's) keyboard layout" instead". What do you think? The keyboard detection could perhaps add a ansi_codepage == GetACP() check someday, for example... I think it is not needed. Field layout_cp should serve for it. - const int (*vkey)[MAIN_LEN], which could point to e.g. main_vkey_qwerty, main_vkey_qwertz, main_vkey_dvorak, etc, instead of having just one main_key_vkey Yes, very good proposal. I'll make main_vkey_qwerty, but I have no idea about others. And how about main_key_scan_querty, main_key_scan_dvorak and others? BTW, did I make any errors while restoring VK_* key codes for your keyboard? Dmitry.
Re: Disabled windows can't be resized by WM
gerard patel [EMAIL PROTECTED] wrote: [...] I investigated further, without great success. It's difficult to trace since the end of the trace disappear, I ended up adding a sync() call at this point. What happens is that the main window (the one being disabled) get an UnmapNotify event almost immediately after the new size is set. That's incorrect as it's not what the program asked. If I comment only the line setting the min and max height, the main window is not unmapped and the app works correctly. The only hack I found to eliminate the crash it to don't have min=max, for example : size_hints-min_width = wnd-rectWindow.right - wnd-rectWindow.left; size_hints-max_width = size_hints-min_width + 1; size_hints-min_height = wnd-rectWindow.bottom - wnd-rectWindow.top; size_hints-max_height = size_hints-min_height + 1; No crash then... I just can't believe! That means, that this code (already existing in x11drv), will crash for you if, say, application shows "About" dialog and then will center it relatively main window by SetWindowPos. Could you confirm it? Though, this may mean, that wnd-rectWindow has wrong or just zero size for you. If this is the case, then I couldn't help to trace it, it will be your job, sorry. Dmitry.
Re: Disabled windows can't be resized by WM
James Hatheway [EMAIL PROTECTED] wrote: I don't think your patch is causing these problems. I have these two same Balsam for my soul... problems in the app that I am debugging, without your patch applied. (I get this problem with KDE 1.1.2) For me, when the app starts up it has a normal rectangular window and only has the close button. When a region is applied to its window with SetWindowRgn(), and then a normal rectangular window is restored with a SetWindowRgn() and a NULL region, the window doesn't have a system menu or the close button. ... but I really see this only with my patch. I don't have time to look at this bug at the moment, unfortunately. I just thought I'd let you know that I don't think your patch is the actual cause of the problem. I just hope, that this mystery bug will be fixed by the joint efforts. Dmitry.
Re: Disabled windows can't be resized by WM
gerard patel [EMAIL PROTECTED] wrote: [...] If I test this patch with winedt (available from www.winedt.com), my X-server crashes when I try to load the Options dialog box. Winedt is a program written in Delphi I think; Borland has a very special system to simulate modal dialog boxes; I see the same problem with Bcb4. It is very strange. Theoretically my patch should not affect on the any windows specific features of program, it just instructs WM. I'll download winedt and try to figure out what happens. Attachment Converted: g:\eudora\eudora\attach\wnd1.dif You can use diffs against the whole tree : it saves time for people wanting to try your patches. Sure, but usually I have much more then a couple of modified files in my tree and not all of them belong to the same single patch. Dmitry.
Re: Disabled windows can't be resized by WM
gerard patel [EMAIL PROTECTED] wrote: If I test this patch with winedt (available from www.winedt.com), my X-server crashes when I try to load the Options dialog box. Winedt is a program written in Delphi I think; Borland has a very special system to simulate modal dialog boxes; I see the same problem with Bcb4. I have downloaded WinEdt 5.1. But I didn't manage to crash it with my patch. My WM is KDE 1.1.1. Although WinEdt doesn't crash for me, it exhibits some flaws in the way Wine manages windows. For instance main WinEdt window has only close box on it, though in Windows all three standard buttons showed. My patch adds another "feature": after any dialog box was shown, bitmap on the system menu along with the sole close box on the main window caption disappear and don't get restored after the main window was enabled back. But I'm not a X programming expert, and I couldn't say what is happening wrong. I just reused code, which already works in wine/windows/x11drv/wnd.c, lines 661-678, and it worked fine for enabling/disabling windows in my test programs. My experiments with replacing XGetWMSizeHints/XSetWMSizeHints by XGetWMNormalHints/XSetWMNormalHints didn't change anything. Man page for them doesn't mention any special tricks that could be used. Dmitry.
Problems with repainting menu
Hello all. My app have a problem with repainting its menu in managed mode. Funny, but it can be reproduced with old 16-bit clock.exe from windows 3.1. How to reproduce: Double clicking on the client area switches clock modes: with menu (and caption) and without menu (and caption in not managed mode.) After switching to the mode with menu, menu isn't shown until window is resized/minimized/maximized. After several hours of attempts to find culprit, I was failed. Can someone help here? Dmitry.
EnumResourceTypes and 16-bit modules
Hello all. The question is short: is EnumResourceTypes supposed to work with 16-bit modules? I ask because I don't know what to do: simply avoid crashing by checking HIWORD(hModule), or implement a full working solution. Dmitry.
Problems with inlined strlenW and gcc 2.95.2 with -O2
Hello all. Some traces +mdi and version of strlenW that prints result before exit: ... trace:mdi:MDI_UpdateFrameText AFTER lstrcpyW(lpBuffer): L"Adobe PageMaker 6.5" trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5", L" - [") strlenW(): 19 -- right trace:mdi:MDI_UpdateFrameText AFTER strcatW: L"Adobe PageMaker 6.5 - [" trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5 - [", L"") strlenW(): 19 -- wrong trace:mdi:MDI_UpdateFrameText AFTER strcatW: L"Adobe PageMaker 6.5" trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5", L"]") strlenW(): 19 -- right trace:mdi:MDI_UpdateFrameText AFTER strcatW: L"Adobe PageMaker 6.5]" ... and more: ... trace:mdi:MDI_UpdateFrameText AFTER lstrcpyW(lpBuffer): L"Adobe PageMaker 6.5" trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5", L" - [") strlenW(): 19 -- right trace:mdi:MDI_UpdateFrameText AFTER strcatW: L"Adobe PageMaker 6.5 - [" trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5 - [", L"Untitled-1") strlenW(): 19 -- wrong trace:mdi:MDI_UpdateFrameText AFTER strcatW: L"Adobe PageMaker 6.5Untitled-1" trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5Untitled-1", L"]") strlenW(): 29 -- right trace:mdi:MDI_UpdateFrameText AFTER strcatW: L"Adobe PageMaker 6.5Untitled-1]" ... Some workarounds: 1. Without -O2 - all right. 2. Disabling assembly in strlenW - all right. Ideas? Dmitry.
Re: Thunking problem is partially solved
Ulrich Weigand [EMAIL PROTECTED] wrote:
I've now modified the CallTo16Register routines to save (some) register
values possibly modified by the called 16-bit routine back into the
CONTEXT86 structure. Saving *all* registers is difficult (or at least
would create more overhead), so I decided to save only those registers
typically modified: EAX, EBX, ECX, EDX, EBP, and ESP.
This done, it is now possible to find out the proper number of popped
arguments from the SP value in the CONTEXT86. I've updated the various
flat thunk routines accordingly.
Could you try out the appended patch, whether it fixes your problem?
Ulrich, thank you very much. Adobe PageMaker 6.52 is in a fully workable
state now. Page layout, fonts, images, metafiles - just all that I have
tested so far! CodeWeavers, time to call to Adobe?
Though very little patch should be applied after your one:
--- relay.c Mon Sep 11 13:42:06 2000
+++ relay.c Mon Sep 11 13:33:38 2000
@@ -341,7 +341,7 @@
{
CONTEXT86 *context = (CONTEXT86 *)ret_val;
-DPRINTF("CallTo16() ss:sp=%04x:%04x\n",
+DPRINTF("CallTo16() ss:sp=%04x:%04x retval=0x%08x\n",
SELECTOROF(NtCurrentTeb()-cur_stack),
OFFSETOF(NtCurrentTeb()-cur_stack), ret_val);
DPRINTF(" AX=%04x BX=%04x CX=%04x DX=%04x BP=%04x SP=%04x\n",
Thank you again.
Dmitry.
Re: Glibc
gerard patel [EMAIL PROTECTED] wrote: [big snip] If other had similar experiences, it would probably a good thing to include in the how-to or faq that while Wine will work correctly for most programs with glibc 2.0, it works best with glibc 2.1 (apart from the infamous Redhat 2.1.3 problem, of course) I just want to say, that Wine has no problems with glibc, since it no more uses glibc's unicode conversion routines. Dmitry.
PageMaker and thunking
Hello all. I'm still trying to solve problems with PageMaker and thunking... Assuming, that problems arise with using QT_Thunk/SMapLS_IP_EBP_8/SUnMapLS_IP_EBP_8 functions (i.e. Win95 thunks), I guessed that -winver nt40 will solve at least some part of the problem. But PM always used Win95 thunks: with nt40 or win95. Traces showed, that PM uses GetProcAddress to decide, which type of thunking to use. After commenting mentioned above functions in kernel32.spec, it confirmed my guess, and PM now opens and actually draws the whole page layout! Though some problems persist (with Syslevel locking in PlayMetaFile for instance), but progress is here! Now I'm in embarrassment: to really continue hacking PageMaker, I need to choose some way: either try to solve problems with Win95-type thunking (but nobody except Andreas Mohr actually tried to help me with absolutely unknown for me subject), or try to implement some sort of hack around GetProcAddress to simulate presence and absence of the bunch of functions. The latter is very obscured idea and I don't like it. What to do? Dmitry.
Re: Small correction for path stripping in builtin32.c
Alexandre Julliard [EMAIL PROTECTED] wrote: "Dmitry Timoshkov" [EMAIL PROTECTED] writes: Changelog: Small correction for path stripping. This breaks paths that contain both '/' and '\'. What are you trying to fix? Well, while I searched for a real culprit of crash with printer driver loading in PageMaker (solved by "Fix buffer overflow in builtin.c" patch), I found, that if driver name contains '/' and '\', BUILTIN32_dlopen will fail: for instance, if name is "c:\path/driver.drv", BUILTIN32_dlopen will try to load "libpath/driver.so". Dmitry.
Re: Small correction for path stripping in builtin32.c
Alexandre Julliard [EMAIL PROTECTED] wrote: BUILTIN32_dlopen seems correct to me. Are you sure the problem wasn't rather with BUILTIN32_LoadLibraryExA? We don't try to handle '/' there, and maybe we should (but it has to be done the same way as in BUILTIN32_dlopen, not the way you did it in your patch). Sorry, perhaps I wasn't very clear, and you were confused by it. It was not the real problem that I was encountered, but just a pseudo problem. I decided to fix it, because I thought that BUILTIN32_dlopen uses incorrect way of the stripping file name from path by searching first '/' in the name, then from possibly found position it tries to search for '\'. If you don't see any problem with current implementation, forget about my patch. Dmitry.
Re: Code page stuff is broken
Alexandre Julliard [EMAIL PROTECTED] wrote: I don't have any Russian fonts on my Windows machine to test this, but if I select an OEM font TextOut definitely uses the OEM codepage, not the CP_ACP one. So we cannot assume that all strings passed to TextOut are in current ANSI codepage; we have to take into account the font codepage somehow. Note 1: Until the last changes, ALL my fonts with ALL different encodings worked in Wine just fine. I already noted in my previous mail, code page of currently selected font is the problem of a dc driver (display, printer, etc.) ONLY. Note 2: Text feeded to TextOut can be received from the several different sources: resource (unicode), message table (ansi/unicode), hard coded in the program (I often use this one myself), entered from keyboard, created dinamically, etc. I should add, that the derived text might easy be delivered to any other text handling function (CharNext for instance). In ALL these cases APPLICATION assumes that text is in current ansi code page for every single character. Dmitry.
Re: Code page stuff is broken(about system font)
TAKESHIMA Hidenori [EMAIL PROTECTED] wrote: I check original windows 98(Japanese edition; CP_ACP=cp932). There are some system fonts that have codepage CP_ACP (at least in my environments): - System, FixedSys, Terminal Probablly, these three 'reserved' fonts should be treated as special font names and should have CP_ACP. And all stock font objects should have codepage CP_ACP, too. these stock objects seem to be hard-coded (using ANSI_CHARSET) in objects/gdiobj.c, but these should be fixed... Hardcoding some code page for the FONT NAME is a very bad design, and will introduce only additional hadaches and mess. In my opinion (already mentioned several times), all font code pages is the problem of a dc driver ONLY. Dmitry.
Code page stuff is broken
Hello. This patch broke correct displaying of cyrillic characters: revision 1.28 date: 2000/08/20 20:08:35; author: julliard; state: Exp; lines: +20 -14 Hidenori Takeshima [EMAIL PROTECTED] Handle the codepage of fonts if supported by the graphics driver. because of: 1. My app loads resources (russian text) from resources. Resources are in unicode, loaded text is in ANSI (LoadStringA was used). 2. Then app displays the text using ExtTextOutA. Here the problems begin. Now ExtTextOutA assumes, that ANSI code page and code page of currently selected font is the same. It is wrong assumption. As it was many times pointed out (at least by me). Suggested fix: Wine should always treat non-unicode text as it is in current ANSI code page. Code page of font is an internal problem of display driver and hacks for internal support of several code pages simultaneously should not be introduced. Please, remove that patch! Dmitry.
Re: patch for animate.c
Francois Methot [EMAIL PROTECTED] wrote: For the transparency issue, this patch implement a switch-case for the bitcount (bit per pixel) of the animation files. With this switch different line of code is executed for getting and setting the transparency color whenever it's 2, 4, 8, 16, 24 or 32 bpp because different operation is needed for each of those cases. For now, the switch-case implementation has been made only for 8, 16, 24 and 32 bpp. Just curious, I have never seen 2 bpp DIBs, only 1 (monochrome), 4 and so on. Dmitry.
Re: patch to remove sysmenu on toolwindow ...
Francois Methot [EMAIL PROTECTED] wrote:
This patch prevent a system menu from appearing on a docker by filtering the
Style and ExStyle of a window.
The system menu won't be displayed if a given window has the following
style:
WS_EX_TOOL_WINDOW
However to display it, it requires those:
WS_SYSMENU
WS_CAPTION
I choosed these styles based on test I made with Window.
...
-if (pt.x = rect.left) return HTSYSMENU;
+if (pt.x rect.left) {
+if ((wndPtr-dwStyle WS_CAPTION) !(wndPtr-dwExStyle
+WS_EX_TOOLWINDOW))
+return HTSYSMENU;
+else
+return HTCAPTION;
+}
...
in winuser.h WS_CAPTION defined as
#define WS_CAPTION 0x00C0L /* WS_BORDER | WS_DLGFRAME */
so, test "if (wndPtr-dwStyle WS_CAPTION)" is not correct. Everywhere in Wine
the construction like "if ((wndPtr-dwStyle WS_CAPTION) == WS_CAPTION)" is widely
used.
Dmitry.
Re: Code page stuff is broken
Alexandre Julliard [EMAIL PROTECTED] wrote: 2. Then app displays the text using ExtTextOutA. Here the problems begin. Now ExtTextOutA assumes, that ANSI code page and code page of currently selected font is the same. It is wrong assumption. As it was many times pointed out (at least by me). It's not assuming they are the same, it's assuming that the app wants TextOutA to display the string using the font codepage, which is not entirely unreasonable (though I agree you can also argue that it should assume CP_ACP instead). Of course, I can :-). ExtTextOutA at wine/objects/text.c takes non-unicode text and translates it to unicode using wrong code page. That's all. The used code page will be always wrong, if currently selected font will have another code page rather then current ANSI code page. Theoretically, the system could have fonts with three different code pages: ANSI, OEM, MAC. I have even more in addition to the mentioned ones: iso8859-1, iso8859-5, koi8-r, symbol. In my case ANSI = 1251, OEM = 866, MAC = 10007. So, the question: Can the fonts with the different code pages easy break everything?! Maybe the problem is that we should always try to use the right font charset for the current codepage unless specified explicitly? Would a patch like this improve the situation? Unfortunately, the problem persist. Dmitry.
