Re: [MSVCRT] Cross build fix
On Wed, Jun 02, 2004 at 11:09:36AM -0700, Alexandre Julliard wrote: > I don't see how this would solve problems like the _WCTYPE_T_DEFINED > issue. Right, it will not solve problems like this (for Boaz: _WCTYPE_T_DEFINED is a sentry for not defining a type twice, check out pretty much any header under include/msvcrt/ to see how it's used). However, I did grep the source, and it seems that we're using the MSVCRT_ prefix only in dlls/msvcrt/*.c. And so it's not clear to me that duplicating part of the headers is going to be that bad. I mean, we will need duplication only for the stuff that we use internally across files. That doesn't include math functions for example, and a bunch of other stuff. If you're positive this is not a good idea, I'll drop it, but if there is a chance it would be acceptable, I might give it a try... -- Dimi.
Re: Porting Application to MacOS X
On Thu, Jun 03, 2004 at 08:18:46AM +0100, saneh gupta wrote: > I need my application to be independent of any other > binary (like wine) - so, once linked with the required > wine-libraries it should just run on any MacOS X > machine i.e. no dependency on wine > binary/installation. Is this possible? No, it's not. A windows application uses a bunch of DLLs that you'll need those around, so you need wine. > I would also > like to use my own makefile for linking in my > application with the wine libraries. Is ths fine? Of course, you can use your own Makefiles. -- Dimi.
Re: Request for winetesting volunteers
On Thu, Jun 03, 2004 at 10:56:51PM +0200, Ferenc Wagner wrote: > We could easily chop those long tags to 6-7 chars. Shall we? Yes, we should because ATM we don't control them, and we can not allow unlimited strings in there. But 6-7 is a bit drastic. Looking at current result, even 20 chars is still OK. For example we have: DimitrisKoukoravas JackHollingworth we can't quite shorten these meaningfully. I'd have: 1. Un upper limit of around 20-25 chars 2. Maybe a smart splitter that would split the ID's at capitalization points: DimitrisJack Koukoravas Hollingworth 3. Decrease the font size even more. Right now it's , but we can do a or somesuch. > Do you mean something like -M key:file or -M key=value? > I agree that something like this should probably be added. Yes, something like that. I'm not sure we need a key/value syntax (do we?), even just -M string would do. But if all metadata is in the key,value format, sure, -M key=value would be great. -- Dimi.
Re: Request for winetesting volunteers
On Thu, Jun 03, 2004 at 10:50:13PM +0200, Ferenc Wagner wrote: > I tend to agree, this idea didn't really work out. Somehow > different Win9x subversions have well recognised names like > OSR2, SP1, SE but other Windows flavours do not while still > having service packs of course. We could probably drop this > distinction altogether and empty this layer of abstraction. > It would simplify things a bit. Deal? Deal. If we do the simple thing and just keep the name constant (i.e. Win95, Win98, etc.) would be perfect. If we need more info, we just click on the link and look at the report. -- Dimi.
Re: Listview ignores the user specified image state index
On Thu, Jun 03, 2004 at 02:12:49PM -0700, Krishna Murthy wrote: > While inserting the item in ListView control in wine( in function > ISTVIEW_InsertItemT() ), the state image index is overwritten with zeros. > After copying the LVITEM structure to newly created item in > LISTVIEW_InsertItemT(), a statement is unnecessarily masking the state with > LVIS_STATEIMAGEMASK by using ~ operator (item.state &= ~LVIS_STATEIMAGEMASK; > ). This statement is making the bits 12 through 15 overwrite with 0's by > replacing original state image index. Odd, I've added that, but I can not understand why. If anything, it might be a typo, as I can't see why I would want to nuke the state image, but I also can not remember what I wanted to remove. So the patch is OK, I'll think some more tonight what, if anything, I wanted to remove from the state. -- Dimi.
Re: Listview ignores the user specified image state index
> Odd, I've added that, but I can not understand why. If anything, it might
> be a typo, as I can't see why I would want to nuke the state image, but
> I also can not remember what I wanted to remove. So the patch is OK, I'll
> think some more tonight what, if anything, I wanted to remove from the state.
Now I know why I did that. Documentation from LVM_INSERTITEM says:
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/listview/messages/lvm_insertitem.asp)
...
If a list-view control has the LVS_EX_CHECKBOXES style set,
any value placed in bits 12 through 15 of the state member of
the LVITEM structure will be ignored. When an item is added
with this style set, it will always be set to the unchecked state.
...
Documentation for LVITEM.state, says:
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/listview/structures/lvitem.asp)
...
Bits 12 through 15 of this member specify the state image index.
The state image is displayed next to an item's icon to indicate
an application-defined state. If these bits are zero, the item
has no state image. To isolate these bits, use the LVIS_STATEIMAGEMASK
mask. To set the state image index, use the INDEXTOSTATEIMAGEMASK
macro. The state image index specifies the index of the image in
the state image list that should be drawn. The state image list is
specified with the LVM_SETIMAGELIST message.
...
So I guess we need to clear the bits only if LVS_EX_CHECKBOXES is set.
ChangeLog
Clear the state image bits only if LVS_EX_CHECKBOXES is set.
Fix obvious logical error in focus handling.
Indentation and formatting fixes.
(based on a patch by Krishna Murthy).
Index: dlls/comctl32/listview.c
===
RCS file: /var/cvs/wine/dlls/comctl32/listview.c,v
retrieving revision 1.388
diff -u -r1.388 listview.c
--- dlls/comctl32/listview.c11 May 2004 22:16:54 - 1.388
+++ dlls/comctl32/listview.c4 Jun 2004 04:41:46 -
@@ -3317,7 +3317,7 @@
ranges_delitem(infoPtr->selectionRanges, lpLVItem->iItem);
/* if we are asked to change focus, and we manage it, do it */
- if (lpLVItem->state & lpLVItem->stateMask & ~infoPtr->uCallbackMask &
LVIS_FOCUSED)
+ if (lpLVItem->stateMask & ~infoPtr->uCallbackMask & LVIS_FOCUSED)
{
if (lpLVItem->state & LVIS_FOCUSED)
{
@@ -6041,7 +6041,7 @@
}
/***
- * nESCRIPTION:
+ * DESCRIPTION:
* Inserts a new item in the listview control.
*
* PARAMETER(S):
@@ -6072,8 +6072,7 @@
if (!is_assignable_item(lpLVItem, infoPtr->dwStyle)) return -1;
-if ( !(lpItem = (ITEM_INFO *)Alloc(sizeof(ITEM_INFO))) )
- return -1;
+if (!(lpItem = (ITEM_INFO *)Alloc(sizeof(ITEM_INFO return -1;
/* insert item in listview control data structure */
if ( !(hdpaSubItems = DPA_Create(8)) ) goto fail;
@@ -6094,21 +6093,21 @@
/* set the item attributes */
if (lpLVItem->mask & (LVIF_GROUPID|LVIF_COLUMNS))
{
- /* full size structure expected - _WIN32IE >= 0x560 */
- item = *lpLVItem;
+/* full size structure expected - _WIN32IE >= 0x560 */
+item = *lpLVItem;
}
else if (lpLVItem->mask & LVIF_INDENT)
{
- /* indent member expected - _WIN32IE >= 0x300 */
- memcpy(&item, lpLVItem, offsetof( LVITEMW, iGroupId ));
+/* indent member expected - _WIN32IE >= 0x300 */
+memcpy(&item, lpLVItem, offsetof( LVITEMW, iGroupId ));
}
else
{
- /* minimal structure expected */
- memcpy(&item, lpLVItem, offsetof( LVITEMW, iIndent ));
+/* minimal structure expected */
+memcpy(&item, lpLVItem, offsetof( LVITEMW, iIndent ));
}
item.iItem = nItem;
-item.state &= ~LVIS_STATEIMAGEMASK;
+if (infoPtr->dwLvExStyle & LVS_EX_CHECKBOXES) item.state &= ~LVIS_STATEIMAGEMASK;
if (!set_main_item(infoPtr, &item, TRUE, isW, &has_changed)) goto undo;
/* if we're sorted, sort the list, and update the index */
Re: [tests] disable winspool tests if we don't have a default printer
On Fri, Jun 04, 2004 at 08:26:49AM +0200, Andreas Mohr wrote: > Why not be more verbose about that? Because those people will not see the warning anyway I'm afraid. Most run in non-interactive mode through winrash, others through winetest. The most we can do is leave the error in, and bug people into fixing their setup, but I'm not sure this is practical. Maybe we need a special sort of failure more for these sort of things, so we can separate them in the HTML output. -- Dimi.
Re: [tests] disable winspool tests if we don't have a default printer
On Sat, Jun 05, 2004 at 03:44:22PM +0200, Francois Gouget wrote: > Not everyone has a printer and there's nothing wrong with that. That's > what's causing the missing default printer, right? I guess. I can see that we would prefer if there were such a default printer, but we can't force people to have one. Anyway, Alexandre committed the patch so ... :) -- Dimi.
Re: wingcc and -Wb option
On Fri, Jun 11, 2004 at 08:08:31AM -0700, Jon Griffiths wrote: > The easiest way to fix this is to change the delimiting character in > either option, i.e.: > > winebuild: --ignore=x,y,z => --ignore=x;y;z > > winegcc: -Wb,--ignore=x,y,z, => -Wb;--ignore=x,y,z; > > Does anyone care which one it is? ';' is not convenient, as it conflicts with the shell ';' operator. winegcc is the front-end tool, so it's more likely to be used directly. So if anything, we should change this in winebuild. But maybe we can introduce a '-i' options instead: winebuild: --ignore=x,y,z => -ix -iy -iz -- Dimi.
Re: [WineHQ] service.cgi fixes
On Fri, Jun 11, 2004 at 02:49:21PM +0100, Paul Millar wrote: > Why remove the verification of the code's gpg signature? It seems to > break a basic security maxim: don't trust the network. Because the current implementation is b0rken, and it just gives us a false sense of security. If we can't trust the network: -- why do we trust the script to tell us to do the verification?!? If anything, we would have to automatically always do the verification, not have a command for it. So a command of download url.foo should implicitily generate a download url.foo.sig gpgverify url.foo.sig -- also, why do we trust the script at all? We should also always sign and verify every time the script. But this will make it rather inconvenient to work with... Oh well, we'll do it if we must. But we have to be careful to NOT accept downloads signed my WineHQ (the sig used to sign the script), because if WineHQ is hacked, all bets are off. In other words, we should trust only human signatures for file download. I'm not sure how easily all this can be implemented in winrash. In any event, those two lines in the script that I've removed are not the answer. For now I guess we can trust the network. -- Dimi.
[MSVCRT] Separate internal definitions from the public headers
Hi Alexandre,
Welcome back! I did this last Friday, but I didn't want to continue
before running it by you. I'm sending here just the first cut of the
definitions I needed to duplicate in msvcrt.h, to compile the entire
msvcrt DLL without the MSVCRT() define in the public headers.
Looking at the changes it seems to me:
1. There aren't that many
2. We can easily add a test file to check for consistency
with the public headers (ideally, this file would be
automatically generated by a script)
3. We should be able to actually drop some of them, this
is just the first cut, and I've tried to keep the
number of changes to the source code to a minimum.
Should I carry on?
--
Dimi.
Index: dlls/msvcrt/msvcrt.h
===
RCS file: /var/cvs/wine/dlls/msvcrt/msvcrt.h,v
retrieving revision 1.25
diff -u -r1.25 msvcrt.h
--- dlls/msvcrt/msvcrt.h16 Mar 2004 19:17:11 - 1.25
+++ dlls/msvcrt/msvcrt.h4 Jun 2004 23:05:05 -
@@ -28,8 +28,27 @@
#include "winerror.h"
#include "winnls.h"
-#include "msvcrt/string.h"
-#include "msvcrt/eh.h"
+typedef unsigned short MSVCRT_wchar_t;
+typedef unsigned short MSVCRT_wint_t;
+typedef unsigned short MSVCRT_wctype_t;
+typedef unsigned short MSVCRT__ino_t;
+typedef unsigned long MSVCRT__fsize_t;
+typedef unsigned int MSVCRT_size_t;
+typedef unsigned int MSVCRT__dev_t;
+typedef int MSVCRT__off_t;
+typedef long MSVCRT_clock_t;
+typedef long MSVCRT_time_t;
+typedef long MSVCRT_fpos_t;
+
+typedef void (*terminate_handler)();
+typedef void (*terminate_function)();
+typedef void (*unexpected_handler)();
+typedef void (*unexpected_function)();
+typedef void (*_se_translator_function)(unsigned int code, struct _EXCEPTION_POINTERS
*info);
+typedef void (*_beginthread_start_routine_t)(void *);
+typedef unsigned int (__stdcall *_beginthreadex_start_routine_t)(void *);
+typedef int (*MSVCRT__onexit_t)(void);
+
/* TLS data */
extern DWORD MSVCRT_tls_index;
@@ -123,4 +142,363 @@
#define _RT_CRNL252
#define _RT_BANNER 255
+struct MSVCRT_tm {
+int tm_sec;
+int tm_min;
+int tm_hour;
+int tm_mday;
+int tm_mon;
+int tm_year;
+int tm_wday;
+int tm_yday;
+int tm_isdst;
+};
+
+struct _timeb
+{
+MSVCRT_time_t time;
+unsigned short millitm;
+short timezone;
+short dstflag;
+};
+
+typedef struct MSVCRT_iobuf
+{
+ char* _ptr;
+ int _cnt;
+ char* _base;
+ int _flag;
+ int _file;
+ int _charbuf;
+ int _bufsiz;
+ char* _tmpfname;
+} MSVCRT_FILE;
+
+struct MSVCRT_lconv
+{
+char* decimal_point;
+char* thousands_sep;
+char* grouping;
+char* int_curr_symbol;
+char* currency_symbol;
+char* mon_decimal_point;
+char* mon_thousands_sep;
+char* mon_grouping;
+char* positive_sign;
+char* negative_sign;
+char int_frac_digits;
+char frac_digits;
+char p_cs_precedes;
+char p_sep_by_space;
+char n_cs_precedes;
+char n_sep_by_space;
+char p_sign_posn;
+char n_sign_posn;
+};
+
+struct MSVCRT__exception
+{
+ int type;
+ char*name;
+ double arg1;
+ double arg2;
+ double retval;
+};
+
+struct MSVCRT__complex
+{
+ double x; /* Real part */
+ double y; /* Imaginary part */
+};
+
+typedef struct _heapinfo
+{
+ int* _pentry;
+ MSVCRT_size_t _size;
+ int_useflag;
+} _HEAPINFO;
+
+#ifdef __i386__
+typedef struct __JUMP_BUFFER
+{
+unsigned long Ebp;
+unsigned long Ebx;
+unsigned long Edi;
+unsigned long Esi;
+unsigned long Esp;
+unsigned long Eip;
+unsigned long Registration;
+unsigned long TryLevel;
+/* Start of new struct members */
+unsigned long Cookie;
+unsigned long UnwindFunc;
+unsigned long UnwindData[6];
+} _JUMP_BUFFER;
+#endif /* __i386__ */
+
+struct MSVCRT__diskfree_t {
+ unsigned int total_clusters;
+ unsigned int avail_clusters;
+ unsigned int sectors_per_cluster;
+ unsigned int bytes_per_sector;
+};
+
+struct MSVCRT__finddata_t
+{
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ MSVCRT__fsize_t size;
+ charname[260];
+};
+
+struct MSVCRT__finddatai64_t
+{
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ __int64size;
+ char name[260];
+};
+
+struct MSVCRT__wfinddata_t {
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ MSVCRT__fsize_t size;
+ MSVCRT_wchar_t name[260];
+};
+
+struct MSVCRT__wfinddatai64_t {
+ unsigned attrib;
+ MSVCRT_time_t time_create;
+ MSVCRT_time_t time_access;
+ MSVCRT_time_t time_write;
+ __int64 size;
+ MSVCRT_wchar_t name[260];
+};
+
+struct _utimbuf
+{
+MSVCRT_time_t actime;
+MSVCRT_time_t modtime;
+};
+
+/* for FreeBSD */
+#undef st_
Re: Do we still need wineinstall?
On Sun, Jun 13, 2004 at 09:23:53PM +0100, Mike Hearn wrote: > So - do we still need it? I don't think so. You have my vote to nuke it :) (getting rid of it is on the 0.9 TODO BTW) -- Dimi.
Re: [WineHQ] service.cgi fixes
On Tue, Jun 15, 2004 at 05:14:46PM +0100, Paul Millar wrote: > With network security, any activity implies at least some trust. The script > wasn't brilliant, but pushing the functionality into winrash doesn't really > solve the problem: we'd still need to verify the binaries somehow, or just > trust that the binaries are OK. Yes, we need to verify them, but not before we verify the script. Otherwise, it's much easier to feed us a hacked script... > But, in the mean time, I'll continue generating the sig files (as it happens > automatically) so future gpg verification-code has something to test against. Sure, that can't hurt, maybe one day we'll use it. -- Dimi.
Re: WineHQ-hosted projects?
On Wed, Jun 16, 2004 at 07:09:28AM -0400, Joel Konkle-Parker wrote: > I'd like to start up a WINE-based project to further development for a > specific app. (e.g. The WINE-Star Wars Galaxies Project, or The > WINE-Internet Explorer Project). Does WineHQ have a place to host such > things (with their own sites, etc.), or should I turn to SourceForge? WineHQ does not host other projects ATM, SourceForge is the way to go. -- Dimi.
Re: [test.winehq.org] missing tests
On Thu, Jun 17, 2004 at 07:36:52PM +0200, Ferenc Wagner wrote: > Not that I know of. Submitting a patch, thanks for pointing > it out. Speaking of the test results, I've noticed the following problems: 1. Some errors reported in the summary don't get reported in the differences. For example, in today's results: http://test.winehq.org/data/200406171000/ If you look at the summary for the shlwapi:clist test, it reports 2 errors (in red) in the Win98 column. If you click on the "2", you are taken to the Win98 differences table (correctly), but there's no mention in there of the shlwapi:clist test. 2. The differences tables are inconsistent. They seem to prune lines that are all 0 (green), but not all of them. I can certainly still see lines that are all 0. Prunning those lines is not a bad idea, but if we do, then we should do it for all such lines, and we also shouldn't make the '0' in the summary a link, since it has nowhere to take us. 3. We are running multiple test _per_ build, but only one is curretly reported. Currently, it says: Main summary for build 200406171000 where '200406171000' is a link to the test. But since we have multiple downloads, it should be: Main summary for build 200406171000: [0] [1] [2] [3] (or somesuch), where [x] is a link to the download. 4. Each of the testers run and submit 4 sets of tests for a build, but only one is reflected in the results. This is related to the above point, and needs fixing. -- Dimi.
Re: [test.winehq.org] missing tests
On Fri, Jun 18, 2004 at 02:33:31AM +0200, Ferenc Wagner wrote: > "Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > > Good catch, fixed (*) Nice, thanks for the quick fix. > > 2. The differences tables are inconsistent. > > How can you say that?! Do you think WineHQ can't reliably > run my program? :) You may find my logic wrong, though. > The differences show, well, the differences. Lines are > pruned iff - all the reports are the same (char by char) AND >- no run failed AND >- there were no errors (* from now). > It doesn't work as well as I expected because lots of > successful tests produce variable output. I thought about > fixing them, but I could as well change the pruning policy > with much less work. Shall I simply drop the first condition? I think we should. We already have so much data that I don't think anyone will start digging through a row of '0' trying to figure out the differences. It would clean the output a bit. > > we also shouldn't make the '0' in the summary a link, > > since it has nowhere to take us. > > Those links don't target specific lines, so they could as > well stay, but I've got no objection against nuking them. Maybe we can do two things: -- nuke the links for '0' -- make the other things line specific, if it's not too difficult (it shouldn't be, just create the 'id' based on the OS and test name. So say you have an error in Win95, in the kernel:heap test. Just create the id diff_Win95_kernel_heap so the URL should just be: 1 You would need to assign the same id to the element in the difference, but that should be easy as you have all the information available. > > 3. We are running multiple test _per_ build, but only > > one is curretly reported. Currently, it says: > > Main summary for build 200406171000 > > where '200406171000' is a link to the test. But since > > we have multiple downloads, it should be: > > Main summary for build 200406171000: [0] [1] [2] [3] > > (or somesuch), where [x] is a link to the download. > > This is a more complicated issue which I haven't dared to > touch yet. I planned to handle this as different builds, so > there is no machinery in place for this variability. > Neither for the download link, nor for the results. The Tag > could be overloaded for this purpose, and the download links > should go into the differences header for easy access, where > they could also serve as a quick indication of the build > type. Then we need short names or icons for the builds. Nothing too complicated. Just append the above index to the Tag, separated by ':'. So tests submitted by me would be DimiPaun:0 DimiPaun:1 DimiPaun:2 DimiPaun:3 If I submit the results from the _same_ URL twice (say from the '0' one), we can do: DimiPaun:0.0 DimiPaun:0.1 But I don't think we need this complication currently. > > 4. Each of the testers run and submit 4 sets of tests for > > a build, but only one is reflected in the results. > > This is related to the above point, and needs fixing. > > 4? I though it was 2: Kevin's and Paul's. Or do they both > plan to build with MinGW and MSVC? Anyway, the reports For now each submit two: one .zip, one compressed with as a self-extractable. We hope to also have a MSVC build in the future. > should be present with the same tag, successively numbered. > The annoying thing is that people started to number their > tags, which leads to strange-looking headers. Oh well. Not if we separate them as I suggested above. I don't think we currently allow ':' and '.' in the Tag. > It would be possible to subdivide the columns under the tags > by builds. We would need a short build id for this at a > well-defined place, like in a new field in the report or > maybe in the first line of the Build info: block. We can just assign numbers for that as I suggested above. As long as we list in the begginning what each number is (that is, the URL for it) we should be fine. Since they all should come from the same BUILD-ID, there should be no difference between then anyway (usually :). -- Dimi.
Re: [test.winehq.org] missing tests
On Fri, Jun 18, 2004 at 03:41:35AM +0200, Ferenc Wagner wrote: > I think separate columns would serve us better by not > repeating the overly long tags several times. Separate columns are good idea if we can get them. > > For now each submit two: one .zip, one compressed with as > > a self-extractable. > > I'm not sure I understand this. The above two should always > produce the exact same results, shouldn't they? They > contain the same executable after all... Yes, in theory. But before we drop the .zip, we wanted to make sure this is really the case. Unfortunately, we can't see the results for now :( Once we make sure the results are really the same, and the self-expandable archive is not creating any problems, we can drop the .zip. Meanwhile, it serves as a test case for doing multiple submission for the same build id! :) > Ah, finally I understand you. I think. So do you suggest > that [1] and [2] may mean different things on different > pages? That would be possible with what we have now, you > are right. I can give it a shot, but only after having some > sleep and maybe soccer, even. Right, indeed, that was what I had in mind: [1], [2], etc. are local to the page, not global. In other words, say that for build XXX we get get a bunch of returns. We look into them, and it turns out that the set of distinct URLs that generated them are URLa, URLb, URLc, URLd. We just pick the most convenient order (alphabetical would probably be best to avoid to much variability on how we order them), and we just list them: [0] : URLa [1] : URLb [2] : URLc [3] : URLd Nothing that we shouldn't be able to do with what we have now, AFAIU. -- Dimi.
Re: docu update
On Fri, Jun 18, 2004 at 11:26:33AM -0700, Alexandre Julliard wrote: > wineinstall is not out of date, it still works fine, I don't see any > reason to remove it from the doc. It's true, wineinstall works OK, but AFAIK we've decided to remove it sooner rather then later, and I guess now it's a good enough time (given that it doesn't do anything interesting anymore). So looking into the future, wineinstall is deprecated, so we'd better not recommend people use it, it will create more pain when we do actually remove it. -- Dimi.
Re: docu update
On Fri, Jun 18, 2004 at 12:22:10PM -0700, Alexandre Julliard wrote: > I don't see why we have to remove it at all. We have to remove most of > its contents, sure, but even if all it does is wrap "configure;make" > with some user-friendly messages it has some value IMO. To be honest, I would be very happy if we can get rid of it. Let me try to explain why: -- few people still build from source. The stats on SF show that only 15% of people get the source tarball, and there are good reasons for this. -- of the few who do d/l it as tarballs, most are power users that don't need/want a basic wrap around "configure;make" -- it is another abstraction that is unfamiliar to people, that needs to be understood for little gain. For the last point, I'll tell you my experience with such wrappers. First, I try to avoid as much as possible installing software that is not package. On my system, the _only_ such package is wine since I work on it. I will not try to justify it, suffices to say that most people do the same, as shown by the stats. In the few occasions that I had to (in the past) compile from .tar.gz, I was quite frustrated by packages that did not follow the standard configure; make approach. Yes, maybe their little script was more convenient, but for me was a pain: -- I did not trust them. Why did they need a scipt? Why not follow the standard. I know, technically it makes no sense, but a psychological level that was my reaction. Go search and do extra work to (1) see what their script does, and (2) try to use the standard install method. -- once done, I did not have a warm and fuzzy feeling. Did I miss something? Should I have used their prefered method instead? Etc, etc. Providing two ways for such a standard thing is not a good idea. It's a matter of UI, and I've argued in the past that almost always it's better to follow the known standard even unless you think you can improve considerably. Having just a trivial wrapper around "configure;make", and advartising it in the documentation before the well known standard does not do that IMO. Let's remove it and see if people complain, and why they complain. We are likely to find real problems that need fixing anyway. -- Dimi.
Re: docu update
On Fri, Jun 18, 2004 at 07:26:23PM -0400, Vincent Béron wrote: > Le ven 18/06/2004 à 17:44, Alexandre Julliard a écrit : > > That's easy, they will complain about the thing wineinstall takes care > > of, like not having write access to the build tree, conflicts with the > > installed rpm, missing ld.so.conf entry, etc. These things were added > > to wineinstall precisely because many people complained about them. > > ./configure --without-hand-holding could skip over those tests, and they > would be there for a straight ./configure. It wouldn't have to be very > documented... I don't think we should do that. First of all, none of the problems mentioned are wine specific, and I don't think we need to try to fix them like that. Second, as I have already argued, it seems most of our builders from source are already power users, and are most likely used to the configure; make cycle well enough that they don't need the hand holding. In fact, they most likely hate it (as I do). The Linux user landscape has changed quite a bit lately, to the point where having wineinstall probably does more harm than good. -- Dimi.
Re: docu update
> configure or LD_LIBRARY_PATH or whatever. Maybe you don't have > clueless users asking you how to build Wine, but I get quite a bit of > them; and being able to tell them "just run tools/wineinstall" saves > me a lot of grief. That's a fair argument, and I can understand that. If it saves you time and agravation, it's worth it. I guess my main concern is having wineinstall in the main flow of the documentation. You're asking: > What harm do you think it causes? Have you heard of anybody > complaining? Why would any power user run wineinstall if they really > hate it? Well, as I've tried to explain, when I see stuff like this, I'm always left with lingering questions: if I run the standard method (configure;make) that I like, I'm wondering wether I've missed something important. Are the bugs I'm seeing caused by me not running wineinstall? If I do run wineinstall, I do it against my first impulse so to speak, and then I keep wondering why the heck couldn't they just stick to the standard method. I can't speak for others, but for me it's annoying (in projects that I just install, not wine where I know what's going on). Normally I'd suggest that clueless users use a packaged wine instead, but you have a good point about building the latest CVS. Hmmm. Maybe making it less proeminent in the documentation, but still keeping it around so you can point users to it? Blah, maybe you're right, and people can't really run configure; make Shame. -- Dimi.
Re: docu update
> (a) and (b) can be solved by WineHQ providing its own distro-neutral, run > anywhere binary packages. This isn't hard as Wine is generally excellent > at running on different peoples machines from the same binaries - after > all, CodeWeavers need it. I think a nice installer for correctly built > distro-neutral binaries for Wine would go a long way towards cutting the > number of non-developers building from source down to zero. I don't think we're doing too badly with the current packages -- over 85% of people go for them. Having a distro-neutral binary packages would be good, and it may shave off another 5% or so of the people who do go for source downloads. The main problem however is that Wine is rapidly changing, and there is a need to build from CVS. No amount of packaging the official releases will solve that problem. But a distro-neutral might, because it makes it feasible to provide automated nightly build on SF, just like we do with winetest. Such a package can take care to avoid conflicts with already installed .rpms, etc., stuff that wineinstall is doing right now. So, what about a autopackage package? :) -- Dimi.
Re: docu update
On Sat, Jun 19, 2004 at 10:37:54AM -0700, Alexandre Julliard wrote: > users build without having to fight the autoconf tools. It's for the > same reason that we have wineinstall. Of course I'm all for improving > the binary packages, but it doesn't avoid the need to also support > source builds. Supporting source builds, and making them easy, is a worthy goal, and we all understand that. We're not arguing to not support them. Virtually every package out there works with the standard: configure; make We're arguing that wine should work just like that, without requiring addition wrapper scripts. Now, you've pointed out some uses cases (namely newbies that need to build a most recent version), where a wrapper script is useful to avoid some potential problems. For this use case, it seems to us that a prepackaged binary would be double useful: -- it's easier on the user (let's face it, even if it's only one command, compiling Wine is not that fun, it used to take me 1h and a lot of HD space). In fact, compiling is not the problem. The user needs to get the latest CVS tree, install devel packages, etc. all of which is a lot more complicated then configure; make. Installing a binary package on the other hand, is a lot faster, which means that the user will more likely go through with the operation. -- it's better for us, because we have a controlled build that we understand. We can build it so it has all the extensions enabled, and do it properly, on a known tool chain. This is an important attribute when dealing with a completely clueless user, and is in fact important on it's own, apart from the current wineinstall discussion. The rest of source users will be able to deal with the configure; make no problem. The above is by no means complicated. -- Dimi.
Re: winemaker problems for creating winelib DLL projects - Solved + bug in winemaker
On Sun, Jun 20, 2004 at 01:36:15PM +0300, Shachar Shemesh wrote: > Shachar Shemesh wrote: > > I managed to solve the above problem by adding a "-shared name.spec" to > the Makefile line that invokes the last winegcc. However, I think > winemaker should have added that line itself. Is this a bug? Most likely, winemaker is in need of some love. Patches welcome. :) -- Dimi.
Re: Setting up drive letters without wineinstall?
On Sun, Jun 20, 2004 at 06:21:58PM +0400, Vitaly Lipatov wrote: > Please do not do it by default. Noone can parse my fstab > correctly :) Maybe it needs fixin' :) -- Dimi.
Re: MSVCRT - __unDNameEx
On Mon, Jun 21, 2004 at 11:33:24AM -0400, Andrei Barbu wrote: > Is there a reason this isn't used there? or can I clean it up a little > and include it? Yes it does have some fixme's, but it's better than > ignoring it. I can't see why not. -- Dimi.
Re: LISTBOX_Directory() returns LB_OKAY for invalid directory / f ilen ame
On Tue, Jun 22, 2004 at 11:08:28AM -0700, Krishna Murthy wrote: > The 'le' is an integer value and not a bitwise value. This means it could > have only one error condition at a time. Right. Because of this fact: > if ((le != ERROR_NO_MORE_FILES) || (le != ERROR_FILE_NOT_FOUND)) return > LB_ERR; Will always return LB_ERR. Proof: (le != ERROR_NO_MORE_FILES) || (le != ERROR_FILE_NOT_FOUND) ## by deMorgan's Law == !((le == ERROR_NO_MORE_FILES) && (le == ERROR_FILE_NOT_FOUND)) ## by transitivity == !(ERROR_NO_MORE_FILES == ERROR_FILE_NOT_FOUND) ## by the definition of these error codes == !(18 == 2) ## different numbers are not equal == !(FALSE) ## by negation == TRUE ;) -- Dimi. P.S. I haven't done a formal proof since I was doing my M.Sc. at UofT :)
Re: !LOSTWAGES! site misc updates
On Fri, Jun 25, 2004 at 07:35:23PM +0200, Ivan wrote: > As in subject. Jeremy, please let me know if there's anything wrong in this patch. Do you really think we need to switch from American to English spelling? What if someone else is sending a patch to convert back to American? I think the spelling is fine the way it is now. -- Dimi.
[RFC] Wine upgrade procedure (spec)
Hi folks, It seems that we are getting ever so closer to 0.9. Slow, but steady. Looking at the TODO, it looks like upgrading is one of the big showstoppers, in that it will affect (1) the end-user experience, and (2) how we deal with the configuration. So this seems like a good time to start discussing this topic, as we need to eventually reach the elusive 0.9. This seems to be a difficult topic, so we need to approach the problem well prepared. That is, we need to first define (and agree) on what we need to solve here. So after a tumultuous discussion on IRC, I decided to get the ball rolling. Intuitively, upgrading wine is simple to understand: once a new version is installed, we need to get users in a state where they can use it. While simple to state, this problem is complicated by the various corner cases that can appear in Real Life (TM): -- native vs. builtin DLLs handling -- multiple Wine installations on a box -- updating only some DLLs -- integrating into the Unix environment -- dealing with Windows software We can also look at some important use-cases that we need to support, but before we do, the following must hold true in all cases: -- administrators should be able to install a new Wine on the system easily with "rpm -U" (or equivalent). -- the upgrade should not erase registry settings that are managed by the user Let's look at the use-cases: A. Global Install In this case, both Wine code, as well as applications are installed globally, for all users to access. This is the most Unix-like setup, but unfortunately the most difficult to support, due to the fact that Win32 apps simply expect a different environment. Since we can't control application's code, this setup may present some limitations, but it may be sufficient for sites that need a limited set of applications. For this to work, it is acceptable that we ship special scripts that know about the applications that are supported, so that they can work around inherent limitations in the applications themselves. Users should transparently be able to use the new version of wine, the next time they start wine. B. Mixed Install Here, Wine code is installed globally, but applications are installed in the user's account. In a way is like (A) but with some additional applications installed directly into the user's account. Same requirements apply to this case as well. C. Local Install Both Wine code, as well as applications are installed locally, into the user's account. The Wine code is still installed globally by the administrator (as in A & B), but it is copied locally before it's being used. An upgrade in this case may require an explicit action by the user, so the upgrade can happen at a controlled time, when the user desires it. In all of the above, there is always state in the user directory. Thus, it is imperative that the upgrade process makes sure that after the upgrade, the user-private state is consistent with the new code base. Also, any solution must take into account that the registry must be created on the fly, as it is created when registering the DLLs. Before we go any further, I'd like to ask everybody to contribute their thoughts/requirements/desires so that we get a conprehensive view of the problem we are trying to solve. Thanks for reading this far! -- Dimi.
Re: [RFC] Wine upgrade procedure (spec)
On Tue, Jun 29, 2004 at 11:49:12AM +0100, Mike Hearn wrote: > Short of copying the entire codebase into the users account when they > explicitly choose to upgrade (ew, no other program does this) I can't see I agree, I personally hate this too, but Alexandre has a point in that this may be the most compatible setup, so at least in theory we should be able to support it just in case we need to employ it later. However, I'm fairly sure we don't need to actually get a working version for it at this time, we just need to make sure we could, if we wanted to, without replacing the entire upgrade mechanism. > a good way of upgrading Wine while it's running that's free of race > conditions. For instance, you could be in the middle of upgrading when a > program you're running starts a new process: the wineserver may be using a > different protocol to what the DLLs expect. > > I really don't think for now we should try and support upgrades while > running. It should probably be up to the packages/install scripts to alert > the user if they try that. Agreed. I think the most important thing is for Wine to integrate nicely with the system where it's running, so that rpm -U / yum update works as expected. If we go overboard with these sort of things, we may screw up the OS integration (remember, rpm -U must be able to run unattended for example), and this is a greater evil. Also, we have to be careful to not be more catholics than the Pope: I really doubt that any significant number of apps out there support 100% upgradability when they are running. In other words, an app that has more than one config/data file, would need to do locking to make sure that the data set that's spread around the files is treated atomically during upgrade. I personally think we can live with the race when we read in the registry files, but if that causes problems, we can add some locking so that we can read them in atomically. Maybe Alexandre can comment on this, he seems to have thought of this scenario already. > > We can also look at some important use-cases that we need to support, > > but before we do, the following must hold true in all cases: > >-- administrators should be able to install a new Wine on the > > system easily with "rpm -U" (or equivalent). > > This is a use case we should definitely support but perhaps only in a > special configuration where wine is a script which checks for a new > version and copies it across next time it's started, or something like > that. That will not work, we install as root, we run it as a regular user. Really, I see no difference between this and option (B) from the upgrade mechanism point of view, I think the challange here is to simply get the apps to run in this environment. We may need scripts that create fake directories with a bunch of symlinks, etc. but this is another matter. > > In all of the above, there is always state in the user directory. Thus, > > it is imperative that the upgrade process makes sure that after the > > upgrade, the user-private state is consistent with the new code base. > > Also, any solution must take into account that the registry must be > > created on the fly, as it is created when registering the DLLs. > > One possible solution here is a new wineserver request that switches the > registry files in use, so to update the registry in a way that doesn't > disturb currently running programs you can connect to a new wineserver > instance (separate socket), switch registry files to "system.reg.new" or > whatever, run wine.inf and then have another request which does an atomic > rename of the registry files over the new ones once merged. This means the > old wineserver instance is still using the old registry file inodes, but > next time the Wine session is started up it'll be using the new registry. Right, I was thinking along the same lines, but I'm not sure we can work with the same wineserver. For one, we will have one wineserver instance per user, running as the user, whereas for global install we need one that runs as root. But we do need to create these files at runtime, so we may need a special operation mode to achive it. -- Dimi.
Re: Missing declaration for MSVCRT_div_t and MSVCRT_ldiv_t
On Tue, Jun 29, 2004 at 01:27:23PM +0200, Pierre d'Herbemont wrote: > Hi! > > On non-i386 we have to define MSVCRT_div_t and MSVCRT_ldiv_t. Please also add the appropriate tests to tests/headers.c. -- Dimi.
Re: Scrollbars, an application bug or a wine regression ? (#2314)
On Wed, Jun 30, 2004 at 10:04:49AM +0200, George Marshall wrote: > Well no, with the Wine release of May the application had no > scrollbars (correctly) while with June release the scrollbars > are shown and are not working properly. Figuring out the exact patch that introduced the problem would be most helpful: http://winehq.org/site/docs/wine-devel/cvs-regression -- Dimi.
Re: Initial creation of directory and config with ttydrv
On Sat, Jul 10, 2004 at 01:54:30PM +0100, Mike Hearn wrote: > On Sat, 10 Jul 2004 09:55:20 +0300, Shachar Shemesh wrote: > > That's ugly. I cannot touch a file that doesn't belong to me. > > Just submit a patch that lets you override the video driver in use via an > environment variable. Can't we just try to load the ttydrv if the x11drv fails to load? (That is, when there's no explicit driver setting). -- Dimi.
Re: Is bugzilla worth keeping?
On Sun, Jul 25, 2004 at 03:02:13PM +0100, Mike Hearn wrote: [finally back on email, account was busted for a while] > Dimi thought it should be kept as well, but thought the UI could be > improved a lot: for instance a mail based interface would be good. He > also thought a dedicated triage guy would be great. Realistically > though that's not likely to happen anytime soon. Alexandre basically > agreed with this view, I think. There's no reason this shouldn't happen anytime soon. We had a few great guys triaging bugs in Bugzilla. People are looking to help, maybe someone steps up to the task. -- Dimi.
Re: WineHQ:service.cgi: fix winrash option
On Wed, Jul 28, 2004 at 11:51:58PM -0400, Kevin Koltzau wrote: > On Wednesday 28 July 2004 04:36 pm, [EMAIL PROTECTED] wrote: > > Your help is much appreciated. This is a tricky issue it seems as SF isn't always > > reliable for downloads... > > Gentoo handles this situation fairly well, it simply uses a URL format > 'mirror://sourceforge/project/file' > and has a small database of sourceforge base urls that are tried in a round robbin > until all are attempted > or the file is successfully downloaded. Possibly a solution similar to this may work > for us I still don't understand why we need all this complication. All you need to do is to have a *private* list of such mirrors, and to simply poll them after uploading until you can successfully download the file from one of them. At that point, use that mirror's address to publish the release on WineHQ. -- Dimi.
Re: Test drive error
On Thu, Jul 29, 2004 at 01:50:20PM +0300, sergio ojalvo wrote: > Hi > I'm working on Debian Linux. I just install the wine packages and > download sources for trying the test driver. > Running Winemaker to winemine test project I note: that configure script > was not created and Makefile is created instead of Makefile.in. (like > wrote in the web page) > I think is a new feature... I'm wrong? It is a new feature, it's true. > Anyway, I try to run make after that and that is the output: > > winebuild -o winemine.exe.dbg.c --debug -C. dialog.c main.c > winegcc -c -mno-cygwin -I. -o winemine.exe.dbg.o winemine.exe.dbg.c > winegcc -c -mno-cygwin -I. -o dialog.o dialog.c > winegcc -c -mno-cygwin -I. -o main.o main.c > wrc -I. -foEn.res En.rc > En.rc:23:22: Error: syntax error That means there's something around line 23 in the En.rc file that wrc doesn't understand. Can you send us a copy of the file? > After that I try with another 2 projects (win32 code) and I receive a > lot of compilation errors like: > > In file included from /usr/include/c++/3.3/iosfwd:46, > from /usr/include/c++/3.3/ios:44, > from /usr/include/c++/3.3/ostream:45, > from /usr/include/c++/3.3/iostream:45, > from midi2nokia.cpp:4: > /usr/include/c++/3.3/i486-linux/bits/c++locale.h:53: error: `uselocale' > was not declared in this scope Using the std C++ lib is still a problem if you need to use msvcrt. Try to use wineg++ (instead of winegcc) *without* the -mno-cygwin flag. -- Dimi.
Re: Test drive error
On Thu, Jul 29, 2004 at 10:05:09PM +0300, sergio ojalvo wrote: > I get the tar files with the sources from sourceforge and didn't change > this file. Yes, but unfortumately, winemaker is not perfect, and in this very case it's buggy. En.rc is not meant to be compiled independently, but rather be included in another file. That's why you need to manually fix the Makefile, but replacing En.rc with rsrc.rc. > > Using the std C++ lib is still a problem if you need to use > > msvcrt. Try to use wineg++ (instead of winegcc) *without* > > the -mno-cygwin flag. > Can you explain exactly what to do? I'm newbie on this project. > I just do: > $ winemaker --mfc -Imydir . > $ make Once again, winemaker is far from perfect. You need to manually adjust and fix the generated Makefile. In this case, as I said, 1. replace winegcc with wineg++ 2. get rid of the -mno-cygwin flag -- Dimi.
Re: Linking with dlls and Linux libs using winelib?
On Fri, Jul 30, 2004 at 11:06:29AM +, James Supancic wrote: > I need to compile a Windows application under Linux. I need to use dlls and > Linux librarys. No matter what I try I can't get winegcc to include the > Linux librarys in the linking stage. What must I do to get winegcc to link > with both the dlls and Linux libs? We can start by sending us a run of the linking stage with the -v -v options. -- Dimi.
Re: list view completely mangled in WINE
On Fri, Jul 30, 2004 at 05:26:57PM +0200, Tobias Burnus wrote: > Hello, > > in Crystal Impact's Diamond the list view is completely mangled and only > barely recognizable as list view. Tobias, I'll try to look into it. I have been however immensely busy lately, so please remind me if I don't get back to you soon. -- Dimi.
Re: list view completely mangled in WINE
On Sat, Jul 31, 2004 at 05:52:21AM +0200, Filip Navara wrote:
> Tobias Burnus wrote:
> [snip]
>
> Can you try the attached patch please?
>
> Changelog:
> - Don't update infoPtr->dwStyle in LISTVIEW_WindoProc. It's already
> handled in LISTVIEW_StyleChanged and LISTVIEW_Create processing.
>
> - if (infoPtr)
> - {
> -infoPtr->dwStyle = GetWindowLongW(hwnd, GWL_STYLE);
> - }
> -
>switch (uMsg)
>{
>case LVM_APPROXIMATEVIEWRECT:
Can you please explain why updating it is a problem? Yes, we may be
doing more work than needed, but at most it should be a no-op.
In fact, we used to call 'GetWindowLongW(hwnd, GWL_STYLE)' every
time we needed to get to the dwStyle, so updating it in there
should be OK.
BTW, I've tried to install the demo, but the installer dies on my
version of wine. Does it work for you, or did you use Windows for
the installation?
--
Dimi.
Re: list view completely mangled in WINE
On Tue, Aug 03, 2004 at 01:42:28AM +0200, Filip Navara wrote: > Unfortunetly I can't explain it, because I don't understand it myself. I In which case I must object to the patch :( It seems we're just hiding a problem in a very convoluted way, don't you think? > have inserted debug messages on all the places where the listview > display mode can be changed and none of them appeared. After going once > more through the whole code I found this. Obviously it seemed redundant > and the only reason for doing that was workarounding problems with > changed WS_VSCROLL and WS_HSCROLL styles (which correctly don't recieve > WM_STYLECHANGED notifications from the scrolling code). So I tried > removing it and ... whoa ... to my surprise it started to work. The problem is that WM_STYLECHANGED is sometimes sent, sometimes not, and it seems so much easier to just update it every time we come in so we can be sure we're using the latest value, as we should. It's redundant, I agree, but it's neglijable in terms of performance so I've put it in due to it's simplicity. This way the dwStyle has a very simple to understand semantics. In fact, I've meant to remove it eventually, just like you did, but only as an optimization. However, doing so to fix a bug in a way that we don't understand worries me greatly. I'd rather keep it in, and fix the problem. -- Dimi.
Re: list view completely mangled in WINE
On Tue, Aug 03, 2004 at 03:17:27AM +0200, Filip Navara wrote: > I did another test. I intserted a code into the ListView window > procedure to print a message every time the internal dwStyle member > doesn't match the one returned by GetWindowLong with GWL_STYLE. To my > little surprise they were different right from the beginning (even for > WM_CREATE message). The one returned by GetWindowLong didn't contain the > listview specific flags, If so, how did the listview work at all until now?!? > WS_VSCROLL/WS_HSCROLL sometimes didn't match > (as I explained why) and for the WS_CREATE message the WS_VISIBLE flag > was different. I searched my local MSDN copy in order to find why this > happens and the only relevant article I found is this: > http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q83366. The Good stuff, maybe we should link to it from WineHQ > "SUMMARY" part of the article sort of explains why this happens (at > least according to my understanding) and so I think the patch is OK. Do > you agree? Almost. If it does go in though, we need to: -- fix a few more places where we look at WS_[VH]SCROLL -- understand why did the listview work at all if the LVS_ stuff was missing -- do an audit (or add a Janitorial task) to audit and fix the other controls as well. (of course, only the 1st point is really needed for the patch to go in, but the other two would be nice to have). -- Dimi.
Re: Add debugstr_rect alias for consistency with other debugging functions.
On Sat, Aug 07, 2004 at 04:00:25PM -0700, Alexandre Julliard wrote: > Mike Hearn <[EMAIL PROTECTED]> writes: > > > The lack of this confused me for a few minutes, might as well stick it in. > > It's missing because it violates namespace rules. The other debugstr > functions are here for historical reasons but we shouldn't add new ones. Please let's not do this inside of Wine. Clearly, we want to export everthing with the WINE_/wine_ prefix, I'm not debating this. I can also see that we want to be consistent, and that's a good thing -- for all but the debugging API our symbol invokations are far and few in between, and it actually *helps* to see when we call a non-standard API. However, the exact opposite holds for the debugging API: it is the most used API in the source, and it doesn't help to know that it's a Wine API. Having the prefix on every single symbol of this API would not only greatly clutter the code, but I'd also claim it's not the style we should promote. People should try to write portable Win32 code (and here portable is between MS Windows and Wine), and a wine_ prefix is a big bad warning sign. One should be able to grep the sources for wine_ to figure out such places. Hiding them inside mountains of debug calls will not help. Usage of the debug API should not tie the code to Wine, and the source should make it clear. We should promote symbol renaming for Winelib apps (just like we do in Wine today): #define ERR WINE_ERR #define TRACE WINE_TRACE ... Apart for much cleaner code, it's also useful, as I can see many people do: #ifdef WINE #define ERR WINE_ERR #define TRACE WINE_TRACE ... #else #define ERR printf #define TRACE printf ... #endif I have a sentimental attachment to the Wine's debugging API, as it was the first project that I undertook in Wine. It was what "hooked" me in. This may be a small issue, and probably I shouldn't care, but I can't help it. I truely think requiring the WINE_/wine_ prefix inside of Wine for commonly used symbols in the debugging API is not a good direction, and I really hope we can revisit this decision. -- Dimi.
Re: Wine devel: Two MFC bugs
> The first is a display problem of edit boxes; for some reason the text > (numbers) are displaying left justified, instead of right justified. The > edit boxes are definitely set for right justified and display fine in > Windows. This is a known problem. Our edit control does not currently support the ES_RIGHT style at this time. > The second bug is that when I multi-select files to perform an operation on, > nothing happens. One selected file works fine, but any additional ones cause > nothing to happen. Works fine in Windows. What control are you using for the multi-select? -- Dimi.
Re: Win API Stats
On Thu, Aug 12, 2004 at 03:36:38AM -0400, Tom wrote: > Hello, > > The Win API Stats page is broken in a bad way! > See: http://www.winehq.org/site/winapi_stats > I think we should just go with > http://fgouget.free.fr/wine/winapi_stats-en.shtml No, we should just fix it, it was working fine some time ago. It is, in fact, running the same code as Francois'. -- Dimi.
Re: Acknowledgment page
On Thu, Aug 12, 2004 at 08:56:24AM -0500, Jeremy White wrote: > Hmm. I have several thoughts on this. First, I think > that corporate sponsors get enough 'props'. While I appreciate > the gesture, I'd rather the acknowledgements page highlight > the many people who do good work for Wine without > pay or other recompense. I still find it informative to see what companies did, so I suggest we simply move them towards the bottom of the page, rather then remove the info altogether. -- Dimi.
Re: NTDLL: Fix signed/unsigned comparison warnings
On Fri, Aug 13, 2004 at 03:14:21PM +0200, Hans Leidekker wrote: > > This time I have tried to be more careful, by not watching a > football match at the same time for example ;) And with this > patch all tests still succeed, although they would not detect > every signedness change of course. Any gadge on if/when will be able to turn this warning on by default? How many warnings are currently left? -- Dimi.
Re: comctl ipaddress enable not working
On Fri, Aug 13, 2004 at 03:10:01PM -0400, Robert Reif wrote: > I have a program which will not gray out an IP address control when it > is not enabled. ipaddress is a distant memory :) I can look at it in a few days, I'll be leaving for the weekend in a few hours, so I can not do it sooner. -- Dimi.
Re: Backtrace Dumps
On Tue, Aug 17, 2004 at 04:03:33PM -0700, Alexandre Julliard wrote: > Robert Shearman <[EMAIL PROTECTED]> writes: > > I think it's better to let the debugger take care of that. If you > don't want a real breakpoint you could define a custom exception to > tell winedbg to just dump the backtrace and continue. I am not 100% how the patch that Robert's proposing would work in practice, but I can tell you (from working with Java for a long time now) that having readily available backtraces is invaluable. I for one love backtraces, but on the other hand I don't much care for debuggers. Having access to them without being forced to go through the debuger would be much appreciated. -- Dimi.
Re: Wine Status - User Interface
On Tue, Aug 17, 2004 at 07:31:33AM -0400, Tom wrote: > I haven't done the changelog so just view this againt > http://www.winehq.org/site/status_ui for changes or diff. > > commits, suggestions, and flames are welcomed Looks good! -- Dimi.
Re: iostream and msvcrt?
On Wed, Aug 18, 2004 at 11:32:33AM +0300, Boaz Harrosh wrote: > >I have used STLport before > >so the idea sounds feasable to me. I imagine I have to change the > >gcc-linux.mak by: > > > >replacing the call to gcc with winegcc, > >removing references to GLIBC, > > > > > Better go with gcc-mingw.mak, as threading and OS is more Windows than > Linux. See if they have a -nocygwin variant. Yes, it should work with the gcc-mingw.mak by changing gcc -> winegcc g++ -> wineg++ > >adding a path pointing to /include/wine/MSVCRT. > > > > > > > Yes exactly. You'll see that you end up with a complete xxx-wine set of > makefiles and headers. No, you shouldn't need that. You just need to make sure you pass the -mno-cygwin flag to winegcc/wineg++. -- Dimi.
Re: iostream and msvcrt?
On Thu, Aug 19, 2004 at 04:00:19PM +1000, Scott Snell wrote: > Hi Dimi, > > Thanks for helping out. I made the changes you suggested to the > gcc-mingw.mak file for STLPort. When I go make it does a: > > wineg++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized > -mno-cygwin -O2 -D_STLP_USE_DYNAMIC_LIB dll_main.cpp -c -o > ../lib/obj/MINGW32/ReleaseD/dll_main.o > > which throws up a world of errors, such as: > > In file included from ../stlport/cstdlib:25, > from ../stlport/stl/debug/_debug.c:160, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:40, > from dll_main.cpp:35: > /usr/include/c++/3.3.2/cstdlib:97: error: `div' not declared > /usr/include/c++/3.3.2/cstdlib:102: error: `ldiv' not declared > /usr/include/c++/3.3.2/cstdlib: In function `ldiv_t std::div(long int, long > int)': Just got back from vacation. Why is it including a cstdlib? Anyway, can you send me exactly what you did, so I can try to reproduce it on my box? -- Dimi.
Re: Fix bin2res Help Text
On Mon, Sep 06, 2004 at 02:37:05AM +0100, Robert Shearman wrote:
> "/* BINRES idb_std_small.bmp */\n"
> - " {}\n"
> + "IDB_STD_SMALL BITMAP idb_std_small.bmp\n"
> + "/* {\n"
> + "} */\n"
What's wrong with the current help. I thought BINRES is the marker...
--
Dimi.
Re: Simple bugzilla question
On Wed, Aug 25, 2004 at 07:23:44PM +0100, Ann and Jason Edmeades wrote: > My understanding is I accept it and assign to myself, then fix it, then > what... Do I put the bug in fixed state and submit the patch or leave that > change to the raised? You submit the patch to wine-patches, and then add a note with a link to the wine-patches archive of your message. Once it is committed, you mark it FIXED, and you add a link to the wine-cvs archive of the committed patch. After that, hopefully the original submitter will verify that the fixed work for him, and will close the bug. Keep an eye on it, and if that does not happen in 2 weeks or so, CLOSE it yourself. -- Dimi.
Re: Acknowledgement page
On Sat, Sep 04, 2004 at 04:37:52PM -0600, Brian Vincent wrote:
> Should have explained that bit.. anyone listed on the Who's Who
> page doesn't show up here. This list will fall right under that on
> the introduction page.. but perhaps I need to add a reference back
> to the Who's Who page.
I think the page looks good, but this set difference between this page
and Who's Who makes things overly complicated (to the point where there
always be confusion, no matter how may links you put in). It's much
easier to understant if we have a liner and uniform definition for the list:
All people that contributed more than {8,10,12,15} patches.
Or whatever other criteria.
Also, I think we should have a proeminent place for Alexandre,
he's given so much to this project, more then anyone else. He
deverves a statue, if one could be build on the site, as far as
I am concerned.
--
Dimi.
Re: test.winehq.org site
On Wed, Sep 08, 2004 at 06:32:31PM +0200, Saulius Krasuckas wrote: > When can we expect it to be up and running? It is up and running, we're just missing an index page. Until that gets created, use this link instead: http://test.winehq.org/data/ Unfortunately, the testing process has been broken lately, for unknown reasons. -- Dimi.
Re: Linking with winelib
On Sat, Sep 11, 2004 at 04:13:30AM +0600, Nikolay A. Liber wrote: > Hello > > I am using winelib with Mono hack to load windows DLL into python > module. There is a dummy function wine_pthread_init_thread in > libwine.so. wine_pthread_init_thread implemented in winelib.so.exe from > mono shared winelib. I link module. > > gcc -shared mymodule.so module_code.o -lwine ./winelib.so.exe > > But when I load module init_thread from ntdll calls dummy > wine_pthread_init_thread. How to override that dumy function? I think it's probably better to build python as a Winelib app instead of using the Mono hack. They had a very narrow set of requirements which may not be enough for Python, and you will experience all sorts of weird problems if that's the case. -- Dimi.
Re: dinput axis mapping and format mapping patch
On Fri, Sep 10, 2004 at 09:46:42AM +0100, Mike Hearn wrote: > OK, makes sense. I'll work on adapting winecfg. I'll also try compiling > a list of the registry entries we use, I don't think there is any such > list currently is there? Please work on this one, it needs love: http://winehq.org/site/status_options -- Dimi.
Re: winecfg (was Re: W->A calls)
On Fri, Sep 10, 2004 at 08:19:09PM +0200, Joris Huizer wrote: > site about that (I found a http://sourceforge.net/projects/winecfg/ but > it seems the last update was over a year ago..) > What's there to do, how to... etc - kind find much documentation except > for the fact it's mentioned as a Todo thing :-/ If you want to work on winecfg, use the one in the Wine tree, in the programs/winecfg directory. -- Dimi.
Re: Correct ConvertSidToStringSidW with test
On Sat, Sep 11, 2004 at 08:37:09AM -0700, Juan Lang wrote: > ConvertSidToStringSidW was incorrect for low-value > authorities; it put spaces in the resulting string. > This corrects that, and includes a test case for it. Content-Description: advapi32.diff Uniffied diff, please :) -- Dimi.
Re: Other W->A crosscalls
On Wed, Aug 25, 2004 at 02:17:22PM -0400, Vincent Béron wrote: > That was with current CVS, before Alexandre last commits :) > Yes, they did disappear. Attached is a revised log. Here is a somewhat cleaned up list. It's not too bad it seems, at 144 entries: crypt.c 514 CryptAcquireContextW: call to CryptAcquireContextA crypt.c 1136 CryptEnumProviderTypesW: call to CryptEnumProviderTypesA crypt.c 1299 CryptGetDefaultProviderW: call to CryptGetDefaultProviderA crypt.c 1754 CryptSetProviderExW: call to CryptSetProviderExA string.c 630 StrRStrIW: call to COMCTL32_ChrCmpIA tooltips.c 1044 TOOLTIPS_AddToolW: call to SendMessageA colordlg.c 1292 ChooseColorW: call to FindResourceA filedlg.c 481 GetFileDialog95W: call to GetCurrentDirectoryA filedlg.c 501 GetFileDialog95W: call to SetCurrentDirectoryA filedlg.c 3668 GetFileName31W: call to GetWindowLongA fontdlg.c 1135 FormatCharDlgProcW: call to GetPropA printdlg.c 165 PRINTDLG_SetUpPrinterListComboW: call to GetDefaultPrinterA printdlg.c 167 PRINTDLG_SetUpPrinterListComboW: call to SendDlgItemMessageA printdlg.c 384 PRINTDLG_UpdatePrintDlgW: call to LoadStringA printdlg.c 387 PRINTDLG_UpdatePrintDlgW: call to LoadStringA printdlg.c 389 PRINTDLG_UpdatePrintDlgW: call to MessageBoxA printdlg.c 684 PRINTDLG_SetUpPaperComboBoxW: call to SendDlgItemMessageA printdlg.c 691 PRINTDLG_SetUpPaperComboBoxW: call to SendDlgItemMessageA printdlg.c 748 PRINTDLG_SetUpPaperComboBoxW: call to SendDlgItemMessageA printdlg.c 763 PRINTDLG_SetUpPaperComboBoxW: call to SendDlgItemMessageA printdlg.c 768 PRINTDLG_SetUpPaperComboBoxW: call to SendDlgItemMessageA printdlg.c 1101 PRINTDLG_ChangePrinterW: call to LoadStringA printdlg.c 1103 PRINTDLG_ChangePrinterW: call to SendDlgItemMessageA printdlg.c 1112 PRINTDLG_ChangePrinterW: call to SendDlgItemMessageA printdlg.c 1116 PRINTDLG_ChangePrinterW: call to SendDlgItemMessageA printdlg.c 1169 PRINTDLG_ChangePrinterW: call to SendDlgItemMessageA printdlg.c 1305 PRINTDLG_WMInitDialogW: call to LoadImageA printdlg.c 1307 PRINTDLG_WMInitDialogW: call to LoadImageA printdlg.c 1311 PRINTDLG_WMInitDialogW: call to LoadIconA printdlg.c 1313 PRINTDLG_WMInitDialogW: call to LoadIconA printdlg.c 1317 PRINTDLG_WMInitDialogW: call to SendDlgItemMessageA printdlg.c 1334 PRINTDLG_WMInitDialogW: call to RegisterWindowMessageA printdlg.c 1612 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1615 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1667 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1676 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1696 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1700 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1706 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1723 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1726 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1733 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 1736 PRINTDLG_WMCommandW: call to SendDlgItemMessageA printdlg.c 2507 PRINTDLG_PS_UpdateDlgStructW: call to GetDlgItemTextA printdlg.c 2508 PRINTDLG_PS_UpdateDlgStructW: call to GetDlgItemTextA printdlg.c 2509 PRINTDLG_PS_UpdateDlgStructW: call to GetDlgItemTextA printdlg.c 2510 PRINTDLG_PS_UpdateDlgStructW: call to GetDlgItemTextA printdlg.c 2712 PageDlgProcW: call to SetPropA printdlg.c 2744 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2746 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2748 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2750 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2756 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2757 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2758 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2759 PageDlgProcW: call to SetDlgItemTextA printdlg.c 2768 PageDlgProcW: call to GetPropA main.c 245 DirectDrawEnumerateExW: call to DirectDrawEnumerateExA font.c 242 FONT_EnumLogFontExWToA)(pointer_type(parm_decl(fontW: call to FONT_LogFontWToA font.c 314 FONT_NewTextMetricExWToA)(pointer_type(parm_decl(ptmW: call to FONT_TextMetricWToA printdrv.c 99 StartDocW: call to HEAP_strdupWtoA printdrv.c 101 StartDocW: call to HEAP_strdupWtoA printdrv.c 103 StartDocW: call to HEAP_strdupWtoA printdrv.c 106 StartDocW: call to StartDocA comm.c 2161 CommConfigDialogW: call to HEAP_strdupWtoA comm.c 2164 CommConfigDialogW: call to CommConfigDialogA comm.c 2286 SetDefaultCommConfigW: call to HEAP_strdupWtoA comm.c 2289 SetDefaultCommConfigW: call to SetDefaultCommConfigA resource.c 235 FindResourceExW: call to get_res_name_type_WtoA lzexpand_main.c 313 GetExpandedNameW: call to GetExpandedNameA lzexpand_main.c 564 LZOpenFileW: call to LZOpenFileA rpc_binding.c 335 RPCRT4_CreateBindingW: call to RPCRT4_strdupWtoA rpc_binding.c 367 RPCRT4_CompleteBindingW: call to RPCRT4_strdupWtoA rpc_binding.c 370 RPCRT4_CompleteBindingW: call to RPCRT4_strdupWtoA rpc_binding.c 372 RPCRT4_CompleteBindingW: call to RPCRT4_strndupA rpc_binding.c 1032 RpcBi
Re: resend: patch: shell32.dll - SHELL_ArgifyW expands env-vars
On Mon, Sep 13, 2004 at 09:44:12AM +0100, Mike Hearn wrote: > > >Check out the NEW! IMPROVED! Wine developer cheatsheet here: > >http://navi.cx/~mike/wine/developer-cheatsheet.html > >Everything you always wanted to know but were too afraid to ask, >in ONE convenient document!! > > Cool. I hope you know this will have to end up on WineHQ, under the Development section, right? :) -- Dimi.
Re: Other W->A crosscalls
On Tue, Sep 14, 2004 at 11:22:46PM +0200, Michael Stefaniuc wrote: > How did you generated this list? By manualy working through the list > generated by Vincent's smatch script or by modifying the script > directly? By manually working through the list, yes. -- Dimi.
Re: Pager Control: Rewritten
On Wed, Sep 15, 2004 at 07:54:44PM +0100, Robert Shearman wrote: > Hi, > > This is a large patch that rewrites a lot of the layout and button state > code in the pager control. Cool stuff. While this is still fresh in your mind, an audit against comctrl v6.0 would be good too... :) -- Dimi.
Re: Other W->A crosscalls
> Once I got rid of the duplicate calls I ended up with 130. What do you mean duplicate calls? Can you give a few examples of entries that you eliminated? -- Dimi.
Re: MSCMS: new dll
On Sun, Sep 19, 2004 at 09:29:39AM +0200, Hans Leidekker wrote: > On Sunday 19 September 2004 06:06, Dmitry Timoshkov wrote: > > Yes, I tried that option but it has even bigger problems. First, the header > doesn't have such a define! It defaults to building on non-windows platforms > and requires you to edit the file if you want a Windows build. > > Furthermore, when you do so it immediately includes windows.h, which is not > allowed within Wine. It's probably best to also try to submit a patch to the Little CMS folks so we can have a better solution in the future. -- Dimi.
Re: RFC: more Windows-NT like user directories?
On Mon, Sep 20, 2004 at 12:32:19AM -0700, Juan Lang wrote: > Folks, I'm still working on the shell path functions, > and I was thinking of changing the directory layout > for the shell directories (desktop, start menu, my > documents and whatnot) from the Windows 95-ish way to > the NT-ish way. That is, rather than being children > of c:\windows, they'd generally be children of > c:\documents and settings\. > > Any complaints? Hmm, shouldn't they be children of /home/ instead? -- Dimi.
Re: fonts: 20 ppem Wine Sans Serif
On Mon, Sep 20, 2004 at 11:51:24AM +0100, Huw D M Davies wrote: > Huw Davies <[EMAIL PROTECTED]> > Add a 20 ppem strike with cp1252 coverage to Wine Sans Serif. > Add U+201a to all strikes. Huw, What's the current status for fonts. I think they deserve a section under the UI Status: http://www.winehq.org/site/status_ui What do we have currently, in what state, what's left to do? -- Dimi.
Re: MSCMS: new dll
On Mon, Sep 20, 2004 at 09:44:51AM +0100, Mike Hearn wrote: > If it weren't for Alexandres dislike of binaries in CVS I'd have asked > for it to be put in there already seeing as the number of people who > have it installed is roughly zero. Currently we just say "download it > from the website" but unfortunately it seems most packagers are not > aware of its presence and do not include it. Ditto for the other > binaries Wine can use but aren't included in the source tree > (stdole32.tlb, fonts, etc) We should have a binary package on our SF site. What do we need in there? I would guess: - Mozilla Active X - fonts What else? -- Dimi.
Re: MSCMS: new dll
On Mon, Sep 20, 2004 at 03:53:27PM +0100, Mike Hearn wrote: > In theory then binary packagers would include them in their packages. In > practice quite a lot of users either install Wine from the source, or > use packages built by people who don't track Wine development (*cough* > gentoo *cough*) so this wouldn't solve the problem for a lot of people. A 'lot' is a bit of an exageration. It seems our binary packages are quite popular, please check the download stats (apprently they have been fixed as of late on SF :)). So getting our packagers to include them would be a great step forward. Also, providing a separate package for the folks that insist to build from source (under Support Files), would solve the problem for most of the other users. > >What do we need in there? I would guess: > > - Mozilla Active X > > - fonts > > A stdole32.tlb, the program Huw posted can be used to generate it (on > Windows) and it only has to be done once. Of course hopefully at some > point that will be moving into the build system. Until it does, we can > stick it in there. Cool, all of this should work just fine. Now we need to get someone to maintain this package... -- Dimi.
Re: Contributing to WINE
Ronald, It's good to hear from you guys. Regarding your contribution to Wine, we conduct our business in public, on this list, like most Open Source projects. It's best to post any issues on [EMAIL PROTECTED], and patches that you'd like to see in the official tree to [EMAIL PROTECTED] Feel free to ask questions about the process of getting your contributions into the tree. We'll be glad to answer. One more thing: it's best if you can post plain text messages to the mailing list. Not HTML, or any other strange formats. Your message for example was in a weird format that's not supported by my mail program, and it caused me no end of grief. Regards, Dimi.
Re: [4/5] GetWindowLongPtr: Windows
On Thu, Sep 23, 2004 at 01:37:32PM +0100, Robert Shearman wrote: > I did replace some GetWindowLongA calls with GetWindowLongPtrW, but > there is really no difference between the two A and W versions in terms > of performance anyway. Yes, but we should use the W version in preference to the A one as a matter of principle. This way, a simple syntactic check can tell us that we don't have W->A transitions. Otherwise, we have to do semantic checks all the time, and that's just not fun :) -- Dimi.
Re: Fix for bug 824 - proper handling of REG_MULTI_SZ
> * - the modification time optionally follows the key name > - * - REG_EXPAND_SZ and REG_MULTI_SZ are saved as strings instead of hex > + * - REG_EXPAND_SZ are saved as strings instead of hex > + * - REG_MULTI_SZ are saved hex (as of 10/10/04 -- see Bug 824) > */ Well, I don't know if the fix is correct, but if it is, just remove the comment instead of saying it's fixed, otherwise we risk cluttering the real issues to the point where they are useless. -- Dimi.
Re: nonclient.c and sysmetrics.c
On Tue, Oct 12, 2004 at 09:12:09AM -0700, William Poetra Yoga Hadisoesen wrote: > > Should I post those two files here (the diffs)? Or does anyone have a comment? If you have made a change that fixes the problem, please go ahead and post the diffs here, by all means. -- Dimi.
Re: [WineHQ] s/Forums/Mailing Lists/
On Tue, Oct 12, 2004 at 04:18:14PM -0500, Jeremy Newman wrote: > I committed this, but when you go to the page it calls itself Forums > still. My instinct was to s/Forums/Mailing Lists/g on forums.template. > But I held off to see if anyone had a better idea on how to layout this > page. As it stands right now, it does not make sense. I think "Forums" is the right term for what is on that page. It's just that in 99.99% of cases, people simply look for Mailing Lists, and so havin a Mailing Lists link is more useful most of the time. I think we can live with this small inconsistency. The cure seems to be worse than the dissease... -- Dimi.
Re: nonclient.c and sysmetrics.c
On Wed, Oct 13, 2004 at 09:57:49AM -0700, William Poetra Yoga Hadisoesen wrote: > And, I forgot to attach the diff. It's attached now. The patch is rather large. Please try to keep a bug/fix per patch (keeping in mind that each patch should be sandalone, that is, after applying it, the tree should build and work just fine). Also, please remove the "FIXED" comments, they clutter the code. FIXME comments are different, they serve as a reminder of what need to be done, we can't have reminders of all things we did well :) -- Dimi.
Re: -fPIC on link line in winegcc for HPUX
On Tue, Oct 12, 2004 at 10:42:37AM -0400, Warren_Baird/[EMAIL PROTECTED] wrote: > The question: is this going to be harmful on other platforms? I'm not > sure whether I should protect it with ifdefs, or just leave it as is. I think it should be fine: the gcc driver should be able to filter it out if it's not relevant. -- Dimi.
RFH: winuser.h
Can someone please help me with the value of LBS_COMBOBOX? TIA, Dimi.
Re: Rename Wine User Guide to Wine User's Guide?
On Thu, Oct 14, 2004 at 04:22:10PM +0100, Peter Riocreux wrote: > I have always operated on the principle that if two people can argue > about it then it should be written a different way, so how about one of: > > Guide for Wine Users > Guide to Using Wine > Wine: a guide for Users > Using Wine Hmmm, they sound/look awkward. We have a Developer's Guide, let's just be consistent. And I think this is typical naming anyway, so let's just call it User's Guide and be done with it. -- Dimi.
Re: [PATCH] DrawDibDraw flag handling
On Thu, Oct 14, 2004 at 05:21:41PM +0200, Andreas Mohr wrote: > Hi, > > On Thu, Oct 14, 2004 at 03:53:41PM +0100, Peter Riocreux wrote: > > if (!(wFlags & DDF_DONTDRAW) && whdd->hpal) > > -SelectPalette(hdc, whdd->hpal, FALSE); > > + if ((wFlags & DDF_BACKGROUNDPAL) && ! (wFlags & DDF_SAME_HDC)) > > + SelectPalette(hdc, whdd->hpal, TRUE); > > + else > > + SelectPalette(hdc, whdd->hpal, FALSE); > This is rather non-obvious if handling, I'm surprised that the compiler > doesn't warn about it, or does it? > > Could you add proper braces there? Better yet, what about we just do: + SelectPalette(hdc, whdd->hpal, (wFlags & DDF_BACKGROUNDPAL) && ! (wFlags & DDF_SAME_HDC)); -- Dimi.
Re: Rename Wine User Guide to Wine User's Guide?
On Thu, Oct 14, 2004 at 09:18:23AM -0700, Kenneth Porter wrote: > --On Thursday, October 14, 2004 11:00 AM -0400 Kuba Ober > <[EMAIL PROTECTED]> wrote: > > >Actually, the apostrophe looks quite right there. Whose guide is it? The > >user's. Then one has user's guide, not user guide. > > Would it not be "Users' Guide"? A guide for *all* users? (Plural) No, we have Developer's Guide. Because we're addressing the book to *the* person reading it. In fact, you seem to have found the answer: > OTOH, I just plugged "users guide" into Amazon and the results on the first > page are all "User's Guide" (singular). :) So let's stick to User's Guide. It's the norm. -- Dimi.
Re: -fPIC on link line in winegcc for HPUX
On Thu, Oct 14, 2004 at 09:03:53PM -0700, Alexandre Julliard wrote: > Actually it could be argued that winegcc should add -fPIC itself if > it's needed for linking, users shouldn't have to worry about that. Absolutely, the user shouldn't need to provide anything. It would be silly to have some internal winegcc computation/compilation fail because the user did not provide some flags. In fact, I also had in mind the same thing, but I forgot the patch did not do that. As I was saying, I think we can just always provide it during link, gcc should be able to deal with it on all platforms. -- Dimi.
Re: [janitor] tools -Wwrite-strings cleanup
On Fri, Oct 15, 2004 at 06:43:31PM +0200, Daniel Marmier wrote: > If such a risk exists, the latter change implies that we will silently free > the copy of the data instead of trying to free the static data. This could > lead to consider a simple test passed, while causing random results in > more complex code that still references the data ... No, nobody will access the data, just the copy is made public. -- Dimi.
Re: Progress Bar: Fix Class Style & Repainting (resend2)
On Tue, Sep 28, 2004 at 12:12:09PM -0700, Alexandre Julliard wrote: > Robert Shearman <[EMAIL PROTECTED]> writes: > > > Changelog: > > - Fix class style to include the hbrBackground member. > > - Fix repainting issues introduced by this change. > > - Add WM_ERASEBKGND handler and remove background drawing code from > > the WM_PAINT handler. > > Isn't that going to cause a lot of flicker? This was the reason for > the existing code, because otherwise it looks really bad with apps > that update the progress bar a lot. Indeed, IIRC I've tried to have as optimum background drawing code as possible (in terms of overwriting areas, etc), as flicker in the progress bar would look rather ugly. We have to be careful with these sort of changes, in that there are some controls that work real hard to avoid flicker as much as possible. Yes, the code is bigger, more complicated, and maybe sometimes not 100% the way MS does it. But if it doesn't cause any problems, having a good looking control is important IMO. -- Dimi.
Re: Tab control update
On Fri, Oct 01, 2004 at 07:58:23AM -0700, Jon Griffiths wrote: > Hi, > > A fairly large update to the tab control. This makes it work as per > native in my app. Nice. While you're at it (and have it fresh in your mind), can you please also provide an audit (and a list of TODOs) as per comctl 6.0? We're getting closer to having a full audit of the controls, and this one has not been audited: http://winehq.org/site/status_ui TIA, Dimi.
Re: Audit the buttons code
On Mon, Oct 04, 2004 at 10:39:24PM +0900, Dmitry Timoshkov wrote: > I can't believe that a simple win32 program linked against user32 only > under XP starts to depend on comctl32 as well. user32 in XP can't depend > on comctl32 too. "Button", "listbox", "combobox" and others were always > a part of user32, moving them into comctl32 would break a lot of apps. > Perhaps comctl32 simply subclasses standard user32 controls and adds > "skinning" for them? I think they just made a copy into comctl32, but this is more of a gut feel than anything else :) Anyway, MS now documents the standard controls together with the common ones (which makes sense, logically they belong together, they are all controls after all), so my comment is OK for its purpose (which is to correctly identify the piece of documentation that the audit was against). -- Dimi.
Re: Audit the buttons code
On Mon, Oct 04, 2004 at 10:58:14PM +0900, Dmitry Timoshkov wrote: > No, your comment is not OK. Actually, it is. Check out the URL for the button docs: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/buttons/buttons.asp See? Button is under commctls. > I bet it's still in user32. You're on. And I win: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/userex/comctrl6.asp Again, now MS documents all controls together, please check out the on line MSDN. -- Dimi.
Re: Audit the buttons code
On Tue, Oct 05, 2004 at 09:19:10AM +0900, Dmitry Timoshkov wrote: > "Dimitrie O. Paun" <[EMAIL PROTECTED]> wrote: > > > Again, now MS documents all controls together, please check out the > > on line MSDN. > > How could that matter where MS does document things? That fact changes > nothing in the actual control functionality or DLL ownership. Oh come on, I've explained that already: the comment's purpose is to identify the *documentation* that the code has been audited against. Which is the commctl 6.0 documentation. This is where MS says the standard controls reside in XP, what's the problem? -- Dimi.
Re: Audit the buttons code
On Tue, Oct 05, 2004 at 08:18:50AM +0200, Shachar Shemesh wrote: > Such comments do suffer from another problem. They tend to fall out of > date. For that reason alone I'm not sure this comment is a good idea. > Otherwise, we get a future commit that changes something, but neglects > to update the comment accordingly, and the comment turns useless or even > dangerous. Maybe if we change that to contain the date or the CVS > version number of the file that was audited This is not a problem for these comments because: -- each control is implemented in one, and only one file -- each control has it's own independent audit -- the comment is at the top of the file, where it's most visible -- from the previous 3 points, it's very difficult to work on any control without stumbling upon it. -- it includes the exact version of the documentation, so when new documentation is released, we can compute the delta -- it includes the exact date when the audit took place, so we can compute deltas on the control side -- they are not open ended. That is, they list all the missing features, and such, if people forget to update them, 99% of the time this simply means they forgot to *delete* something. This is much less of a problem then not adding. It can easily get fixed when someone does a new audit, or wants to reimplement that feature. -- we had them for more then 2 years now, and there wasn't a single instance when people forgot to update them. Which means that the theory detailed this far actually works in practice. -- I've been closely watching patches againt controls myself (along with a few other people, it seems), so we have a pretty good safety net. -- Dimi.
Re: Audit the buttons code
On Tue, Oct 05, 2004 at 07:32:18PM +0900, Dmitry Timoshkov wrote: > I didn't oppose a comment itself, I don't like that it confuses people > by mentioning comctl32. That's simply not true. Dmitry, please stop repeating misinformation. Go read the MSDN, I've provided you with the relevant URLs. Here is the situation: -- in XP, there are *two* implementations of the standard controls: the old one in user32, and a strict superset, in comctl32. Applications can ask for the one in comctl32 by specifying so in their manifest file. This is done so that applications continue to run on older versions of Windows. -- since we don't have the same constrains as MS, and since we can't afford to maintain two versions of the standard controls, we are just going to extend the ones from user32 to the full capability of the ones in comctl32 ver. 6. As such, it make sense to audit them against the comctl32 ver. 6 documentation. In other words, the comment is right on the money. -- Dimi.
Re: Audit the buttons code
On Tue, Oct 05, 2004 at 02:59:35PM +0100, Robert Shearman wrote: > How do you plan on using image lists from user32? How will you make sure > that the version 6 behaviour doesn't break older programs? It's these > questions that made Microsoft move the controls to comctl32. Will we get > ourselves into a bigger mess by not having two separate implementations? I don't dispute that our current approach is not perfect. You are right, there may be some problems with it, and in the long term, we may have to duplicate them. However, doing so mow would imply a lot of work, and as you can see, we're way short of manpower. From what I've seen, we can safely implement most of the XP functionality into the user32 without risking of breaking stuff. That is to say, I don't see right now a big need to dupicate the controls. Let's cross that bridge when we get there. -- Dimi.
Re: kind of newbie question :)
On Wed, Oct 06, 2004 at 07:40:49AM +, Carlo Bono wrote: > configure script! wine version is 14/9/2004 and was compiled from > source on slackware 10.0 running on a via C3 (intel x86 100% > compatibile). is there any suggestion or workaround, or maybe this is > normal, or maybe then i'm forgetti something really stupid? (maybe not > so stupid, don't think it makes a difference :D) Yes, winemaker no longer generates a configure script. It just generates a Makefile, which you may need to hand edit a bit. Then just type 'make' :) -- Dimi.
Re: Problem using winelib
On Mon, Oct 18, 2004 at 03:25:12AM -0400, Ross Quinlan wrote: > This generates one new file, "Makefile" (no Makefile.in, configure) > so I can't run ./configure --with-wine etc. Yeap, that's expected. Docu needs updating. > If I try a simple make, here's the result: > > E> make all > winebuild -o winemine2.exe.dbg.c --debug -C. dialog.c main.c > winegcc -c -mno-cygwin -I. -o winemine2.exe.dbg.o winemine2.exe.dbg.c > winegcc -c -mno-cygwin -I. -o dialog.o dialog.c > winegcc -c -mno-cygwin -I. -o main.o main.c > wrc -I. -foDe.res De.rc > De.rc:22:21: Error: parse error > make: *** [De.res] Error 1 You need to hand-edit a bit the generated Makefile. In this case, you have to remove all the language ,rc files (Xx.rc) from there, since these are included by the main .rc file. -- Dimi.
Re: wine/dlls/ntdll time.c
On Mon, Oct 18, 2004 at 04:19:29PM -0500, Alexandre Julliard wrote: > Log message: > Rein Klazes <[EMAIL PROTECTED]> > In RtlQueryTimezoneInformation use information from the registry if it > is available. > > Patch: http://cvs.winehq.org/patch.py?id=14188 Hmm, shouldn't we synch up with the Unix env instead? I assume this info is available in the Unix env... This would be preferable even in the case of a shared Windows install, me thinks. -- Dimi.
Re: Cleanup config
On Thu, Oct 21, 2004 at 03:37:37PM -0700, Alexandre Julliard wrote: > This is OK except for the windows dir, that one is still being used by > the registry code. Heh, that's not nice, now we define it in two places. I can't quite find where it's been used, do you remember the filename? -- Dimi.
Re: Fix for bug 824 - proper handling of REG_MULTI_SZ
On Mon, Oct 18, 2004 at 05:29:29PM -0700, Alexandre Julliard wrote: > Do you actually have an app that depends on this? I agree that in > theory we should preserve the data exactly, but this means giving up > on an easily editable registry format, so it should be done only if > something really needs it. What about supporting regular C escaping rules? It would be pretty consistent with the file format, and frankly I'd expect that to be supported (speaking as a Unix user). As for processing overhead, I'd be surprised if it shows on the radar. -- Dimi.
Re: Fix for bug 824 - proper handling of REG_MULTI_SZ
On Fri, Oct 22, 2004 at 02:59:45PM -0700, Alexandre Julliard wrote: > > It's pretty much supported already. This doesn't really solve the > problem of getting rid of the terminating null (except if you want to > require always specifying the null explicitly, but that's not > backwards compatible). I must be missing something, but I thought regular strings can not contain embedded nulls, so we can have a simple rule: don't store terminating nulls for simple strings, but store them for multi-strings. Aha -- you mean that if we follow this rule, all is good, but we will not be backwards compatible because currently multi-strings don't have the embedded nulls, right? In that case, I guess we already have a versioning mechanism for the registry files, so we'll just have to go to the next version, and convert the old files to the new format. -- Dimi.
Re: The wine user guide: an idea
On Sat, Oct 23, 2004 at 09:00:40PM -0700, Scott Ritchie wrote: > Thanks for you comment. I've taken up the task of rewriting alot of the > User Guide at the moment, and revising the Using Wine section may be the > most important next step after the rewrite of the Intro. Please coordinate with Brian Vincent ([EMAIL PROTECTED]), he already did a lot of work on the User's Guide, and he's waiting for some changes in the codebase to merge. It would be a pitty if work would be needlessly duplicated. IIRC, the mostly work on redoing the Configuring Wine section. -- Dimi.
Re: Functions For Helping FillRect
On Sun, Oct 24, 2004 at 02:20:53AM -0700, William Poetra Yoga H wrote: > FillRect is used in many places for drawing the GUI. But one thing I think many > developers miss is that it doesn't fill the right and bottom borders of the > rectangle, very much like LineTo doesn't draw the destination point (as per the > MSDN docs). This is OK, the rect functions are consistent with the rest of the GUI functions (I would also add that not including the right and bottom borders is a good thing, but let's not debate that). Anyway, even if the standard APIs were awkward, in Wine we insist on using the standard stuff as much as possible, it's the best we can do long term. For many reasons. So no, adding such helper functions will not fly. -- Dimi.
Re: wine/dlls/user button.c
On Mon, Oct 25, 2004 at 05:38:01PM +0900, Mike McCormack wrote: > > Hi Dimi, > > The following hunk of the patch below breaks the IE install. You should > be able to press Alt-A to accept the license in the first dialog, but > with this hunk applied it no longer works. Thank you, I'll submit a patch later on tonight. It seems the MSDN is wrong (oh, the horror!), so I'd guess a test would be nice as well. -- Dimi.
