- Wine-Devel - list.winehq.org

Re: wine/dlls/user/dde server.c misc.c ddeml16.c d ...
by Pouech Eric DMI AEI CAEN Feb. 15, 2005

Feb. 15, 2005

are you sure of this? according to MSDN, the iCodepage in convcontext is unicode or ansi depending on the A/W version called for DDE initialize (I never tested it though). A+ > Message du 14/02/05 13:11 > De : "Alexandre Julliard" > A : wine-cvs(a)winehq.org > Copie à : > Objet : wine/dlls/user/dde server.c misc.c ddeml16.c d ... > > ChangeSet ID: 16099 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/02/14 05:53:15 > > Modified files: > dlls/user/dde : server.c misc.c ddeml16.c dde_private.h > client.c > > Log message: > Dmitry Timoshkov > Make DDE implementation always work internally in Unicode. > > Patch: http://cvs.winehq.org/patch.py?id=16099 > > Old revision New revision Changes Path > 1.18 1.19 +42 -72 wine/dlls/user/dde/server.c > 1.25 1.26 +37 -34 wine/dlls/user/dde/misc.c > 1.12 1.13 +1 -2 wine/dlls/user/dde/ddeml16.c > 1.9 1.10 +7 -10 wine/dlls/user/dde/dde_private.h > 1.21 1.22 +32 -60 wine/dlls/user/dde/client.c > > > >

2 1

printf and the long long case
by Jesse Allen Feb. 15, 2005

Feb. 15, 2005

Since Mike McCormack's printf patch has our own vsnprintf parsing the format strings, but yet we still push integers to libc's printf, I figured that we can handle the 'I' (eye) size type now. I hacked together a patch that handles it and fixes 3 test failures with long long. It fixes it by converting I (eye) and I32 to long, and I64 to long long. 'll' (ell ell) is translated to be long only. Mike, I have a question. You have flags.IntegerDouble++; on the case of long long -- what were you planning on doing with it? Other than that it is unused. I decided to use it as the flag for long long. Patch below. Jesse --- dlls/msvcrt/wcs.c-original 2005-02-14 16:14:01.000000000 -0700 +++ dlls/msvcrt/wcs.c 2005-02-14 17:48:39.000000000 -0700 @@ -378,6 +378,16 @@ sprintf(p, ".%d", flags->Precision); p += strlen(p); } + if( flags->IntegerLength ) + { + sprintf(p, "%c", flags->IntegerLength); + p += strlen(p); + } + if( flags->IntegerDouble ) + { + sprintf(p, "l"); + p += strlen(p); + } *p++ = flags->Format; *p++ = 0; } @@ -474,12 +484,28 @@ { if( *p == 'h' || *p == 'l' || *p == 'L' ) { - if( flags.IntegerLength == *p ) /* FIXME: this is wrong */ - flags.IntegerDouble++; - else + if( flags.IntegerLength != *p ) flags.IntegerLength = *p; p++; } + else if( *p == 'I' ) + { + if ( *(p+1) == '3' && *(p+2) == '2' ) + { + /* Unchecked on 64-bit systems */ + flags.IntegerLength = 'l'; + p += 3; + } else if ( *(p+1) == '6' && *(p+2) == '4' ) { + flags.IntegerLength = 'l'; + flags.IntegerDouble++; /* Why ++? */ + p += 3; + } else { + /* FIXME: 'I' modifier needs to produce + 64-bit number output on 64-bit systems! */ + flags.IntegerLength = 'l'; + p++; + } + } else if( *p == 'w' ) flags.WideString = *p++; else @@ -567,6 +593,8 @@ if( pf_is_double_format( flags.Format ) ) sprintf( number, fmt, va_arg(valist, double) ); + else if ( flags.IntegerDouble ) + sprintf( number, fmt, va_arg(valist, long long) ); else sprintf( number, fmt, va_arg(valist, int) );

2 1

Re: Resend: [Bug 2631] Trap in RegisterClassExA
by Dmitry Timoshkov Feb. 15, 2005

Feb. 15, 2005

"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> wrote: > Make RegisterClassExA check the reserved bytes is a valid value > Tests to confirm this behaviour > + /* Bug 2631 - Supplying an invalid number of bytes fails */ > + cls.cbClsExtra = 0; > + cls.cbWndExtra = -1; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of WndExtra bytes\n"); > + > + cls.cbClsExtra = -1; > + cls.cbWndExtra = 0; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of ClsExtra bytes\n"); > + > + cls.cbClsExtra = -1; > + cls.cbWndExtra = -1; > + ok( ((RegisterClassA( &cls ) == 0) && (GetLastError() == ERROR_INVALID_PARAMETER)), > + "Failed with invalid number of ClsExtra and cbWndExtra bytes\n"); You need to set last error to some bogus value (0xdeadbeef usually works) before every API call to ensure that it's really that API call who sets the error. -- Dmitry.

1 0

[ddraw/dsurface/main.c] LPRECT parameters for Main_DirectDrawSurface_Lock
by Andreas Eckstein Feb. 15, 2005

Feb. 15, 2005

Good morning, wine devs! When playing Icewind Dale II (using wine-20050111), the game sometimes crashed with these messages: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-0x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! or, on another occasion: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-2x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! As you notice, the game tries to lock a surface with width and/or height equal to zero. Frankly I have no idea what the expected behavior is in this case, however playing the critical passages on Windows worked without crash. A quick patch to let Main_DirectDrawSurface_Lock not choke on zero-width or -height LPRECTs solved the problem with wine. Since I don't plan to dig into wine hacking any time soon, could someone merge it into cvs for me (if the new behavior of the function is acceptable, that is)? Thanks in advance! Andreas Eckstein --- The patch: --- dlls/ddraw/dsurface/main.c 2005-01-09 18:35:44.000000000 +0100 +++ dlls/ddraw/dsurface/main.c 2005-02-14 21:03:36.511738080 +0100 @@ -1111,8 +1111,8 @@ (prect->left < 0) || (prect->bottom < 0) || (prect->right < 0) || - (prect->left >= prect->right) || - (prect->top >= prect->bottom) || + (prect->left > prect->right) || + (prect->top > prect->bottom) || (prect->left >= This->surface_desc.dwWidth) || (prect->right > This->surface_desc.dwWidth) || (prect->top >= This->surface_desc.dwHeight) ||

1 0

Re: Fix documentation build
by Alexandre Julliard Feb. 15, 2005

Feb. 15, 2005

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > Those errors are particularly bad as (in the past) it prevented the Wine > documentation on winehq to be built for a release. > > Alexandre, do you build the docs the same way you compile C files after > applying a patch, or is it that your setup allows missing tags? Yes, I always compile the docs, and they build fine on my setup. If you know how to change my config to make it less forgiving I'd be happy to do that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winecfg: various drive detection enhancements
by Paul van Schayck Feb. 14, 2005

Feb. 14, 2005

On Mon, 14 Feb 2005 16:10:55 +0100, Michael Jung <mjung(a)iss.tu-darmstadt.de> wrote: > Changelog: > Include config.h to reenable reading /etc/fstab on platforms that support it. > Implemented a black list of mount directories, which should not be mapped. > Ensure that the user's home directory is mapped. Hehe I was just about to send a patch doing almost exactly the same things. Including the fix you put in to properply add a drive letter to the working_mask. And are we ready to let wineprefixcreate use winecfg? Or do we want more testing of the autodetect code? Paul

2 1

Re: [OLE #69] Use RPC Runtime
by Mike Hearn Feb. 14, 2005

Feb. 14, 2005

Robert Shearman wrote: > Hi, > > This patch is significant as it changes the RPC backend of our COM > implementation from using named pipes to using any transport implemented > by the RPC runtime. As a matter of coincidence, this patch is numbered > 69, which is my favourite number, and this patch is my favourite patch. Haha, 69 DUDE!!!! > Not only this, but it should also solve some real problems with having > way too many threads (one and only one per apartment) and some complex > deadlocking situations caused by this. It also significiantly reduces > the amount of code in the file and reduces most of it to simple wrappers > around the RPC runtime functions. We'll still need to run a message loop in the RPC runtime right? Until we do that I think InstallShield won't work correctly. So that's the keystone - after that it should all fall into place. thanks -mike

2 1

Real-world appdb
by Holly Bostick Feb. 14, 2005

Feb. 14, 2005

If I may interrupt and split off the various theoretical discussions about recoding the appdb, I'd like to report my experiences actually using the appdb as it is today. I wanted to use the appdb in order to (attempt to) solve some installation problems with several applications (two games, two applications). My impressions as a user predisposed to feeling that the appdb is an extremely useful capability, currently (severely) underutilized, were as follows: I started with the last program I had tried to install, the expansion pack for Icewind Dale, called "Heart of Winter". It's been some time since I've even accessed the appdb, much less tried to use it to solve a problem with a listed program, so I had a fairly fresh eye for how it looks, how accessible the information I needed was, and how noticeable useful information that I didn't know I needed was (or was not). I had forgotten the precise URL directly to the appdb, so I had to start from the main site, which brings me to my first useability complaint: too long a trail to get to the app I'm looking for. I had to go through 4 links just to get to the main application page. First, the sidebar link from the main site to the appdb front page. This front page is useless to me (and imo, fairly useless overall), since the majority of the "Gold" and "Silver' apps so prominently listed I already do/would use the native alternatives for in the case of winzip, p7zip, Paint (Paint??! it's barely useful under Windows!), SimCity, IE, Excel, ACDSee, Money, Frontpage/Dreamweaver, and Ant Movie Catalog. Others I do not use at all, either because I have no use for them, in the case of Powerpoint, Access and Visio, or because they are "special interest programs" as in the case of Warcraft and Age of Empires (I play games, but not those). Having a lovely page with big 'ol screenshots is very nice and all, but given that the chance of a random individual user coming to use the appdb actually needs to know about those particular programs (as opposed to one or more of the thousands of others they may be attempting to run) is relatively small, I would think that the "Top 25" links would be more useful there (and less space-consuming, since I have to scroll the current page to see if there might be a useful link at the bottom of it), along with another, more prominent "Browse Categories" link than this page as it stands. So, after following the first link to a page I cannot use, I must then link to "Browse apps" to get a category listing (Games), and then to the sub-category page (if present, which in this case it was; Role-Playing), and then to the application itself to see the results for Icewind Dale ( http://appdb.winehq.org/appview.php?appId=141 ). I am now quite tired, having trudged through all these links when I was already tired; after all, the only reason I'm at the appdb at all is because I have tried to install an application and failed, which is stressful-- especially since I, like many users, have retried the process several times before looking to the appdb for help. And yes, I could have used the search box, but that would be *typing* :-) when I was mousing. Yes, it's my worst leftover habit from my years of Windows use; I tend to mouse and not type. But I'm far from alone in this, so it's a fair comment. My first impressions on arrival (since I was looking at the page with "fresh eyes"): 1.1) The current design of the individual application page is readable and easy on the eyes. 1.2) The "Description" area is well-placed and sized, but the information contained therein is generally pointless and should be a "Summary" instead. Most of the descriptions I read told me what the application is and does as if I was making a buying decision. However, I believe that in most cases (certainly my case), users are already familiar with the capabilities of the program itself (since they already have it), thus telling users what a program they already have actually does is a waste of space. What I would have found more useful on what is essentially the "overview" page is some indication as to whether the problems with the application that I am consulting the app database about are known, and whether they are solveable (so I'd know whether to continue with the appdb or if I need to immediately begin searching elsewhere for solutions). A nice bulletted list (or a couple of them) would do just fine: "Installs: Yes, no, with modification (the last being a link to the comment explaining the needed modifications); "Runs: Yes, no, with modifications (as above); "Known Problems: Bulleted list (with links), none". If such a summary was provided on the main application page, I would not mind so much having to go to yet another page (fifth link, now) in order to find specific details on possible issues with the particular *version* of the program I'm trying to install/run. 1.3) The screenshot on the application overview page is some reward, however; at least I have proof that the application can be made to work, even if I cannot get it to, and its placement is eye-catching so that I am sure to be a bit heartened by seeing it. 1.4) The big "Become a super maintainer" link/button is nice, and encourages me to become one (via guilt; because I'm attempting to look up programs I very commonly install under Wine whenever I install a new distribution, I feel I might be familiar enough with the issues surrounding them that I should contribute something back) but I do not become a maintainer because: 1.4a) I couldn't log in via that login button anyway; I had to use the side menu link and then go back to the page I was on. Fortunately the "send a new password" link on the login page that the "Log in to become a maintainer" button takes you to didn't seem to work either, so I was able to look up my original password in a password maintenance progam (PCMagazine's 6-year-old Password Prompter) that I run via Wine (which is why I hadn't so much bothered to stop what I was doing and look it up in the first place) and use my real login in the side menu link instead; 1.4b) more importantly, I do not know what the responsibilities of a "maintainer" are-- much less a "super maintainer". There is no link on that page as to what this means (not even a little question mark with a tooltip popup), and no indication as to whether actually clicking the button will go to an "intermediate" page which explains what it is, or just sets your login as the maintainer for this app (since I have specifically had to log in in order to enable this button in the first place, it's not an unreasonable assumption that that might occur). Since I didn't know what would happen, and didn't know if I wanted to or was capable of fulfilling what might be a committment (how much do I need to know about the program? How much do I need to know about programming? Do I need to have a version of Windows available to know how the program runs there, so I can compare it to how it runs under Wine?), I did not click the button, so the apps will remain unmaintained for the time being (or they won't be maintained by me, anyway). Weirdly enough, going to the version page for the application offers me the opportunity to be a "regular" maintainer-- so, what, that means I would be a maintainer for that specific version, whereas "super maintainer" means that I'd be maintainer for all versions, like some kind of 'team leader'? I'm not sure that either makes sense to me as a user, nor that it is a logical setup generally, at least for games, which usually should not be run at lower versions if a patch (which increases the version while repairing errors) is available. So there is in some ways no reason to maintain version "1.0" when no one should actually be *running* version 1.0 other than immediately after install, and then only for the 5 seconds before the user has installed one or more patches (after which they will be running a higher version). There are certainly some games that would require that several patch levels/versions be maintained; I know of at least one (Settlers 3) that only works (for my boyfriend under Windows 2000) with a lower patch than the "latest" patch, and SiN (a game which I run under Wine despite a native version being available, because I already have two copies of the Windows version) is also very touchy about patches, so it certainly can happen that multiple patch levels of a game might need to be separately maintained. I would think that the game's maintainer would know if his/her particular charge needed special circumstances though, and since this is not a common situation (you usually want all users to be running the latest patch, and this is usually a good idea), having it as a general organizational strategy, at least in the games category, seems to be unnecessary work. 1.5) Comments are not being counted properly on the main overview page; Icewind Dale actually has two comments on the version page (version 1.0, which again is not the "real" version as there are two expansion packs, both of which contain patches that increase the version number, and these patches are also available separately, so no one should be using "vanilla" 1.0), but the main page says that the number of comments are 0. 1.6) I hope that one of the responsibilities of the maintainer or super maintainer is to control comments in some way. I completely understand that users of the appdb who are having problems with any given app *have no other place to state their issue with the specific program in an organized and somewhat reliably maintained fashion* (as wine has no forums, and certainly no forums linked to the specific app). However, comments like "hmm... when exporting registry, the reg file is all messed up. It has weird symbols in it. Any idea what I'm doing wrong?" have no place in the appdb. On the other hand, if I was the maintainer, I would want to know that a user of the app that I maintained was evidencing this problem (assuming that the issue commented on is specific to the app, which in this case it probably is not), and help the user solve it so that I could update the procedure to install and run the app. I'd really like to see forums or at least some kind of PM system so that the users of the applications could reliably communicate with the maintainer for the benefit of both parties. I see that Planescape: Torment (another game I have running under Wine, without issue; http://appdb.winehq.org/appview.php?versionId=437 ) has a maintainer, but his name is not a mailto: link, so I can't contact him (afaik) to advise him of any new information I may have discovered short of posting a comment myself... which is fine if it's new information (assuming that my comment fits into the organizational structure of the db so that following users can find it easily), but if it's an app-specific issue that I want his help with, it's a waste of space (insofar as such a comment provides no real information to other users searching the database except a confirmation of the issue), and the appdb as it is gives no assurance that the maintainer will see the comment anyway. Comments should also require the specification of the Wine version, the distribution under which it is used, and the type of install (self-compiled from source, distribution repository package, or Wine distribution package; I have visions of a radio button) to be attached to the comment, as new users often don't know to include this information, but it's pretty hard to answer many questions without having this information (so one has to ask, which wastes time and space). A Wine FAQ at the forefront of the appdb, or even linked to each application's overview page might be nice, too, for more general issues like the above comment-- an explanation of basic procedures such as exporting/importing registry entries, what common errors mean, like the "Warning: The specified Windows directory L"C:\\Windows" is not accessible" error and what to do about it, why not to get all freaked out by seeing "fixme"s, and simple statements like the fact that some programs will run fine with wine /path/to/app.exe, but some will fail that way with very scary looking errors, but will run fine if one first cds to /path/to/ and then runs wine app.exe. This kind of thing is often something new Wine users don't know, but is a very simple way to eliminate possible vectors of error before going to any mailing list or forum with problems, and may eliminate the need for a user to ask for help at all (as the program works when started in the alternate manner). Somebody's going to say I should write a FAQ myself and submit it as a patch, aren't they? Yes, OK, but let me finish this mail first ;-) . 1.7) Descriptions are really not very useful, for several reasons. Still focusing on Icewind Dale (since that's the page I have open in the appdb atm), here's the Description for the version page: "Description CD Release. Runs from a modified Baulders Gate engine. Notes from that game would help here as well." But there's no link to said notes, nor are the relevant notes copied from that page and posted as an addendum, so even though this particular description does contain some useful information (for once), it's not even a lead, but only a suggestion of a lead. Big help. 1.8) (or, "On the road again") Off to the Baldur's Gate page, then... Back button to the subcategory (Games=>Role-Playing; thank heavens they're the same type), follow a new link to the Baldur's Gate page... I'm ranging far afield now, but in this case, that's OK. I have BG as well, but haven't installed it yet, so it's useful for me to look at the page anyway. Luckily. Because if I didn't have BG, I would now be traveling to the page of a completely different application in which I had no interest, with no assurance that what I find there will be of any use to me. In that case, I'd probaly be pretty bloody pissed off by now, given that I would have spent a fair amount of time trailing around the appdb without being so much as a single step closer to solving my actual problem with the original application, or even having it confirmed as a known problem, or receiving a clue that implied "user error", or anything whatsoever that would give me a troubleshooting or solution trail. http://appdb.winehq.org/appview.php?appId=157 if you'd like to come with me. 1.9) (or, "Helpful help?") Well, there are helpful notes there on the BG page, or rather, actual solutions to potential problems that I might have were I installing BG, which I remind you that I am not. Mind you, I, a simple user, don't know if the solutions posted for Baldur's Gate are problems that also exist under Icewind Dale -- well, actually, I personally do know, because I have run IWD and IWD2 under Wine in the past, and am currently running Planescape: Torment, (which btw runs great under 20050111 without any modification to Wine dlls, one appdb-documented change to the game's configuration file, and one small, optional [AppDefault] in Wine's config). All 5 of these games (IWD, IWD2, BG, BG2, and Planescape) are made by Black Isle, use more or less the same engine, and evidence similar problems to each other. But this does not mean that "your average user" would have any experience with multiple Black Isle games and thus know their technical similarities and differences. The solutions on the Baldur's Gate page are general enough to be worth trying if IWD did not run at all, or ran poorly. However, this is not my problem; IWD installs perfectly and seems to run quite well (except for one minor but annoying issue related to Managed or Desktop settings that I haven't yet idenitified how to fix, since the way I fixed the same issue for Planescape doesn't seem to work here). Thus, none of the listed issues for Baldur's Gate is related to my actual problem with Icewind Dale, the specific application I have trailed all over the appdb trying to fix-- and the foremost reason is that my problem is not with IWD itself, but with installing the the expansion pack, "Heart of Winter", and 1.10) *this application is not listed in the appdb*, either as a version of IWD (since installing the expansion does require IWD, and does patch the original to a higher version), or as a separate program. Also not listed are the Baldur's Gate expansion, "Tales of the Sword Coast", and the Baldur's Gate 2 expansion "Throne of Bhaal", so I hope I have no trouble installing those expansion packs when I get around to it. However, given that I am already unable to install the expansion pack for IWD, and since I know that IWD and Baldur's Gate are strongly related, I'm expecting the worst-- and since the appdb is unable to help me with IWD: Heart of Winter (nothing said about the official, free, downloadable final expansion, Trials of the Luremaster, which is also not in the database), if I hit trouble, I already know where I *won't* find any help. Fine, I'm stopped cold with this issue, let's stop quickly by the Icewind Dale 2 page ( http://appdb.winehq.org/appview.php?appId=1033 ) and see if there's help for me there; the issue being that it won't begin the install. InstallShield fails to extract/open with a regular Windows-type dialog saying either that some dll in the /tmp/{long CLSID-looking-string-of-numbers} folder can't be opened, or that IKernel.exe can't be run. Actually the same issue I'm having when trying to install IWD:HoW, which doesn't surprise me very much, as I would guess that the Installshield for IWD:HoW and IWD2 are more closely related to each other than the one for the original IWD. Since the issues seem similar, maybe there's a fix for both apps on the IWD2 page. 2.1) Only one version (the original version, although there is a 2.01 patch), but whatever; according to the description, I am supposed to be able to install this, as long as I have an insanely old version of Wine (the original description was penned by someone installing under 20020904!), which I don't. 2.2) Two comments listed on the overview page, only one comment in actuality. 2.3) I'll try the workaround listed in the description, but since the version of Wine used is so distant from what I actually have, and the error which the workaround is fixing may or may not be the same one I'm having (it's impossible to tell), and furthermore may not even be needed anymore given the improvements in Wine in the meantime, I don't have much hope that it will work. But it's the only lead I have, as far as the appdb is concerned. Given that my second-best source of information--Transgaming's games database and forums-- has been blown away and replaced with a new games database (for which little or no data for most individual games has yet been entered), I don't have many other options than the appdb, since sites like Frank's Corner only cover a very limited selection of apps/games, and the various IWD sites on the Web don't cover Linux). If the workaround doesn't work, I will probably dig up my backup of my last installed and updated Win98-- which I cleverly saved all the system files from before blowing it away, for just such an eventuality-- and "taint" my Wine installation by copying over the "real" InstallShield files to the fake windows Common Files. This will probably work-- it has in the past-- but I was really hoping to run 'pure' Wine this time around. It has so been improving by leaps and bounds lately. Let's see if things are any better in the Applications section. My issue here is that I need to burn some CloneCD images. K3b claims they are unuseable, and ccd2iso did not create recognizeable isos from them. It remains unclear whether this is because the images themselves are no good, or because there is a problem with ccd2iso, which several users claimed was the case on the project site's bug tracker ( http://sourceforge.net/tracker/?group_id=94638&atid=608541 ). So I want to install either CloneCD (preferred), or Nero (version 6 or above, which I *think* will also recognize the images, I have version 5.* as well, but I don't *think* it will solve my problem to install it, as I'm not sure when Nero's recognition of *.ccd images became reliable, but I believe it was with version 6, if in fact it is reliable at all), to see if the error is in the images themselves, or burn them if the problem is with K3b. I do not have any real interest in installing these programs on their own account, although if I kept one, I would keep CloneCD for the specific use of handling .ccd images, on the rare occasion that I need to deal with them. I would prefer not to install Nero at all, and certainly not to keep it, as it's too much overhead for the only use I have for it (for my normal requirements, K3b is perfectly adequate). The only reason Nero is under consideration at all is that I may not be able to install or use CloneCD and Nero is the only other application that I know that might reliably recognize and burn the images if they are in fact not flawed. I have already tried to install both programs; CloneCD installed without problems, but would not run, starting the debugger immediately with an error in the 32-bit code-- I would like to find out why, and if there is a solution. I then tried to install Nero 6.3, but clicking either the Nero 6-only setup button or the "install suite" button on the autorun dialog blinked and returned me to the autorun dialog-- I'd like a solution, if I cannot get CloneCD to run (which I don't think I can). This is a real issue I am attempting to solve, and my goals are clear. I am now going to the appdb to see if it will help me. 3.1) Gotta search for CloneCD, as I have no idea what category it would be in. Utilities=>File System, it turns out. Guess that makes sense, no idea if it's "intuitive". http://appdb.winehq.org/appview.php?appId=822 3.2) Version: not the version I have, but any port in a storm... Comments field says there's one comment. Also not a hopeful sign, but the appdb has been wrong about the comments before, and anyway, any port.... 3.3) ..what the..???!!! There is no comment! Is the description being counted as a comment? In any case, there is absolutely no information whatsoever for this application (I don't call "Description: Program for burning CD Especially to make clones of original CD\'s" information), and there are Zarro bugs found in Bugzilla (of course; I'm not even certain if Bugzilla is even linked to and indexed with the appdb in that way yet). OK, this is a dead end. Guess I'd better try to fix Nero, so it's off to http://appdb.winehq.org/appview.php?appId=152 . 4.1) Hey, the first app I've looked at in this db with a "native alternative" link. Nice, but I'm not reading the description anyway (I know what Nero Burning ROM is and does), so I almost missed it. I think that the link should be underneath the link to the Nero URL, above the screenshot (one extra field, thus; "Native Alternative <link to K3b>"). I'd be much more likely to see it then (if I didn't know about K3b already). 4.2) Versions: all versions that an 'ordinary' user might have are represented, good; no comments counted for any of them, bad (if true). Following the link to 6.x. 4.3) Nope, there are in fact no comments. And the description field is exactly the same, except without the native alternative link. What is the point of that? It's Nero version 6, one can reasonably assume that the program has not suddenly changed from the CD-burning application described on the overview page to a word processor, so why not at least put the changelog here.... oh, right, because we're not trying to sell Nero, which would be the only reason to put Nero's changelog in this field. It becomes much clearer now why the "Description" field is useless, and should be replaced by a "Summary" of whether this version of this application works in any way under Wine, and then the comments could/should contain solutions to the specific common problems a user might encounter when trying to install or run this (version of the) program. As it is, there's nothing for me here; let's see if version 5.x is any better. 4.4) huh, 7 comments, when none are counted on the overview page. 4.5) Two comments look like they might be helpful if I have problems attempting to install an earlier version of Nero (which I may have no choice but to attempt, since the appdb has no assistance for my preferred version of Nero, or my preferred application, CloneCD). 4.6) The most useful snippet on this page is the mention of Frank's Corner (without a link, but I know where it is), where I would next go to see if I can find some adequate instructions/help/guidance for one or both of these programs (not to mention IWD and IWD2). In actual fact, what I will probably do is transfer the CloneCD images to my boyfriends Windows PC, install CloneCD there, and burn them that way. It's a pain, but ultimately faster and easier than trying to find any organized assistance on these programs via the appdb. Which is just a bloody shame, imho. Anyway, I'm terribly sorry this was so long, but it seemed past time to offer some input on actual useability issues in the midst of all this discussion. The appdb does "work" as it is (I can navigate it, read the entries, etc); I assume that it will "work" when/if adjusted, both in terms of code, and with the addition of active maintainers. But it is barely of any *use* whatsoever as it is, and it's not clear to me whether the proposed redesign and/or increasing numbers of active maintainers will improve the db's practical functionality for users, for whom I feel this complex and difficult to maintain database should be a primary resource, from which they can both receive and offer assistance in an organized fashion. Or have I misunderstood the function of the appdb entirely? Holly

8 15

TechBot
by Ivan Leo Puoti Feb. 14, 2005

Feb. 14, 2005

Hello list, the #reactos channel has a thing called techbot that translates NTSTATUS and GetLastError() values from their numeric value to their meaning, I think it would be useful to have it in #winehackers, any objections? Ivan.

1 0

Re: Compiling MFC with Winelib
by Ira Krakow Feb. 14, 2005

Feb. 14, 2005

An excellent idea! I definitely want to include a section on compiling the MFC with Winelib in the book. From what I can see, it looks like a big part of it is compiling stdafx.h and generating precompiled headers. A nice enhancement would be for winemaker to sense that it's working with MFC sources and to generate the appropriate flags. Do you have any preliminary examples or documentation that goes beyond the current docs? It would help my experimentation. Thanks. Ira

1 0