Re: AppDB - Watchtower Library as Nr. 1 Top-10 Platinum application
The other factor is that it sounds like it's a fairly simple application to run, basically just a plain-text viewer with minimal DRM, which is why it has reached "platinum" status. Some games have as many as 400 votes. 2009/7/30 Igor Tarasov > 2009/7/30 Groeschel, Volker : > > This looks like a manipulation for me. > > > > How is this calculated? > > This is calculated by the number of votes. Watchtower Library 2008 has > 46 votes. 2nd place application - 44. > > -- > Igor > > >
Re: Appdb flight simulation sub category
To me, "Flight simulation" (like MS flight simulator, Top Gun, ...) seems like a totally different category that Simulation Games (SimCity, SimTower, Mall Tycoon, ...), so it should be a different category direcly under Games. -- DLL 2009/7/2 Ken Sharp > Simulation Games is already in there. Besides, I don't think the > categories are actually all that useful. > > > Keith Muir wrote: > >> Hi, >> >> Any chance of a games> simulation> flight simulation sub category? >> >> Regards, >> >> Keith >> >> > >
Re: Icons, logos, Tango, consistency, the user experience, and our project looks like a 2D champaign flute
On Thursday 16 April 2009 20:19, Ben Klein wrote: > 2009/4/17 Scott Ritchie : > > A user submitted a bug report to launchpad complaining that the Wine icon > > is not Tango compliant: [...] > > > > In short, it means the Wine icon looks very out of place [...] > > > > In short, it's ugly, but our real goal here is usability. [...] -1 Consistency != Usability Sure, it might look out-of-place, but Windows applications are somewhat out-of-place on Linux. It's very ugliness probably makes it easier to find. If the default icon is changed, current users will have more trouble finding it again. > Seems like a lot of fuss over a few trivial details: > 1) The Wine system icon is ugly (I'm all in favour of changing it, but > you make a BIG fuss over it) > 2) If the icon is changed, it should be done in time for Ubuntu 9.10. > (I have BIG issue with this. Wine is not exclusive to Ubuntu [...] Not sure about this. If someone is planning a major release, it's nice to get little things in place for it, especially a "branding" item like this. > 3) The glass is the wrong shape. Is it really THAT important? If > anything it makes Wine distinguishable from the beverage. Do we get > any outraged wine enthusiasts posting on wine-users or the forum > telling us that we use the wrong glass in our logos? Agreed. -- David Lee Lambert ... Software Developer, member IEEE, ACM Cell phone: +1 586-873-8813 GPG key at http://www.lmert.com/keyring.txt IM: davidleelambert (Yahoo!) or lambe...@cse.msu.edu (MSN)
Compile error in taskmgr before 1.1.14
I'm trying to use a git tree to do a regression-test for something that seems to have gotten broken somewhere between 1.0 and 1.1.19; but when I do a full "git reset _version_ ; git checkout -f ; ./configure CC='ccache gcc-3.4' ; make depend ; make" I get the following error before about 1.1.14: ccache gcc-3.4 -c -I. -I. -I../../include -I../../include -I../../include/msvcrt -DNO_LIBWINE_PORT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -fno-builtin -o about.o about.c In file included from about.c:29: ../../include/msvcrt/memory.h:27: error: redefinition of 'memicmp' ../../include/msvcrt/string.h:132: error: previous definition of 'memicmp' was here ../../include/msvcrt/memory.h:28: error: redefinition of 'memccpy' ../../include/msvcrt/string.h:131: error: previous definition of 'memccpy' was here make[2]: *** [about.o] Error 1 make[2]: Leaving directory `/usr/src/wine-git/programs/taskmgr' make[1]: *** [taskmgr] Error 2 make[1]: Leaving directory `/usr/src/wine-git/programs' make: *** [programs] Error 2 Does anyone remember seeing this error, or is it likely to be the result of misusing git? Build system is Debian 4.0 with gcc 3.3, 3.4 and 4.1 available. -- David Lee Lambert ... Software Developer, member IEEE, ACM Cell phone: +1 586-873-8813 GPG key at http://www.lmert.com/keyring.txt IM: davidleelambert (Yahoo!) or lambe...@cse.msu.edu (MSN)
Re: Regarding Implementation of Microsoft Speech SDK using wine
Mike McCormack wrote: Kalpit Shah wrote: I want to implement the Microsoft Speech SDK using wine on Fedora Core 3. How feasible is this.can anyone give me an insight on how do i go about doing this. please give me some orientation. The first step is to familiarize yourself with the Speech SDK's API on Windows. Perhaps write a simple test program that uses it, then try run it on Wine. The test program can later be submitted as part of the Wine regression test suite. Once you've done that, it should be a bit clearer which dll or OLE interface you need to implement to make it work. Someone has made Festival connect to the MS Speech API on Windows; it might be possible to run that Windows port under Wine, or use a similar method to link to the native Linux version (see https://lists.berlios.de/pipermail/festlang-talk/2006-January/000717.html ). Another possiblility would be to use JNI to call the FreeTTS libraries. Is there any reason why a Wine DLL can't dynamically link to Java? -- DLL
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
Joseph Garvin kzoo.edu> writes: > Tony Lambregts wrote: > > > It's been there a long time... > > > > http://www.winehq.org/site/forums > > > > look at [Archive 2] > > Now actually having looked at gmane, I can say that it's not nearly as > newb friendly as a real phpBB forum would be -- it wasn't even > immediately obvious that I could post replies, and the option is labeled > "Followup" a term which no modern forum/bulletin board uses anymore and > people won't recognize. [...] It would be easy to set up a forum for wine-user using phpBB and mail2forum. The tricky part would be administration. A poorly-mintained forum could be a point-of-entry for spammers, and might also encourage people to ask questions but never check the response. > That the World of Warcraft thread in the Gentoo Gamer's and Players > forum has become the center for discussion for running WoW under wine > for ALL distributions I think says something about the newb friendliness > of the mailing lists. [...] And the AppDB page for WoW has a prominent link to the Wine thread in that forum. Wine is a big project, and all discussion of it needn't be in one place. There are features that I'd like to see in AppDB, Bugzilla and the lists that aren't present, but at this point we've collected so much information that it would be a waste to switch to a different system. The one step that I think would help the problem you're trying to address is something I've suggested before: add a permissive "robots.txt" to appdb.winehq.org, and make the one on "bugs.winehq.org" more open. That would probably lead to fewer duplicate bug-reports as people find similar postings using Google or Yahoo. Incidentally, I'm posting this via GMane... -- DLL
Re: WINEBROWSER: also handle mailto: urls.
Hans Leidekker wrote:
As suggested by Alexandre, I factored out some common code
in winebrowser and extended it to handle mailto: urls as well.
This version looks much better. Just one small question:
+length = sizeof(mailers);
+/* @@ Wine registry key: HKCU\Software\Wine\WineMailer */
+if (RegCreateKeyEx( HKEY_CURRENT_USER, "Software\\Wine\\WineMailer", 0,
NULL,
+REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &key,
NULL ))
+{
+fprintf( stderr, "winebrowser: cannot create config key\n" );
+return 1;
+}
+
+r = RegQueryValueExA( key, "Mailers", 0, &type, (LPBYTE)mailers, &length );
+if (r != ERROR_SUCCESS)
+{
+/* set value to the default */
+RegSetValueExA( key, "Mailers", 0, REG_SZ, (LPBYTE)defaultmailers,
+lstrlen( defaultmailers ) + 1 );
+strcpy( mailers, defaultmailers );
+}
+RegCloseKey( key );
+
Why create another key in the registry? Wouldn't
HKCU\Software\Wine\WineBrowser , Mailers make it easier for a user to
find the value in the registry?
--
DLL
Re: What would most aid WINE development?
[EMAIL PROTECTED] wrote: The only real barrier that remains is for sufficient number of businesses and administrations to adopt a strategy where it is no longer acceptable to publish and transmit documents in a format that forces the recipient to have the lastest version of M$ office to read and modify a document. I used to be unable to read Office 2000 and later files with a certain non-Microsoft Windows word processor and with StarOffice, but for as long as I've been using it regularly, OpenOffice has never had a problem with any Word document I've been exposed to (and a lot of professors at my school use Word sometimes). Perhaps that barrier is pretty flimsy too? signature.asc Description: OpenPGP digital signature
Re: What would most aid WINE development?
Susheel Daswani wrote: My belief (which opposes the 'fact' stated above) is that if there was virtually complete documentation of what exists, and full disclosure of additions and modifications, a cloning could be achieved. Of course it would take a huge capital and time investment, but the payoff would likely be worth it. The finding you cite was probably true 10 years ago, but it may be less relevant today. There are many, many applications that were and still are sold to be used with the Win32 API, but there are other applications that are available commercially for Linux x86, and some also for Solaris x86 and FreeBSD. Furthermore, more applications are written to run on platform-independent runtime environments, such as Java, JavaScript and .NET. Besides, a pure Linux platform is sufficient for many, many tasks. On the other hand, some application developers like working against a complex, uniform, binary, proprietary OS that changes regularly but not too often, and don't care if it's a monopoly (since they don't feel like they are the ones paying for it.) Game vendors use all sorts of tricks to achieve "copy protection", as do digital music services. (Cf. the recent Sony incident.) Windows application developers also have a habit of trying to get the user to escalate their privileges more than is strictly necessary; for instance, MusicMatch Jukebox (which came free on my brother's WinXP laptop) won't run properly in a "Limited User" account. For comparison, I just installed the Linux version of matlab as a normal user (in my home directory, without becoming root), and it runs just fine. As a more general statement, the fact that old programs become unusable or unstable after an OS upgrade means that the useful lifetime of a piece of computer software is no longer anything near its copyright term, but instead only about 2 or 3 years. Even if a third-party organization verified that Wine 1.0.0 on such-and-such a vendor's version of Linux (kernel 2.6.1001, glibc7, ...) implemented 100% of the Win32 Unicode API calls correctly when set to the en_US.utf8 locale, a lot of application vendors (including Microsoft) would probably still not want to support it, because that version of Linux could be stored on a CD and run on a different computer 20 years from now with the same application. Of course, the biggest potential threat to Microsoft dominance is probably OpenOffice, Firefox and other open-source standard-document-processing applications. (I said "is" because they are only a threat together; no one component is a competitor by itself.) Just some ideas... signature.asc Description: OpenPGP digital signature
Re: Wine and Mono
Jonathan Ernst wrote: .exe files are often associated with Wine so that it's easy for users to double click a windows application and have it working like any native application. Wouldn't it be possible for Wine to detect .Net application and run them using mono (mono app.exe) instead of just failing ? According to an MSDN article ( http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx ), .NET executables are just PE executables that happen to be linked against MSCOREE.DLL. Perhaps Wine could detect an attempt to load that DLL and call Mono instead. In theory a program could execute arbitrary code first and then have too much state to pass to Mono safely, but if a lot of these applications are mechanically generated stubs it might not be a problem. If that's not wanted, would it be at least possible to issue a message to tell the user that the application he'is trying to run is a .Net application and that he should try running it using mono ? What are your opinions about the handling of .Net executables ? I tried running a .NET application the other day and it gave me a nice error-message (on the console) telling me that I needed to install .NET. Now that Wine is finally, officially, in a numbered release, it might be a good idea to reopen the question of Wine/Mono dynamic linking or other cooperation. For an example of the bad feelings that some .NET users have about WIne, take a look at the last post (the one dated 10-15-2005, 6:55) on http://community.sharpdevelop.net/forums/1310/ShowPost.aspx (note: SharpDevelop is an open-source .NET development environment.) -- DLL
Re: [wine] Re: Improve Bugzilla Query page usability by changing default state?
Molle Bestefich wrote: http://www.google.com/search?q=site%3Abugs.winehq.org doesn't work either, Google does not index the contents of the bugs pages. Not sure why. See http:///bugs.winehq.org/robots.txt I think at least the following paths should be opened up to GoogleBot and other indexers: /buglist.cgi /show_bug.cgi Then again, I'm not paying for the server, and there might be a concern that a spider could overload it. Still, I wish this information were made indexable; it might cut down of FAQs a bit. -- DLL
Re: Wine's Registry Format
On Thursday 16 June 2005 11:20 pm, you wrote: > On Sat, 18 Jun 2005 22:22:56 +0200, Alexandre Julliard wrote: > > Actually the current method is probably the fastest for everything > > except the initial read. > > The only reason that the current method is fast is because we're loading > the entire registry into memory. As stated in Bugzilla, this is fine for > small registries, but the author of the bug has noted wineserver allocated > up to 30MB when wine initiates JUST for the registry! How do you propose to keep track of multiple sources of the registry data? At one time Wine supported system-wide registry files as well as per-user ones, and some people would like to see that again. > Using BerkeleyDB to access the registry would provide the kind of > random-access that we need for such a large amount of information Samba already uses something called 'TDB', and it's been suggested that the two projects could share a case-insensitive-filename layer based on it; could you look into using that? > - It > would also provide us with a quicker and easier way to search through the > registry - so we could finally implement the Find feature in wine's > regedit without much effort ( Not that it couldn't be done as is, but > things would definitely be easier ). This could only be done at the expense of several times increase in on-disk storage, and would actually not be used very much. A more useful enhancement would be to support PCRE syntax for find-and-replace, or multiple views of data, or version-control of the registry... in fact, there are Windows programs that do all that, and all they require is a good, stable, quick implementation of the registry calls, which is what Wine provides. -- DLL GPG key at http://www.cse.msu.edu/~lamber45/newmail.htm?GPGkey pgpJtRZJKkxaE.pgp Description: PGP signature
Re: [wine] Soliciting suggestions for AppDB
On Wednesday 08 June 2005 08:32 pm, Mitchell Mebane wrote:
> I'm putting together a Summer of Code proposal for working on the AppDB.
> I've been talking with Chris Morgan, and he has a few suggestions, but I
> was looking for more. Does anybody have any features they'd like added
> to the AppDB, quirks they'd like worked out, or things of that nature?
I have some ideas about the AppDB, but I've been working on some of them
myself, and others really need the approval of the WinHQ webmaster more than
anything. Still, I'd like to hear what other people think of them:
1. The AppDB, Bugzilla and the Wiki ought to send last-modified information
for most of their pages. This would speed things up, in some cases, for
dialup users, but the real advantage would be as protection against a
slashdotting or onslaught of AOL users. Many of the pages also send other
headers that prevent caching of positive lookups.
Today I sent a patch to the AppDB maintainer to do this for images, which are
probably the biggest performance hit (they cause the AppDB main page to take
about 30 seconds to load over a dialup connection). However, almost any
page in each of these databases could in theory be cached. Bugzilla bug
display pages already display a "Last modified" datum in the text of the
page, and so do Wiki pages (bug 2889 mentions this).
Several of the AppDB tables already have TIMESTAMP columns, so I was planning
to write some code to just gather them all together and send the latest one
as the last-modified date. The only problem is that if a page contains an
item which is then deleted, its timestamp will go backwards.
2. The "robots.txt" on bugs.winehq.org is overly restrictive, and the
'robots.txt' on appdb.winehq.org and wiki.winehq.org are HTML pages. (Yes,
I know that they have a big red "404" in the middle when viewed by a human,
but they come back with "200 OK" responses to a spider). There might be
fewer duplicated requests for help in different places if search engines
could actually get at the text of bug reports and app comments.
3. It would be nice if the application display page could do a query against
the Bugzilla database directly, and diplay it, something like
(no reported bugs) _add one_
or
[12 open bugs, 6 closed]
with the numbers being links to the Bugzilla query page for full details.
It would also be helpful to be able to associate a bug with more than one
application.
4. The wiki should recognize the phrases "app " and "bug "
and make them links to the corresponding AppDB and Bugzilla entries.
5. Perhaps the information about Linux alternatives for each app could be
kept as a separate table, instead of as haphazard notes in app descriptions.
6. There are a couple more flags that would be nice:
license ENUM('OpenSource','Freeware','Commercial'),
availability ENUM('Available','Discontinued'),
linuxVersionAvailable ENUM('Yes','No')
--
DLL
GPG key at http://www.cse.msu.edu/~lamber45/newmail.htm?GPGkey
Re: [wine] Re: [msvcrt] Implement %I types for printf
On Mon, Jun 06, 2005 at 05:32:52PM +0200, Alexandre Julliard wrote: > Jesse Allen <[EMAIL PROTECTED]> writes: > > > Well it's rebuilding the format string, I thought for libc. Is there > > another %ll-like specifier? %I64 certainly is not. =) > > No, I'm afraid there is no standard way of doing that. You won't be > able to simply forward this one to libc, you'll need to do at least > part of the formatting by hand. The ll flag is specified by POSIX (2001, "System Interfaces", p. 404) and is described by the Linux (dated 2000-10-16) and Solaris (SunOS 5.9) manpages. I'd certainly call that a "standard way", even if it's not supported everywhere. Apparently 4.4 BSD and older versions of Linux libc used a "%q" flag for the same thing. Would it be OK for Jesse to use a "configure" check to see which is supported, at compile-time? -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey resume at http://www.cse.msu.edu/~lamber45/resume.htm
Re: [wine] Re: Software patents
On Thu, May 12, 2005 at 08:04:57AM -0400, gslink wrote: > The easiest way to resolve this business with Borland is to contact > Borland. They may also have an interest in Wine. If they have no > objection to what Wine wants to do then there is no one else to > complain. They might even help Wine. Borland probably doesn't even Borland may have some intrest in Wine (it can be used to run code produced by their compilers, which helps their potential market-share a bit). However, it could also view Wine as a competitor (especially to their Kylix product). I doubt they'd sue Wine developers over this, but it's possible that they have a reciprocal license that would require them to defend patent #5,628,016. Would Wine be able to proceed if we got the following statement from them? "Borland hereby grants a worldwide, royalty-free, non-exclusive license to use the methods described in U.S. patent 5,628,016 to the current Wine developers when they use the current LGPL source-code for wine, and to anyone who properly recieves a copy of that source-code or properly creates a derivative work based on it when they use said copy or derivative work." I think this would satisfy the conditions in section 11 of the LGPL. In absence of communication from Borland, we might also infer this based on their future public statements. I just don't want to see this turn into another situation like GIF files or PGP 2.x, where one company's patent put all "compatible" implementations on shaky legal ground. -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey resume at http://www.cse.msu.edu/~lamber45/resume.htm
Re: [wine] Re: Commercial support
On Mon, May 09, 2005 at 10:19:55AM +1000, Troy Rollo wrote: > > On 5/7/05, Shachar Shemesh <[EMAIL PROTECTED]> wrote: > > > I really suggest we adhere to KISS - Keep It Simple. > > In any case, the difficulty you have here is that anything you do that sets a > barrier against the bad guys is also likely to set a barrier against the good > guys. ... > If you ask the question "how can the WINE project stop some random company X > from exploiting the situation unfairly", then perhaps hoops is a good idea. > > If you ask the question "how can the WINE project get the maximum possible > benefit from this", then hoops may not be a good idea, since the WINE > project's interests lie in the largest possible pool of suppliers of > services. (Sorry about jumping in at the tail end of this discussion.) I say that we should accept all good-faith requests for inclusion after a posting on wine-devel or a patch against the website on wine-patches. Of course, the page should have a disclaimer such as "Inclusion on this list does not constitute endorsement by WineHQ, its sponsors, or any Wine developer." I hope someone will visit the websites once in a while, and post another patch if the linked page obviously has nothing to do with Wine. If the list gets big enough that it needs to be sorted, we could order it by lines-of-code-contributed, as suggested. Alternately, we could order the list by the provider's net operating income (aka "Income from Operations"?) during their previous fiscal year, and stick everyone who can't/won't provide financial information at the end, alphabetically. This wouldn't obligate anyone to pay anything, of course, but it would seperate the serious *commercial* support (companies or individuals who pay atention to their own financial statements) from organizations that would be less prepared to deal with a lot of new business. However, both of these ideas are just things to think about when the list gets longer. -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: [wine] Re: KERNEL: Implement undocumented SetCPGlobal API call
On Thu, Mar 31, 2005 at 03:18:27PM +1100, Troy Rollo wrote: > That assumes every process is OK working with the same code page. This is not > necessarily the case with a server application, which may well be serving > clients in multiple regions in a multi-national environment. I know one major The solution in this case is to use Unicode internally, and then add calls to WideCharToMultibyte() (NOTE: the first parameter "can be given the value of any codepage that is installed or available in the system" (Borland 5.0 helpfile)) or a cross-platform library like iconv(3) to your I/O pipelines. I would say that using the Windows OEM code pages is not suggested for new application development. > It may not even be the case with a client application: you may have a > software > reseller who supports multiple regions and needs to be able to view data in a > program that does not use Unicode when that data has come from a client in a > region with a different code page; you may have somebody in a business whose > native language is not the same as that of the locality they are in who > prefers to use most applications in their native language, but needs to use > some with the local code page to get access to business data. This situation is an even worse case to try hacking the undocumented Windows internationalization APIs. Remember, for instance, that Win95/98/ME *only* supports one OEM code page for the whole system, in the U.S. and Canada, and that for those systems the wide-character APIs are provided by a redistribuable DLL. If you're writing a text-editor or other general-purpose tool, you ought to be building in some character-set detection heuristics, conversion, etc., anyway. If you're developing you're application's data-file formats from scratch, you ought to define a format (probably using some form of Unicode for character data) and stick to it. Do you think IE or IIS actually uses this particular call? -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey resume at http://www.cse.msu.edu/~lamber45/resume.htm
Re: [wine] Re: [Discuss] Recycle Bin problem with Preclick image editing software
On Wed, Feb 09, 2005 at 09:00:10PM +, Mike Hearn wrote: > Niceness Don. Of course, it'd rock more if this had worked out of the > box. I expect we're missing some shell magic for the recycle bin. > Wouldn't be hard to investigate but have a million other things to do so > I'll CC this to wine-devel. > > Context is: app has a "send to recycle bin" option to delete photos. > Doesn't work. Native shell32/shfolder fixes it. If anybody is up for > what is probably an easy task, figure out why and fix it so c:\Recycled > is used. > > For bonus points we should bridge it to KDE/GNOME so if an app recycles > something it appears in your actual trash can :) comment in dlls/shell32/shlfileop.c says: "unimplemented and break if any other flag set: FOF_ALLOWUNDO, FOF_WANTMAPPINGHANDLE". FOF_ALLOWUNDO = 0x40 is the flag that says to use the Recycle Bin, if available. Note that Windows itself doesn't use the recycle bin on network drives or removable disks. Probably some extra logic could be added around line 1085 to issue a 'rename' (or MoveFileEx) call in either of the following situations: 1. The file is under the user's home directory; move it to ~/Desktop/Trash or ~/.gnome-desktop/Trash 2. The file is on a VFAT partition; move it to $(MOUNT_POINT)/Recycled However, the app in question is probably upset about something else, and there are still some stub functions in that file, so I doubt that a "correct Recycle Bin" is first-priority for the Wine team. -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey resume at http://www.cse.msu.edu/~lamber45/resume.htm
Re: PRESS: run windows viruses with wine ...
On Thu, Jan 27, 2005 at 07:36:54PM +, Mike Hearn wrote: > On Thu, 27 Jan 2005 08:29:08 -0600, Brad DeMorrow wrote: > > Many also seem to be worried that a virus under wine could do damage to > > their other partition with windows installed. I tell them that without > > an entry in Wine's configuration for that virtual drive - any pure > > windows application wouldn't even know that such a drive existed. > > That's not quite right, some viruses just do a recursive search for all PE > EXE/DLL files. They will find a real Windows drive eventually if it's > mounted r/w as drive z: makes the whole system available. However, the "Z:" drive in Wine is just a suggested feature; it's quite possible to run Wine without it. Something like Knoppix will automount all drives, but a sane, secure distribution generally requires manual intervention (as root) to even access non-Linux partitions. -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey resume at http://www.cse.msu.edu/~lamber45/resume.htm
Re: [wine] 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\. Please remember that under Windows 95 with multiple users or Windows NT 4, per-user settings are stored under C:\WINDOWS\Profiles\ or C:\WINNT\Profiles\ (if I remember rightly). The actual paths are stored in the Registry; or are you just thinking about changing the default locations for new installations? Either layout is fine for testing-only installations, but in a production environment I would probably point the "Desktop" to $HOME/Desktop (shared with KDE) and "My Documents" to $HOME/ . The have been regular questions on the users list asking how to do things like this. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: [wine] Linux registry
On Mon, Aug 30, 2004 at 03:27:49PM +0200, Robert van Herk wrote: > These people seem to be implementing a kinda Windows registry clone into > Linux, but then secure, stable 'n' stuff... I looked at this and, as it stands, the project is basically a bunch of hot air and a little bit of demo code that is far from "secure and stable". If it becomes widely used, it might create minor difficulties for Wine: 1. It has a tool called 'regedit', which conflicts with MS 'regedit.exe' and Wine 'regedit'; 2. It does not preserve the key/value dichotomy in the Windows API (i.e., I could make a key "HKCU\Software\LMert\xx" and a value "xx" in "HKCU\Software\LMert" and set them to different values -- this is of doubtful utility but a natural consequence of the Windows API). 3. It doesn't have the REG_DWORD type, or any integer type for that matter, yet. 4. Right now, the syntax is actually pretty text-editor-unfriendly: it has no support for numeric values and it creates a lot of little five-line files. However, the original author seems to want to move *all* config files in mainstream distributions over to his format, something that I don't see happening within the useful lifetime of Wine. Perhaps *they* should take a look at Wine code; as an LGPL project, Wine can't copy their (GPLv2) code directly anyway, and the Wine registry code actually has worked well for a long time. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: [Wine]faking network shares
On Thu, Aug 12, 2004 at 12:42:08PM +0100, Fergal Daly wrote: > I have an app that wants to read from \\server\directory\file.ini and I > don't have an easy way of changing this, so I want to tell wine that > \\server\directory is available in /mnt/smb/server/directory. Is this > possible? What do I need to do? If you try to read from a path starting "\\.\" in Wine (in some versions), you'll get a message saying something like "Fixme: UNC name (%s) not supported.", but there is basic support for Wine to read from a file directly over an SMB link for paths that start with "\\" up until Wine-20040505. It identifies itself as a WfW server and doesn't attempt to provide a username or password, as far as I can tell. It looks like the relevant functions were deleted before 20040615. In principle, Wine could probably provide UNC-name support by calling 'smbclient', or by parsing /etc/mtab for 'smbfs' mountpoints and trying to access them like any other file. Another alternative would be a configuration-file override to alias an arbitrary UNC path as some file, just like the old [Drive X] mappings. In your case, would it be acceptable to have a local, static copy of the .ini file, and just point Wine at that somehow? (Forwarding to the developer's list, since it looks like this is a useful feature that was removed because no one was finishing it.) -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: [wine] Re: config converting problem
On Wed, Aug 11, 2004 at 04:45:20PM +0200, Henning Gerhardt wrote:
> Hi Mike, you wrote:
> >I'm not sure what to do about this, except maybe to add back in support
> >for ${HOME} style vars. It's clear that people are "using" (at least,
> >installing) much older versions than we anticipated.
>
> Personally I would prefer to merge back the support for ${HOME}
> variables because I think many other people have the same problem
> if they want to upgrade wine.
Not having totally grokked the code, I think this raises an important semantic
issue: if ~/.wine/dosdevices and the config-file's text conflict, which has
priority? Or should Wine read the config-file and then (effectively) overwrite the
settings with the contents of ~/.wine/dosdevices? This won't work if Wine
automatically builds ~/.dosdevices from scratch.
It seems that mapping one drive to the user's home directory is a common case,
since many organizations already do this for users via Samba or Netware. As
presently implemented, is there any reason a system administrator shouldn't do
( cd /etc/skel ; mkdir -p .wine/dosdevices ; cd .wine/dosdevices ; ln -s f: ../.. )
where f (for example) is the drive letter used for each user's home directory, and
then use a shell script to push the change out retroactively to existing accounts?
--
resume at http://www.cse.msu.edu/~lamber45/resume.htm
PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: Wine and locales
On Wed, Aug 04, 2004 at 11:20:57AM +0300, Shachar Shemesh wrote: > David Lee Lambert wrote: > >On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote: > >>"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > >>I don't see how the settings would be different, surely LC_CTYPE is > >>always going to control the ASCII->Unicode mapping on Unix, so why > >>shouldn't it do that on Wine? If the issue is that users change their > >>setup without understanding the results, then surely adding even more > >>config parameters that they need to get right is not going to improve > >>the situation. > > > >1. ANSI->Unicode translation for programs that use the ANSI calls, as > >has been discussed in this thread. > > > Ok. > > >2. Unicode->codepage translation on standard output, and > >codepage->Unicode translation on standard input. ... > > > Why should we set it differently than 1? (1) is when a program talks to what it thinks is a version of Windows according to the author's understanding of a the codepage. (2) and (3) are how are how Wine talks to the rest of the system. What codepage should be used under a utf8 locale, such as most of the setups on Redhat WS 9? There are no Windows programs that actually pass utf8 data to the Xxxx*A calls; if a program wants to use Unicode, it will use the wide character APIs. (MS Word, PAF 5, IE 6...) (I know I said UTF16 before. I haven't actually tried a UTF16-only setup, and UTF16 is not compatible with the C library because it uses \0 in normal text, etc.) > Name one such filesystem, please. EXT and reiser never cared, as far as > I know. VFAT has to translate names stored in UTF-16. Are you saying the > kernels<2.4 didn't have the "iocharset" option? I have some files stored on a Windows ME box with names containing accented characters, which show up fine in Explorer and the MS-DOS prompt on that system and on other WinME systems accross the network. In Linux the filenames appear to be encoded in CP437 when I use 'smbmount' whith no options. The manpage says that iocharset= (Linux side) and codepage= (Server side) are only supported in kernel 2.4 and above. However, on my system that runs kernel 2.4.x, the problem persists even when I pass options "iocharset=utf8,codepage=cp437" I get a message about CP437 not being supported, even though I have a kernel module cp437.o . By the way, Explorer and command.com only allow me to enter directories with 8-bit-character-names on the local system. Under Linux, I can enter said directory using tab completion, even though the characters don't show up. > > This is all through > >GetLocaleInfo(), whose first argument is an LCID returned by either > >GetUserDefaultLocale or GetSystemDefaultLocale. > > > You can also pass "LOCALE_SYSTEM_DEFAULT" instead, but that doesn't > matter. In any case, there are "user overrides" here, which we may, one > day, want to implement. Everything is laid out in the table that started > this thread. > > >5. The MultiByteToWideChar() and WideCharToMultiByte() functions, which > What do we need to do with these? They get an explicit codepage to > convert to/from. Funny though it may sound, these functions are not > affected by locale. Right. > I don't agree. Mixing default codepages across simultaneously running > programs is not possible on Windows, and sounds horribly difficult to > implement. Clipboard handling and cross-file using are two examples of > things that are likely to go horribly wrong if we tried. If a program does a an ANSI call, it gets changed to Unicode. If that data gets passed back to another program using an ANSI call, it gets converted to the target codepage, as much as possible. If Wine is doing console output to a non-Unicode codepage, it gets converted there too. I'm not sure about mixing codepages under Windows, but input-method switching is easy. > Having one setting applicable to all running processes sounds good > enough. I don't object to a config setting overriding what LC_CTYPE > says, but I don't see a use for it either. Let's say I want to run an Arabic dictionary program and Spanish dictionary program as I'm typing a report in Word. Furthermore, the arabic dictionary program would use ANSI calls and expects to run on Arabic windows (with MS-ARAB encoding); the Spanish program would use LATIN1. Word uses wide-character calls. How would I run all these programs at the same time under Wine? (I'm not saying I actually have such a set of programs. Actually, I own a copy of a standalone program that allows typing of Arabic programs on Western windows, and also have access to systems where Office XP with the Arabic and US-International input methods is installed.) -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: Wine and locales
On Wed, Jul 28, 2004 at 10:13:15PM -0700, Alexandre Julliard wrote: > "Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > > > I like the idea of moving that setting to the config file. We can't > > use existing unix locale settings except LC_ALL and LANG because > > every user's system might have (and does have) very different locale > > settings, we can't assume that everyone out there configures locale > > in the same way. > > I don't see how the settings would be different, surely LC_CTYPE is > always going to control the ASCII->Unicode mapping on Unix, so why > shouldn't it do that on Wine? If the issue is that users change their > setup without understanding the results, then surely adding even more > config parameters that they need to get right is not going to improve > the situation. Actually, there are a number of different locale-related things that Wine needs to keep track of: 1. ANSI->Unicode translation for programs that use the ANSI calls, as has been discussed in this thread. 2. Unicode->codepage translation on standard output, and codepage->Unicode translation on standard input. Note that I could set LANG to 'en_US.UTF-16' on my Linux system, and programs SHOULD accept this. Most don't, however. 3. Unicode->codepage->Unicode translation on Linux kernels before 2.4, whereafter filenames are SUPPOSED TO be in UTF-8, and kernel modules do translation for filesystems where filenames are stored in some other charset. (OPTIONAL, as filenames are not a big deal and the newer kernel fixes it--however, there has to be a converson from the short-per-character format to UTF-8). 4. Selection of approriate language for strings in programs that use such selection, as well as time, numeric, and string formats. This is all through GetLocaleInfo(), whose first argument is an LCID returned by either GetUserDefaultLocale or GetSystemDefaultLocale. 5. The MultiByteToWideChar() and WideCharToMultiByte() functions, which allow a program to do its own conversion to and from Unicode with a specified codepage. I think (1) should be specified on a per-program basis in the config file, with a system default there, and, as final default, raw translation for ANSI-to-Unicode and something reasonable the other way. I said in another message that codepages are deprecated; I meant that the ANSI calls (as opposed to (5)) are deprecated for internationalized applications. The '.codepage' suffix of LANG and LC_CTYPE should both be searched for the answer to (2). As for graphical output to X, it doesn't seem like that should be restricted by setting LANG. For (3) there should be an option in the config file like "filesystem_codepage", but it should default to utf8. For (4), Wine should select an appropriate LangID and LCID based on the la_CC tag and return them, respectively, in response to Get*DefaultLangID and Get*LCID. In wine, at present, there is not really a seperate 'system' level. Furthermore, wine could respond to different groups of GetLocaleInfo() constants according to LC_MESSAGES, LC_NUMERIC, etc., but this is an unusual feature that probably isn't needed at first. It seems that using the config-file to define codepage translation and the suffix for IO charset translation gets rid of the typical user's need to have other variables besides LANG set. Consider locales I might use: LANGLCIDLangID -- en_US 1 9 es_MX 52 10 es_US 1 9 ar_SA 966 1 Let's say I have a program that prints "Hello, World" in the current language, using wide calls. When I run it in Linux, it should print that string out using the current language and codepage. Suppose I also have a database program that was written in outer burgoslavia and keeps its data files in the encoding for outer burgoslavian, which is supported only by Windows 95 for Burgoslavia and Windows Server 2003. I don't want to change Linux to support Burgoslavian, but if Burgoslavian is encoded in some Unicode font I can add a section to [AppDefaults] and let that perticular program think it is running on an all-Burgoslavian system. For (5), the functions act the same no matter what locale the user is in. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: Wine and locales
Dmitry Timoshkov wrote: I still want your patch to be removed until you at least write test cases showing what exactly APIs are affected by system/user locale. Using LC_CTYPE for the system default locale (current ANSI code page) is very dubious choice as well. The whole purpose and the patch itself are pure hacks aimed to fix unexplaned side effects. I think it would be best to set the codepage for an app in the [AppDefaults] section. Codepages are deprecated in favor of full Unicode support, but specific apps might use ANSI APIs, and might even expect certain locales. For instance, Quattro Pro 9 appears to parse text from the clipboard and from ODBC calls as CP437 on my WinME boxes. By the way, I think a system-wide /etc/wine.conf should be brought back before the 1.0 release. -- DLL
Re: [wine] Re: IE6 installation error. would you please give me a suggession
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jul 02, 2004 at 12:42:02PM -0400, Andrei Barbu wrote: > Can't the wine installer chmod a-w all of those right when it sets > things up? This won't work if the WINDOWS\\SYSTEM directory is on a VFAT partition. > > solution is to this. Maybe preventing the Wine FS code writing to symlinks > > if they are inside the windows directory or something equally hackish - - or > > just ensuring that the exe.so files are always readonly. > It'd solve the problem more elegantly than having to add extra code that > might break other programs. It might be simplest to simply reinstall Wine after installing IE. Or, if we can get Wine to run the native REGSRVR32.EXE with no trouble, it shouldn't be a problem when the Wine version gets overwritten with the native version. Someone who wants a Microsoft-free installation won't install IE anyway. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5meJkeetBuAdnkIRAspQAJ9ua13goN8NnhRGlzK4eqjSKPfNAACgpllS 15rpfMNwCTvauB61uUpGEOA= =aDxt -END PGP SIGNATURE- -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: [wine] Re: Fw: [Mono-list] System.Windows.Forms plans.
On Fri, Jul 02, 2004 at 10:48:57PM +0800, Jonathan Wilson wrote: > Bascily, there should be 3 sorts of APIs exported in WINE. ... > and 3.external WINE apis. There should be a limited set of special APIs > which are made available to enable projects like mono and others wanting to > interact with win32 code and/or the windows API implementation in WINE. > These should be specificly documented and made stable (as in, we wont > changer the prototype and we wont change the basic idea of what these > functions do). In other words, what Wine needs is not so much a stable API as a stable meta-API to determine what is actually supported. > For example, ... > If these were made stable, then apps that use them could be gauranteed that > things wont break. Then, the only thing they need versioning for is to > identify if a certain windows API is present or not. If it is, > WineGetProcAddress (or whatever it is) will return an appropriate address. > If its not, it would return an arror and you could work around it. (which > may mean prompting the user to upgrade WINE). The smaller said native-interaction API is, the easier it will be to keep stable. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: Setting up drive letters without wineinstall?
On Sat, Jun 19, 2004 at 05:42:36PM -0700, Alexandre Julliard wrote: > An initial set of symlinks will be created by wineprefixcreate; they > can then be modified with winecfg (or by changing the symlinks by hand > of course). The plan is also to have winecfg autodetect cdroms but > that's not done yet. Speaking of this, I tried to make a config file with no [Drive X] sections at all, and Wine wouldn't load (It complained about a missing L"C:\\WINDOWS\\SYSTEM" directory, even though I had the apropriate entry in the file). I added a dummy [Drive X] section back into the exact same file, and wine loaded just fine. It looks like the parser might be broken, but I haven't had a chance to look more closely at it yet. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: [wine] Re: Zombie processes
On Tue, 8 Jun 2004, Robert Shearman wrote: > Shachar Shemesh wrote: > > It seems Wine has been > generating lots of zombie processes > when it's not 100% cleanly killed. I > have also seen the system hold > a socket created from a wine process in > "ESTABLISHED" state, when no > process is registered as the socket's owner. > > According to Alexandre according to Mike, this is a kernel bug. Well, it > > most certainly is. Theoretically, there is nothing a user space process > > can do to cause zombies to stay around after their parent has exit, or > > keep sockets open after their controlling process has quit. As wine is a > > user space only process, this must be a kernel bug. No way around it. > > However, it happened to me both on RedHat 9 with 2.4.something (NPTL I'm experiencing odd problems with RedHat 9, and it may or may not be related to Wine. Sometimes when I leave the computer for a while and come back, the screensaver has come on an the system has frozen. There is no response to the keyboard and mouse, and the system (apparently) doesn't respond to the network either. However, cycling the power and rebooting brings the ext2fs partions back up in a dirty state, requiring fsck. It could be a BIOS thing (sleep mode enabled), but it seems to only happen when I have Wine running. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Latest Wine with Corel Office 9
I just got around to patching and compiling the '0408 release of Wine,
and I notice a few improvements. I tried it out with Corel PerfectOffice
9, of which my family has several copies. Here are my
results:
WordPerfect hung at the splash screen. Presentations loaded up, but the
menu was empty except for "File", and the "Open" item didn't appear to do
anything, so I used "Exit" successfully. Quattro Pro quit after a few
seconds of the splash screen, giving about a screen of errors:
I await thy bidding $ wine qpw.exe
err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym (No
Name) :
err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=0)
err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym (No
Name) :
err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=1)
err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE20
(ISO_Left_Tab) :
err:keyboard:X11DRV_ToUnicodeEx (virtKey=9,scanCode=F,keycode=17,state=1)
err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FEF9
(Pointer_EnableKeys) :
err:keyboard:X11DRV_ToUnicodeEx
(virtKey=90,scanCode=45,keycode=4D,state=1)
err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym (No
Name) :
err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=0)
err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym (No
Name) :
err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=1)
fixme:ole:CoRegisterMessageFilter stub
fixme:tab:TAB_WindowProc Unimplemented msg TCM_SETEXTENDEDSTYLE
fixme:accel:CreateAcceleratorTableA should check that the accelerator
descriptions are valid, return NULL and SetLastError() if not.
fixme:ole:CoCreateInstance no classfactory created for CLSID
{eab38d25-26dc-11d2-98c0-00104b24170b}, hres is 0x80040154
fixme:storage:StgCreateDocfile Transacted mode not implemented.
err:seh:setup_exception stack overflow 0 bytes in thread 0034 eip 401bfc99
esp 40851000 stack 0x4085-0x4095
I thought I ought to report the "Please Report" messages; WordPerfect
gave similar ones.
Is anyone planning to implement CreateAccelleratorTable and related
functions any time soon? If not, is there any reason I shouldn't try
it?
--
resume at http://www.cse.msu.edu/~lamber45/resume.htm
PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey
Re: [wine] Re: Implement RegFlushKey
On Sat, 27 Dec 2003, Shachar Shemesh wrote: > Dmitry Timoshkov wrote: > >"Shachar Shemesh" <[EMAIL PROTECTED]> wrote: > > > >>This is a request to understand, not a suggestion (yet?). > >>Why not use a general purpose DB system? (postgresql, mysql, whatever) > >>After all, the registry is just a tree shaped database. We can do that > >>using standard SQL, and fall back to our current method if a proper DB > >>is not found. ... > Two tables - one for keys, one for values. > > The keys table: > key ID, primary key (serial type in PGsql). > Key name, varchar (or whatever). > Parent key (foreign key to key ID). > unique index on key name (if the database support the collation where > things are case insensitive, which most databases should). This should be UNIQUE(parent_id,key_name), unless the "Key Name" is actually the full path, which seems counterproductive. > The values table: > Key - foreign key to the Key ID in the keys table > Value name, varchar. > Value type - long int > Value data - binary > Primary index - key+value name (unique). > > Alternatively, if you want easier editing of the DB itself, you can > split the data into seperate tables - one for strings, one for numbers, > and one for everything else. As you point out, this would require triggers or database-specific constraints to maintain integrity. (Actually, you could probably make this into one table; aren't key names and value names in the same namespace? - No, they're not. Win32 has seperate functions RegEnumKey() and RegEnumValue(). On WinME, it's possible to have a subkey and a value by the same name.) > What you gain - fast, efficient, Unicode aware manipulation. Data > integrity taken care for you. Concurrancy taken care for you. Seems too > good to be true, I think. One thing to think about is performance. Do we want to undergo round-trip network time for every call to RegOpenKey()? Now, with prepared statements and a binary database protocol ofer a UNIX-domain socket the overhead might not be so bad, but it's still an extra layer. The real power of this is that it would allow for better multi-user interaction, if that's what is desired. Wine could load HKEY_LOCAL_MACHINE based on $HOST or $DISPLAY and HKEY_CURRENT_USER based on getuid(), all in the same table. I'm not sure how secure this would be, since most SQL databases don't support row-lovel ownership of data. (Perhaps we could change to a three-tier approach, in which registry keys are exposed as XML objects?) Global search-and-replace is easy in SQL: just do an "UPDATE table SET x=REPLACE(x,'pattern','new value') WHERE x LIKE '%pattern%'", for instance. To do regular-expression substitution of all keys recursively under a certain one, one might need to write a one-page perl script, but an ASCII file doesn't preserve the registry's tree stucture either when doing search-and-replace either. -- DLL
Re: [wine] List of API functions and completeness.
On Thu, Sep 11, 2003 at 12:21:56AM +0200, Jacobus Erasmus wrote: > Hi I'm looking for a list of all the functions that would be displayed > in a debug list. ... > Basically I'm interested in writing a little script that would run > through a debug output and pickup all the functions called with the > execution of the Windows program in wine. You don't really need a list of functions to do this; you just need to parse the debug-output (probably of 'wine -debugmsg +relay'). It should by easy to do this in Perl and store the result in a MySQL table, for instance. Probably the table would be based on the tuple (program, function, count)... You could also just collect the informatio in a hash and print it to stdout, but that would be less useful for comparing multiple programs. -- DLL
