On January 29, 2003 05:16 am, Christian Kristukat wrote:
> Hi,
> I'm not sure if it's really a bug. It occured while using Microcal Origin.
> Wine crashes after every call of an analysis function, e.g. Peak fitting.
>
> ChangeLog:
> * dlls/user/text.c
> - I added some braces to prevent a division by zero error
Wrong solution; that just makes the problem go away by making it wrong for
everything else.
What does windows do when one passes silly data to GetTabbedTextExtent?
>
> ? patch.diff
> ? dlls/user/text_orig.c
> Index: dlls/user/text.c
> ===================================================================
> RCS file: /home/wine/wine/dlls/user/text.c,v
> retrieving revision 1.43
> diff -u -r1.43 text.c
> --- dlls/user/text.c 8 Jan 2003 21:09:26 -0000 1.43
> +++ dlls/user/text.c 29 Jan 2003 12:41:14 -0000
> @@ -1244,7 +1244,7 @@
> else if (cTabStops > 0)
> tabPos = nTabOrg + *lpTabPos;
> else
> - tabPos = nTabOrg + ((x + extent.cx - nTabOrg) / defWidth + 1)
> * defWidth;
> + tabPos = nTabOrg + ((x + extent.cx - nTabOrg) / (defWidth +
> 1)) * defWidth;
That is a different calculation and is wrong.
> if (fDisplayText)
> {
> RECT r;
--
Bill Medland
ACCPAC International, Inc.
medbi01(a)accpac.com
Corporate: www.accpac.com
Hosted Services: www.accpaconline.com
Hello
On my Suse 7.3 Linux (Kernel 2.4.4) I tried to start the
w2k Explorer (Version 5.0 (Build 2195: Service Pack 3)
using wine-20030115 with just buildin dlls.
tm@penguin:~/c/w2k > winedbg explorer
For language 'german' several language ids were found:
de_DE - 0407; de_CH - 0807; de_AT - 0C07; de_LU - 1007; de_LI - 1407;
Instead of using first in the list, suggest to define
your LANG environment variable like this: LANG=de_DE
For language 'german' several language ids were found:
de_DE - 0407; de_CH - 0807; de_AT - 0C07; de_LU - 1007; de_LI - 1407;
Instead of using first in the list, suggest to define
your LANG environment variable like this: LANG=de_DE
fixme:console:SetConsoleCtrlHandler (0x404c3340,1) - no error checking or
testing yet
For language 'german' several language ids were found:
de_DE - 0407; de_CH - 0807; de_AT - 0C07; de_LU - 1007; de_LI - 1407;
Instead of using first in the list, suggest to define
your LANG environment variable like this: LANG=de_DE
fixme:shell:SHLWAPI_437 (0x00000004) stub
fixme:process:SetProcessShutdownParameters (00000002, 00000000): partial
stub.
fixme:shell:FileIconInit (true)
fixme:ntdll:NtOpenProcessToken (0xffffffff,0x00000008,0x406b2e08): stub
fixme:ntdll:NtQueryInformationToken (0xcafe,10,0x406b2dc4,56,0x406b2dfc):
stub
Copied by hand from the winedbg window:
0011: sel=008f base=401145e0 limit=00000fff 32-bit rw-
Backtrace:
=>0 0x400c3de5 (RaiseException+0x75(code=0xc06d007f, flags=0x0, nbargs=0x1,
args=0x406b2df8) [except.c:84] in libntdll.dll.so) (ebp=406b2da8)
1 0x0040de7f (explorer.exe.EntryPoint+0xc8d7 in C:\w2k\explorer.exe)
(ebp=406b2df0)
2 0x0040a30f (explorer.exe.EntryPoint+0x8d67 in C:\w2k\explorer.exe)
(ebp=406b2e3c)
3 0x00401621 (explorer.exe.EntryPoint+0x79 in C:\w2k\explorer.exe)
(ebp=406b2e9c)
4 0x400ba038 (start_process+0x248 [process.c:564] in libntdll.dll.so)
(ebp=406b2f38)
5 0x400beb3d (call_on_thread_stack+0x1d(func=0x400b9df0) [sysdeps.c112]
in libntdll.dll.so) (ebp=406b2ff4)
6 0x400bece4 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000)
0x400c3de5 (RaiseException+0x75 [except.c84] in libntdll.dll.so): leal
0xffffffa8(%ebp),%esp
84 RtlRaiseException( &record );
This seems to be an error in the wine exception handling. Is this right?
What can be done about that?
Greetings
Thomas Mertes
liu spider <liuspider(a)yahoo.com> writes:
> ChangLog:
> - controls/edit.c
> new message type WM_IME_CHAR to handle XIM input.
> - dlls/x11drv/keyboard.c
> new function XIM_KeyEvent to process XIM key events.
> - dlls/x11drv/window.c
> new attributs added when creating a IC
> - dlls/x11drv/x11drv_main.c
> exchange the order of XCloseDisplay and XCloseIM
> (otherwise it will crash when closed)
>
> (What's wrong with this patch? It seems to be ignored.)
It's not ignored, but I'm currently working in this area, and we also
have some related stuff in the Crossover tree, and I'm trying to bring
everything together into a coherent whole; so it will eventually be
committed in one form or another, but I have to spend a bit more time
on this first.
--
Alexandre Julliard
julliard(a)winehq.com
My japanese fonts seem to make wine crash,
even apart from that, they also don't work in wine ;-)
------------- wine output on wine hl.exe --------
---------- cut out a couple thousand lines-------
err:font:XFONT_BuildMetrics failed to load -kappa-fixed-bold-r-normal--20-190-75-75-c-100-jisx0201.1976-0
Font metrics: 92.2% done
fixme:font:LFD_InitFontInfo font '-kappa-fixed-bold-r-normal--20-190-75-75-c-100-muleipa-1' has unknown registry 'muleipa' and character encoding '1'
X Error of failed request: 82
Major opcode of failed request: 45 (X_OpenFont)
Serial number of failed request: 10964
Current serial number in output stream: 10965
----------------------- end ---------------------
Why? I don't know. they work fine in everything else...
--
"De-fault! The two sweetest words in the English language."
-- Homer Simpson
Get Gaim for unix or win32 systems! gaim.sourceforge.net
Scott "Action" Jackson - scott_j(a)ajackson.org
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
> Not so. Looking at the header file generated by wrc,
> it occured to me that it is exporting symbols that it
> shouldn't be exporting in the first place. I think the
> options where added long ago for compatibility with the
> old resource compiler.
No, it's exporting symbols to reference the resource data directly, in
case you don't want to go to the trouble of parsing the resource
directory and you just want the data. It's true that the header is not
really useful since you can add extern statements in the code that
uses the data; I think we should keep the -g option though, otherwise
in asm mode you are forced to parse the resource descriptor which
isn't much fun.
--
Alexandre Julliard
julliard(a)winehq.com
"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote:
> >
/**************************************************************************
> > + * RtlUpperChar (NTDLL.@)
> > + */
> > +CHAR WINAPI RtlUpperChar( CHAR ch )
> > +{
> > + return toupper(ch);
> > +}
>
> It's better to avoid using locale dependent functions from an underlying
> system because Wine internal code page almost always is different from OS
> locale. The way to go is convert to unicode, do desired things, and
convert
> the result back to ansi.
The implementation of RtlUpperString in rtlstr.c gave me the idea to use
toupper:
/**************************************************************************
* RtlUpperString (NTDLL.@)
*/
void WINAPI RtlUpperString( STRING *dst, const STRING *src )
{
unsigned int i, len = min(src->Length, dst->MaximumLength);
for (i = 0; i < len; i++) dst->Buffer[i] = toupper(src->Buffer[i]);
dst->Length = len;
}
The docu of RtlUpperChar says:
RtlUpperChar returns the uppercase version of the specified character or
returns the value specified by the caller for Character if the specified
character cannot be converted.
RtlUpperChar returns the input Character unconverted if it is the lead byte
of a multibyte character or if the uppercase equivalent of Character is a
double-byte character. To convert such characters, use
RtlUpcaseUnicodeChar.
--- End of docu --
IMHO RtlUpperChar has nothing to do for unicode chars.
Is there a way to use Wine internal code page to do the conversion without
converting to unicode and back?
BTW: If it is not ok to use toupper several other places in wine have a
problem:
$ grep toupper */*.c */*/*.c */*/*/*.c | grep -v toupperW | grep -v
str_toupper
in wine-20030115 gives a longer list of usages of toupper.
Specially msvcrt toupper seems also to use the function from libc.
Greetings
Thomas Mertes
> To: wine-devel(a)winehq.com
> From: thomas.mertes(a)t-mobile.at
> Date: Wed, 29 Jan 2003 14:26:27 +0100
> Subject: w2k Explorer makes wine crash in RtlRaiseException
> [Virus checked]
>
> Hello
>
> On my Suse 7.3 Linux (Kernel 2.4.4) I tried to start the
> w2k Explorer (Version 5.0 (Build 2195: Service Pack 3)
> using wine-20030115 with just buildin dlls.
>
> tm@penguin:~/c/w2k > winedbg explorer
> Copied by hand from the winedbg window:
> 0011: sel=008f base=401145e0 limit=00000fff 32-bit rw-
> Backtrace:
> =>0 0x400c3de5 (RaiseException+0x75(code=0xc06d007f, flags=0x0,
> nbargs=0x1,
> args=0x406b2df8) [except.c:84] in libntdll.dll.so) (ebp=406b2da8)
> 1 0x0040de7f (explorer.exe.EntryPoint+0xc8d7 in C:\w2k\explorer.exe)
> (ebp=406b2df0)
> This seems to be an error in the wine exception handling. Is this right?
> What can be done about that?
No, it is not. It is a software exception raised by explorer itself (you can
get the same effect by running Win98 explorer on Win2k). I have seen the
same problem myself and managed to fix it, though I can't remember how. I
have submitted quite a few patches specific to getting Win2k explorer
running on Wine, but they haven't been accepted so far.
For a start you could try --dll shlwapi=b and copying over the native
shdocvw.dll and browseui.dll and running regsvr32 on them both. Try running
with --dll ole32=b to see if it is a COM class that isn't registered and
finally try using some of my shell32 and shlwapi patches :)
Hope this helps,
Rob
BTW I have got explorer loaded and displaying a folder but there are no
items in the folder view apart from 'Desktop'. I am still trying to work out
exactly why this is.
I've played with our MDI application a bit more, and have
observed two kinds of bugs under cvs wine:
First type: things not drawing, probably because of missing messages
(we know the WM_NCPAINT message is AWOL, but it might be something
else);
1. One of the "documents" has blank client areas (mentioned previously);
these don't ever get drawn.
2. Another of the "documents" has a blank pane initially, but
if you diddle around a bit, it does draw.
3. Maximizing any of the "documents" is supposed to make a
minimize/maximize/close widget appear on the right-hand side of
the toolbar, but it doesn't.
Second type: things drawing in the wrong place:
4. The text box at the bottom of a three-panel window has its
upper left corner in the right place, but its lower right corner
is exactly one scrollbar width inset too far.
The scrollbars are inset by that amount, too. That leaves the area
where the scrollbars ought to be totally undrawn.
Duane Clark is looking at the missing message problem in this
and another app.
Also, I'm setting up Linux and Wine for the guy
who wrote our app so he can poke around and look
for these problems himself; if nothing else, he can
put together a minimal test case.
- Dan
--
Dan Kegel
http://www.kegel.comhttp://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
I'm looking into updating section 3.3 of the Packagers Guide.
I am not toatly sure about all the info that I have if you are
aware of something out of place could you let me know.
Thanks
Tom
----------
Windows 95 to ME )
Registry Files
/windows/system.dat
/windows/user.dat
/windows/win.ini
The Registry consists of two local files, System.dat and User.dat.
System.dat contains information on
software and hardware settings and is located in the Windows folder.
User.dat contains user-specified
configurations for the GUI and shell. It is located in the Windows
folder unless the system is set up
for multiple users, in which case each user will have a separate
User.dat file located in
Windows\Profiles\username (where username is the name of the user).
Windows Dynamic Link Libraries
/windows/system
( Windows NT )
Registry Files
/winnt/profiles/(username)/ntsystem.dat
/winnt/profiles/(username)/ntuser.dat
/windows/win.ini -- for 16-bit app compatibility
If there are multiple profiles on one machine (one local, one as part of
a domain, etc.),
then the user directory will be the user name plus a number.
Windows Dynamic Link Libraries
/winnt/system -- 16-bit compat ?
/winnt/system32
( Win2K / XP )
/documents and settings/(username)/ntsystem.dat
/documents and settings/(username)/ntuser.dat
/windows/win.ini -- for 16-bit app compatibility
If there are multiple profiles on one machine (one local, one as part of
a domain, etc.),
then the user directory will be the user name plus a number.
Windows Dynamic Link Libraries
/winnt/system -- 16-bit compat ?
/winnt/system32
On January 24, 2003 09:04 pm, Tom Wickline wrote:
> www: Uma grande quantidade de informação acerca do Wine está disponivel
> pelo WineHQ em http://www.winehq.com/ : varios guias Wine, base de
> dados de aplicações, localizaçao de erros. Isto é provavelmente o
> melhor ponto de começo.
>
> FAQ: A Wine FAQ está localizada em http://www.winehq.com/FAQ
>
> Usenet Tu podes discutor tópicos relacionados de Wine e obter ajuda em
> comp.emulators.ms-windows.wine.
>
> Bugs: Ajuda online está disponivel em #WineHQ on irc.freenode.net.
>
> IRC: O currente desenvolvimento do Wine está disponivel por CVS.
> Vai a http://www.winehq.com/development/ para mais informação.
>
> Mailing Lists:
> Há algumas mailing list para responsaveis pelo desenvolvimento
> Wine; ver em http://www.winehq.com/development/#ml para mais informação.
Can we please switch these www.winehq.com references to www.winehq.org?
Any volunteer to update our documentation?
--
Dimi.