Re: mono progress on mixed-mode assemblies...
Hi, From: Dan Kegel But Wine has its own increasingly useful implementation of msvcrt, at least the part that uses the C api. (The C++ api is difficult for us because it has to be written in C; g++ uses a different ABI than Microsoft C++.) Perhaps, once we work the kinks out, Mono can rely on Wine once more to get this and related functionality. That would be great. Because mixed-mode (there is no pure managed version) msvcrts require Managed C++ and C++/CLI and there is no open source compiler supporting any of these so MS compilers would be required. Also note that Mono's Class Library is licensed under MIT/X11 because inlining (done by the runtime) may be incompatible with GPL that would not allow non-GPL programs to be executed within Mono. Would it be possible to have a MIT/X11 licensed msvcrt? Kornél
Re: mono progress on mixed-mode assemblies...
On Wed, May 14, 2008 at 2:37 AM, Kornél Pál [EMAIL PROTECTED] wrote: Because mixed-mode (there is no pure managed version) msvcrts require Managed C++ and C++/CLI and there is no open source compiler supporting any of these so MS compilers would be required. Bleah. Well, you gotta do what you gotta do! Also note that Mono's Class Library is licensed under MIT/X11 because inlining (done by the runtime) may be incompatible with GPL that would not allow non-GPL programs to be executed within Mono. Would it be possible to have a MIT/X11 licensed msvcrt? That's an interesting question. If you start from scratch, and make it part of Mono, sure. If you start with Wine's source code, you would need to get permission from the authors who have contributed to Wine's msvcrt. I don't know how many there are, but it would probably only take an hour or so for somebody to write a script that generated the list of authors... - Dan
Re: wine.inf: add a fake dll for sensapi.dll
Austin English [EMAIL PROTECTED] writes: Anything wrong with this patch? http://www.winehq.org/pipermail/wine-patches/2008-May/054794.html It's not a valid git patch. -- Alexandre Julliard [EMAIL PROTECTED]
TrendyFlash Site Builder works!
http://bugs.winehq.org/show_bug.cgi?id=9376 People who generate annoying cookiecutter Flash web sites can now migrate to LInux with confidence :-)
Re: mono progress on mixed-mode assemblies...
From: Dan Kegel Also note that Mono's Class Library is licensed under MIT/X11 because inlining (done by the runtime) may be incompatible with GPL that would not allow non-GPL programs to be executed within Mono. Would it be possible to have a MIT/X11 licensed msvcrt? That's an interesting question. If you start from scratch, and make it part of Mono, sure. If you start with Wine's source code, you would need to get permission from the authors who have contributed to Wine's msvcrt. I don't know how many there are, but it would probably only take an hour or so for somebody to write a script that generated the list of authors... I think that the best idea would be to have two separate code bases because that would allow more freedom for an experimental managed C++ runtime. On the other hand patches could be merged manually so both Wine and Mono could benefit the changes. So the question is: If the current authors permit to make msvcrt MIX/X11 licensed would it be possible to make Wine's msvcrt MIT/X11 licensed for future releases as well (no legal question but philosophical)? Kornél
Re: Serial port support in wine-1.0: What to do to make it working ?
Pavel wrote: I have to use wine-0.9.40 to communicate with a device in my work (simple text-based command-reply communication), any wine newer than say 0.9.50 doesn't work, the communication times out. ... I will try to dig into the driver and search for the bugs there. One of the cases is I think simple, the device uses normal ASCII protocol and I can talk to it using kermit or minicom, but the windows program intended to control it simply stucks on the first command and never gets a reply. I think there is a good place to start. Yep. FWIW, the fix might be tiny. Alexandre fixed a serial bug today, http://bugs.winehq.org/show_bug.cgi?id=9356 with just a single assignment. If you can come up with a simple way for others to reproduce the problem, that might help, too. Hi! I have a very good news today! I tested the current wine git and I've found that it works again in the case of a device mentioned above! It's really good, because it didn't work in 0.9.61 and using 0.9.40 was not good because of another problems in this version. Even better, I've also found that today's wine fixes the last graphics glitches remaining in the program GUI, so now it works PERFECTLY under wine, and it seems that reading/writing the device over the serial port is even FASTER than from windows! I will try another devices soon, to help to debug serial port problems as much as possible! With regards, Pavel Troller
Re: mono progress on mixed-mode assemblies...
On Wed, May 14, 2008 at 8:37 AM, Kornél Pál [EMAIL PROTECTED] wrote: So the question is: If the current authors permit to make msvcrt MIX/X11 licensed would it be possible to make Wine's msvcrt MIT/X11 licensed for future releases as well (no legal question but philosophical)? You will need to review the git history and contact anyone that has contributed to msvcrt since the Wine changeover to LGPL and get permission. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: mono progress on mixed-mode assemblies...
From: Steven Edwards So the question is: If the current authors permit to make msvcrt MIX/X11 licensed would it be possible to make Wine's msvcrt MIT/X11 licensed for future releases as well (no legal question but philosophical)? You will need to review the git history and contact anyone that has contributed to msvcrt since the Wine changeover to LGPL and get permission. Thanks for the information. This makes the list even shorter. If contributors agree only the current version will be MIT/X11 licensed. But I would like to know if the Wine community is willing to license msvcrt under MIT/X11 after that in the future in Wine's source repository to help Mono? Kornél
Re: dinput: Convert keyboard buffer from internal data format to user data format
Vitaliy Margolen wrote: Sergey Khodych wrote: Any particular reason for this? Do you have a program that sets different data format? The reason I ask - copying 256 bytes is much faster then iterating over the whole data format and copying one byte at a time. A possibility of using custom data format, for any type of devices, is described in DirectX SDK documentation. For example Monolith's F.E.A.R. use this method. That is not what I asked. If you read MSDN it tells lots of things that are not true. Also I do not recall seeing any problems with FEAR game that were related dinput. If you have that bug handle please point me to it. To reply to myself. I've missed the fact that if the requested format is the same as Wine's internal format it will be a simple memcpy. I did not want to penalize most dinput applications that just use default keyboard format (array of 256 bytes). Sergey, please resend this patch. It might resolve few keyboard problems applications having with Wine. At least I hope it might. Vitaliy.
Re: Serial port support in wine-1.0: What to do to make it working ?
On Wed, May 14, 2008 at 6:26 AM, Pavel Troller [EMAIL PROTECTED] wrote: Hi! I have a very good news today! I tested the current wine git and I've found that it works again in the case of a device mentioned above! It's really good, because it didn't work in 0.9.61 and using 0.9.40 was not good because of another problems in this version. Even better, I've also found that today's wine fixes the last graphics glitches remaining in the program GUI, so now it works PERFECTLY under wine, and it seems that reading/writing the device over the serial port is even FASTER than from windows! I will try another devices soon, to help to debug serial port problems as much as possible! With regards, Pavel Troller Wonderful! Can you add this information to the AppDB?
Re: Serial port support in wine-1.0: What to do to make it working ?
On Wed, May 14, 2008 at 6:26 AM, Pavel Troller [EMAIL PROTECTED] wrote: Hi! I have a very good news today! I tested the current wine git and I've found that it works again in the case of a device mentioned above! It's really good, because it didn't work in 0.9.61 and using 0.9.40 was not good because of another problems in this version. Even better, I've also found that today's wine fixes the last graphics glitches remaining in the program GUI, so now it works PERFECTLY under wine, and it seems that reading/writing the device over the serial port is even FASTER than from windows! I will try another devices soon, to help to debug serial port problems as much as possible! With regards, Pavel Troller Wonderful! Can you add this information to the AppDB? To which app ? My one is a very special program, working just with a special telecom device. It's not available publicly anywhere. It doesn't have any entry in AppDB, it would be useless. I will add remarks to other apps, which I will verify later (i.e. MapSource souftware for Garmin GPS etc.). With regards, Pavel Troller
Re: wine.inf: add a fake dll for sensapi.dll
Ahh. Here you go. -Austin On Wed, May 14, 2008 at 4:29 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Austin English [EMAIL PROTECTED] writes: Anything wrong with this patch? http://www.winehq.org/pipermail/wine-patches/2008-May/054794.html It's not a valid git patch. -- Alexandre Julliard [EMAIL PROTECTED] From cd10759b1101222de2177e0c5c240767a03acee3 Mon Sep 17 00:00:00 2001 From: Austin English [EMAIL PROTECTED] Date: Wed, 14 May 2008 10:58:44 -0500 Subject: [PATCH] wine.inf: add fake dll entry for sensapi --- tools/wine.inf.in |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf.in b/tools/wine.inf.in index aa18b87..4be0805 100644 --- a/tools/wine.inf.in +++ b/tools/wine.inf.in @@ -2276,6 +2276,7 @@ HKLM,%CurrentVersion%\Telephony\Country List\998,SameAreaRule,,G 11,,rsaenh.dll 11,,rundll32.exe 11,,schannel.dll +11,,sensapi.dll 11,,setupapi.dll 11,,shdocvw.dll 11,,shell32.dll -- 1.5.3.6
re: ws2_32: Test for invalid hostnames again.
Kai, that test will always fail on some systems. How about this: just test for whether that function completes at all, rather than testing for success. - Dan
Re: mono progress on mixed-mode assemblies...
On Wed, May 14, 2008 at 5:48 AM, Kornél Pál [EMAIL PROTECTED] wrote: If contributors agree only the current version will be MIT/X11 licensed. But I would like to know if the Wine community is willing to license msvcrt under MIT/X11 after that in the future in Wine's source repository to help Mono? We can certainly discuss it. - Dan
Wineconf 2008
Hi Folks, We have provisionally set Wineconf for the weekend of September 27/28 in Saint Paul, Minnesota. The Wine conference is open to all. We host 2 days of informal sessions to discuss technical issues related to Wine development. We'll likely also have a celebration of Wine 1.0, and other social activities. If you're interested in Wineconf, please visit this web page: http://www.winehq.org/site/wineconf/survey In particular, if you have given up on Wineconf because of travel costs, please indicate that on the form. I'll use the response data I get there to nail down the details. I look forward to seeing you all, and to celebrating 1.0! Cheers, Jeremy
Re: dinput: Convert keyboard buffer from internal data format to user data format
To reply to myself. I've missed the fact that if the requested format is the same as Wine's internal format it will be a simple memcpy. I did not want to penalize most dinput applications that just use default keyboard format (array of 256 bytes). What do you think about using common buffer for all types of devices and translating a new event direct to user's data format? In this case we just copy buffer of base device.
richedit: text that does not need scrollbar should also result in a scroll range of 0. Tests for this behavior.
Eric Pouech escribió:
Alex Villacís Lasso a écrit :
Even though the code freeze is still in effect, I post this so that it
will be reviewed. For more information, see bug #12311.
Changelog:
* richedit: empty text should result in a scroll range of 0.
* Tests for this behavior.
what I don't understand is why the height of an empty doc is not zero (I
had similar issues with the height of a doc where we systematically get
one row too much). I believe this root cause should be fixed instead of
the band aid your patch is providing
A+
The height of the document is irrelevant. Instead, if the actual height
is less than the height of the client area, the scrollbar should also be
set to zero, as shown by tests included in the attached patch. Empty
text is just one special case.
Changelog:
* Text that does not need to be scrolled should also result in a scroll
range of zero
* Tests for this behavior
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
diff -ur wine-orig/dlls/riched20/paint.c wine-build/dlls/riched20/paint.c
--- wine-orig/dlls/riched20/paint.c 2008-05-14 16:18:24.0 -0500
+++ wine-build/dlls/riched20/paint.c 2008-05-14 16:25:44.0 -0500
@@ -689,7 +689,7 @@
si.nMin = 0;
- if (ME_GetTextLength(editor) 0)
+ if (editor-nTotalLength editor-sizeWindow.cy)
{
si.nMax = editor-nTotalLength;
si.nPage = editor-sizeWindow.cy;
diff -ur wine-orig/dlls/riched20/tests/editor.c wine-build/dlls/riched20/tests/editor.c
--- wine-orig/dlls/riched20/tests/editor.c 2008-05-14 16:18:24.0 -0500
+++ wine-build/dlls/riched20/tests/editor.c 2008-05-14 16:20:27.0 -0500
@@ -1930,6 +1930,15 @@
/* test a richedit box containing a single line of text */
SendMessage(hwndRichEdit, WM_SETTEXT, 0, (LPARAM) a);/* one line of text */
+ memset(si, 0, sizeof(si));
+ si.cbSize = sizeof(si);
+ si.fMask = SIF_RANGE | SIF_PAGE | SIF_POS;
+ GetScrollInfo(hwndRichEdit, SB_VERT, si);
+ ok(si.nMin == 0, si.nMin == %d, expected 0\n, si.nMin);
+ ok(si.nMax == 0, si.nMax == %d, expected 0\n, si.nMax);
+ ok(si.nPos == 0, si.nPos == %d, expected 0\n, si.nPos);
+ ok(si.nPage == 0, si.nPage == %d, expected 0\n, si.nPage);
+
expr = 0x0001;
for (i = 0; i 4; i++) {
static const int cmd[4] = { SB_PAGEDOWN, SB_PAGEUP, SB_LINEDOWN, SB_LINEUP };
regressions running Photoshop?
Hmm. I just tried running Photoshop CS2 trial and Photoshop 5.5 trial, and both failed on current wine. CS2 complained not enough DOS memory, and 5.5 complained lcms: Error #12288; Too many tags (2025813777) PS6 works, though.
Configure question about Wine / HAL
I'm trying to get Wine to compile with HAL support on FreeBSD, and running into this error: checking dbus/dbus.h usability... yes checking dbus/dbus.h presence... yes checking for dbus/dbus.h... yes checking hal/libhal.h usability... yes checking hal/libhal.h presence... yes checking for hal/libhal.h... yes checking for dbus_connection_close in -ldbus-1... no configure: error: libhal development files not found, no dynamic device support. This is an error since --with-hal was requested. What exactly is -ldbus-1? Is there a way around this? Configure is finding the dbus and hal headers properly, and they both work properly on the system. -- Kris Moore PC-BSD Software http://www.pcbsd.com
shell32 failures only under winetest, not make test?
Oddly, I only see shelllink.c:90: Test succeeded inside todo block: SHILCreateFromPath failed (0x) shelllink.c:194: Test succeeded inside todo block: path_to_pidl returned a NULL pidl shelllink.c:214: Test failed: GetPath returned 'C:\nonexistent\file' shelllink: 190 tests executed (2 marked as todo, 3 failures), 0 skipped. when I run on wine with winetest-dist. When I do 'make test', shelllink.ok gets created fine. Anyone else see that?
Re: dinput: Convert keyboard buffer from internal data format to user data format
Sergey Khodych wrote: To reply to myself. I've missed the fact that if the requested format is the same as Wine's internal format it will be a simple memcpy. I did not want to penalize most dinput applications that just use default keyboard format (array of 256 bytes). What do you think about using common buffer for all types of devices and translating a new event direct to user's data format? In this case we just copy buffer of base device. It's hard to find something common for say keyboard and joystick. Former have lots of only buttons while later can have lots of axes and only few buttons. So still have to use some specialized data buffer. Or you mean to use user data format internally? That will still require some mapping - from indexes to offset size. But that gets really messy and still requires conversion (which we are doing anyway). Unless everything will be changed in one go. However when I'm thinking about it - it will require extra work while doing object enumeration. For a time being (during the code freeze) I'd prefer not to change any core functions. Vitaliy.
Re: Configure question about Wine / HAL
Hello Kris, 2008/5/14 Kris Moore [EMAIL PROTECTED]: I'm trying to get Wine to compile with HAL support on FreeBSD, and running into this error: checking dbus/dbus.h usability... yes checking dbus/dbus.h presence... yes checking for dbus/dbus.h... yes checking hal/libhal.h usability... yes checking hal/libhal.h presence... yes checking for hal/libhal.h... yes checking for dbus_connection_close in -ldbus-1... no configure: error: libhal development files not found, no dynamic device support. This is an error since --with-hal was requested. What exactly is -ldbus-1? Is there a way around this? Configure is finding the dbus and hal headers properly, and they both work properly on the system. How do you link to libhal on freebsd? And how do you link to libdbus? Cheers, Maarten.
