Re: Wine FAQ edits
On Thu, Feb 3, 2011 at 18:17, Albert Lee tr...@forkgnu.org wrote:
The instructions were intended to give some context for users who
might not be familiar with the ~ expansion.
Using {$HOME} would be more portable. The Bourne shell (/bin/sh) on
Solaris (9/10 - OpenSolaris defaulted to ksh) doesn't support ~
(although csh, zsh, bash, tcsh, ksh and just about all the other
bundled shells does, it sh is the default shell)
(Checkin proper quoting in case it contains spaces might be necessary..)
Gert
Re: Wine FAQ edits
Correction:
${HOME}
Re: Wine FAQ edits
On Sat, Feb 5, 2011 at 10:05, Gert van den Berg wine-de...@mohag.net wrote:
On Thu, Feb 3, 2011 at 18:17, Albert Lee tr...@forkgnu.org wrote:
The instructions were intended to give some context for users who
might not be familiar with the ~ expansion.
Using {$HOME} would be more portable.
And using ${WINEPREFIX:-${HOME}/.wine}/dosdevices/c:/Program Files
should work correctly in any Wine setup (on a Bourne-compatible
shell), including one using a custom WINEPREFIX. (But might be
somewhat hard to follow for someone not familiar with the
technicalities of the Bourne shell)
Re: banning spammer from the forum
For the forum it might be useful to find / write a phpbb extension that disallows URL shortening services (and known spam domains) and forces a captha check on users posting ANY link to a non-whitelisted domain... (pastebin, a decent image hosting service, winehq, microsoft, codeweavers, google, LMGTFY for a start...) Even if it is a relative uneffective captcha, it should at least make spamming more difficult... Wine the mailing list integration, it makes sense to try and get something to strip email addresses (Not sure if the mailing lists archives hide them?) to prevent robots from finding them... (If the official archives is stored in a database (I know phpbb does for the forum), stripping it should be easy (at least for the SQL wizards...)) Gert
Re: The WineAPI wiki.
On Mon, Aug 2, 2010 at 18:16, Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: There should be links to the Microsoft documentation in each article, but Microsoft has been known to move their documentation around without maintaining redirects. To avoid being at Microsoft's mercy in this, a summary (*not* a duplicate) of the Microsoft articles, which would be fair use, should be maintained. There seem to be several interfaces to retreive MSDN articles... Some of those interface might be more stable / provide a way to retrieve a current link? (Framing the content would probably not be allowed, but retreiving links should be...) http://blogs.msdn.com/b/innovation/archive/2009/04/22/launching-low-bandwidth-loband-v1-and-new-ide-view.aspx Some more: http://blogs.msdn.com/b/innovation/archive/2009/10/26/launching-lightweight-beta-view-for-msdn-library.aspx Web service interface: http://services.msdn.microsoft.com/ContentServices/ContentService.asmx (possibly the most useful for building current links?) (It might also work to try and retreive as much information about MSDN links when they are posted, in order to allow the links to be updated when the site stucture change?) (Doing a web service query everytime to retreive a link would probably be slow and inefficient...) Gert
Re: The WineAPI wiki.
On Mon, Aug 2, 2010 at 19:26, Max TenEyck Woodbury m...@mtew.isa-geek.net wrote: On 08/02/2010 01:04 PM, Gert van den Berg wrote: There seem to be several interfaces to retreive MSDN articles... Some of those interface might be more stable / provide a way to retrieve a current link? (Framing the content would probably not be allowed, but retreiving links should be...) If it *looks* like copying, it should be avoided. What I meant is, that it would allow for things like some really nice side-to-side postings of Wine's documentation and MSDN... It is unlikely to be legal though... (And should therefore be avoided) I think it will be necessary to regenerate articles as the Wine project evolves. I regenerated the 'dlls' page after Alexandre's CVS run today. There was some new content so I saved the result. I've regenerated the individual DLL pages several times as I improved the generating scripts. Both activities put a load on me that I am trying to automate. In fact, if you look at the original post before it got hijacked into a discussion of the project name, it asks about a way to improve that automation. Since there will be fairly frequent semi-intelligent reviews of pages, such queries can probably be incorporated into that process. Can you help me with this, please? I can give an overview of what I think... I might do a bit of implementation, but finishing something bigger than a short script when I have other things to do isn't always easy... Sourceforge provides quite decent hosting in the project hosting space as well... Automating things from there might be a good idea. To handle MSDN, I can see the following (very) high level process: Posted MSDN links gets converted to point to redirect system in the project space. (The conversion retrieves and save some additional data). The redirect system will redirect the user to relevant content on current MSDN (allowing user to configure some parameters, such as view type / language) What I managed to figure out about MSDN content for the Web services documentation this far: 1. Content is identified by a Content identifier, which can be any of the following: a. GUID b. Short ID (Short (~8 character) unique identifier such as ms224917) c. Alias (Friendly string) d. asset ID (Documented here: http://msdn.microsoft.com/en-us/magazine/cc163541.aspx Can be used to retrieve other (non-URL) identifiers) e Content URL (The URL to an MSDN page) 2. A Content key uniquely identifies an article and consists of a content identifier, locale and version 3 The version.identifies the various versions of the documented item. e.g. the .NET version / VC++ version 4. Locale identifies preferred language More detailed version: 1. Find MSDN URL and retrieve other identifiers (GetContent without a locale seem to retreive almost all the metadata (partial match in the docmentaiton)) 2. Store data in database, with GUID / short ID / assetID as primary key (they are always-present unique identifiers) other fields include alias, current URL. (content table) 3. Other tables: Locales and versions. Mapping tables between content and possible locales and versions hould also exist. The content table should save when the data was last updated and it should be automatically updated once it reaches a certain age and an user wants to retreive the page / select a non-default locale / version. 4. Generate new link pointing to the redirector system. The redirector system needs the unique content identifier (GUID / shortID / assetID) and preferably a version. It should be able to take a parameter to preview the URL (probably a smaller options link) and allow the user to choose other locales / versions and generate links to those. This content options page should also allow problems with the redirector's link to be reported. The reports should be used to update the information for that link by querying it again from MSDN. It might require several trips to MSDN to initially add an item / to update versions and locales. This should possibly scheduled once the data get really old (somewhere between 180 days and 1 year) and be run on demand when someone requests the content from somewhere where they might want to see the other versions / locales about half the scheduled update age. This should keep the request volumes to MSDN low... MSDN changes and updates required: 1. Changes to web services interface: Update relevant parts (This shouldn't be too serious as long as the entire interface is not redesigned) 2. Link changes: Change how the URLs are generated from the identifiers in the database (I don't see an easy way to request an URL from the web services interface) Other possible extensions: The redirector can build a more complete view of what is available to allow documentation to be found easier (the information should only be retrieved on demand and saved) and to prevent duplicate trips to MSDN. (This should eventually provide a nice tree of MSDN with reliable links
Re: Please remove / block user from bugzilla
On Sat, Jul 17, 2010 at 10:27, David Gerard dger...@gmail.com wrote: You are going to get noise. Stopping people reporting bugs is probably not the answer. It's hard enough to get bug reports out of people already. A Where do I (of What do I do when...) section in the FAQ might help in some cases? (with a link near the bug comment box) Some suggested sub-questions: Have trouble applying a bug Have trouble compiling Wine Have problems with PlayOnLinux Tested an application and it doesn't work MY application crashes It might be a good idea to try and get most potential bug reports discussed on the forum first? A link to the patch problems question one near the attachment list might work as well. Regexp searches with You seem to be doing something bad (see _here_), are you sure you want to post this comment? confirmation for dodgy comments might help pointing users in the right direction in the most obvious cases.. (and it won't keep comments from being posted by the persistent/ in case of false positives...) Gert
Re: Please remove / block user from bugzilla
On Thu, Jul 15, 2010 at 16:23, James Mckenzie jjmckenzi...@earthlink.net wrote: Rosanne and you have a good point, but I would restrict it the limit to four lines. You should be able to describe a valid bug in that space. Anything more, and it becomes an attachement. 4 lines is horribly short... Especially for posting instructions to reproduce problems, an overview of your system configuration, etc... If bugzilla supports word-based filtering, looking for words commonly present in logs and not present in most posts (fixme:?) to try and prevent users from posting logs as comments... (Quoting parts of a log might be useful at times?) Gert
Re: Porting WIne to D
On Thu, Jun 24, 2010 at 10:55, Francois Gouget wrote: OOP: A lot of the Windows API is exported through DLL entry points and these are not object oriented. Where the Windows API is object oriented is: OOP in C is not impossible wither... It is harder than it could be, but it is possible Wine also has very strong requirements with regards to threading, CPU register usage, exception handling, all of which require very low-level control which negates the advantages high level languages might have in these areas. The good: * D is specifically intended to support low-level applications. * Built in UTF-8 / UTF-16 / UTF-32 support * Types defines size - an int is always 32-bit * COM support * C-compatibility * Standardized inline assembly * Build-in support for unit-tests, etc. (Will require all the tests to be rewritten in a different way though..) D still have some issues, such as two incompatible, competing standard libraries... Version 2 might be worth considering for some new projects... Like the D website says: Who D is Not For * Realistically, nobody is going to convert million line C or C++ programs into D. Since D does not compile unmodified C/C++ source code, *D is not for legacy apps*. (However, D supports legacy C API's very well. D can connect directly to any code that exposes a C interface.) D also specifically drops 16-bit support, which might cause problems for the Win16 / DOS parts of Wine... I'm not sure how widely gcd/dmd is supported. Will it run on some of Wine(lib)'s rarer platforms? (like MIPS Linux, Itanium Linux, x86/x86_64 Solaris, SPARC Linux, *BSD on unusual platforms, OS X (PowerPC, x86 and x86_64)) Linking to C code from D is obviously supported. I'm not sure how well it is supported in the other direction (crucial for winelib...) It is not clear if non-Unicode strings are supported... (No non-Unicode char type exist...) Gert
Re: Porting WIne to D
On Wed, Jun 23, 2010 at 20:48, Stephen Eilert spedr...@gmail.com wrote: On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph cds.w...@gmail.com wrote: Well, being a garbage collected language, it would help with the memory leaks in Wine. Being OOP it could extend the design of the code to make it cleaner and reusable. The assertions above are opinions, not facts. Also, it requires a full rewrite. You can mix D code and C code... A more modern language can result in more readable code, but it is a lot of effort for a small benefit... (And D is a very new language, possibly to the degree that portability might be impacted due to a lack of compilers on some of the more obscure platforms / architectures). Certain parts of Wine might benefit from the latest (draft) version of C++ and the size of the codebase can probably be reduced in size slightly, but a bad port to another language doesn't help anyone... (The C++ standard library is huge and might getrid of some POSIX dependancies) It might require quite an extensive rewrite to get it to a proper C++ program, rather than a C program containing a bit of C++ and compiled with a C++ compiler... Fixing the current problems with Wine should be a much higher priority than porting it to a different language... Porting a codebase the size of Wine will probably take years... C can do anything that other languages can, the amount of effort might differ a bit, bit the difference is probably minor compared to familiarizing yourself with a new language, new libraries, etc (I like D - it have most features from languages like Java and C#, with the option to switch off things like garbage collection and it compiles to native code... Experimenting with it for new project might make sense) (IMHO: Allowing other languages than C for some of Wine's bundled applications (notepad, winecfg, winemine, etc) might make sense, as long as the QC for committing patches doesn't suffer. The mixing of languages within components (single application / DLL) will probably cause confusion and ugly code though... Getting proper QC would probably mostly involve sticking to things that AJ is familiar with.) Gert
Re: Porting WIne to D
On Wed, Jun 23, 2010 at 22:58, Christopher Selph cds.w...@gmail.com wrote: Porting a codebase the size of Wine will probably take years... Actually I'm working on a program to convert C code to D code. You can find/replace most instances of code, like unsigned int (C) with uint (D). The import/include files might take some work though. Just converting the syntax won't help much. It might compile, but it lacks the design changes (such as proper OO) needed to properly exploit a new language. You end up with code with the same problems as the original, but in a language that the programmers are unfamiliar with... (For C++, duplication of functionality in the STL is an example of what often happens if you directly port C code) Wine (like the Linux kernel) might be a good codebase to test your application on (for your own testing), since it is quite a large, complicated codebase... The chances of having it accepted into Wine is probably quite small... (My guess would be that your chances of being struck by lightning while winning the lottery are about equal...) http://www.winehq.org/site/docs/winedev-guide/style-notes might give you an idea of some of the things relatively simple patches struggle with to get included... Gert
Re: Top wine-using country: Russia?
On Sat, Apr 24, 2010 at 22:50, Dan Kegel d...@kegel.com wrote: It might be interesting to know which countries use Wine the most. I have no idea how to measure that, but the top three countries in http://www.google.com/trends?q=winetricks,+playonlinux are Russia, Czech, and Ukraine! Some other interesting trends: (Things changing names through the years make it hard to get a nice trend) http://www.google.com/trends?q=winetricks%2C+winehq%2C+cedega%2C+crossover+linux%2C+codeweaversctab=0geo=alldate=allsort=1 Gert
Fwd: Is there something we can do about Java?
Correct from address... -- Forwarded message -- From: Gert van den Berg Date: Tue, Mar 9, 2010 at 22:34 Subject: Re: Is there something we can do about Java? On Tue, Mar 9, 2010 at 21:49, Austin English austinengl...@gmail.com wrote: How is this different from dotnet20/mfc42/etc.? MS Java used to be bundled with (some versions of) Windows? (If an application was released requireing XP SP1 before the release of SP1a, its developer might have assumed that Windows will include the Java VM) (With IE completely removable under Win 7, it might be even more similar...) http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine#Windows_XP Gert
Re: Is there something we can do about Java?
On Tue, Mar 9, 2010 at 21:49, Austin English austinengl...@gmail.com wrote: How is this different from dotnet20/mfc42/etc.? MS Java used to be bundled with (some versions of) Windows? (If an application was released requireing XP SP1 before the release of SP1a, its developer might have assumed that Windows will include the Java VM) (With IE completely removable under Win 7, it might be even more similar...) http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine#Windows_XP Gert
Re: dns-sd dll implementation -- Needs work
On Tue, Feb 23, 2010 at 09:37, Dmitry Timoshkov dmi...@codeweavers.com wrote: C.W. Betts computer...@hotmail.com wrote: What do you guys think? it's a wrapper for multicast DNS, aka Bonjour®. Looks like this is not a part of Windows or PSDK Neither is OpenAL It might provide functionality as part of Wine that might be hard to implement on top of Wine? On OS X, it would also eliminate the need to install the Windows version of Apple applications bundled with OS X in order to run things that uses a single library provided by them. (e.g. Bonjour support in VLC) Gert
Re: dns-sd dll implementation -- Needs work
On Tue, Feb 23, 2010 at 18:57, Steven Edwards winehac...@gmail.com wrote: Do you really want to run the Windows version of VLC on OS X? I believe there is a better case to be made with Safari/Quicktime/iTunes as I believe they also install Bonjour services on Windows. If you wanted to validate/compare how the native service works verses say a wrapper then it would be of use. Pidgin might be another example... What I really meant is that it should at least be evaluated... (I didn't realize at the time that Bonjour for Windows has a seperate installer available...) It might have a valid use if conflicts exist between Windows Bonjour under Wine and native bonjour / other Zeroconf implementations... (such as listening on the same port) (If such a confilct exists, it should be possible to run either a ZeroConf implementation natively or to run it under Wine, but not both. This can be problematic, since two of Wine's largest platforms, Ubuntu and OS X installs ZeroConf implementations by default) (I'm not familiar enough with Bonjour / ZeroConf to really understand which parts of it is wrapped by this DLL) (It seems that DNS Service Discovery is able to function without mDNS) Just a note: According to Wikipedia, Photoshop CS3 is among the applications using Bonjour under Windows: http://blogs.adobe.com/jnack/2007/01/cs3_doesnt_inst.html Gert
Re: idea: display drivers
On Sun, Feb 7, 2010 at 21:40, David Gerard dger...@gmail.com wrote: On 7 February 2010 15:40, Reece Dunn mscl...@googlemail.com wrote: 1/ Does this mean that OpenGL is required for all GDI calls, not just D3D? If so, it will exclude people who don't have OpenGL support (e.g. are using the vesa, nv, or nouveau drivers). As I understand it, current Xorg does OpenGL in software on any video chipset it supports ... eeerrryyy ssslllooowwwlllyyy, but it does it. But what about other X servers, such as Xsun, Xvnc, remote Xming sessions, etc?
Re: idea: display drivers
On Sun, Feb 7, 2010 at 22:47, David Gerard dger...@gmail.com wrote: No idea, sorry. Xsun is on extended (life-)support with Sun moving to Xorg (and Alan Coopersmith from Sun being one of the main Xorg developers). Xming is Xorg compiled for mingw Xming: An ancient version of Xorg (at least for the free version) (6.9) I have seen Solaris 10 default to Xsun in some cases... (Although Xorg is available...) What I meant is that requiring OpenGL might lose some portability... (Needing an X server for console apps is irritation, but solvable using something like Xvnc. This becomes a lot harder to solve if you need an X server with OpenGL) Gert
Re: Winehq donation and DATA COMPRESSION
On Sat, Jan 30, 2010 at 15:58, Gerold Jens Wucherpfennig gjwucherpfen...@gmx.net wrote: BTW I've done some cabinet.dll stuff some years ago. Can anybody give me a hint to some easy-to-understand data compression documentation? I want to complete the cabinet.dll archive creation compression, if I get the required knowledge. It's so difficult... :-( 7-zip might have some usable code under a LGPL license (many files are public domain as well)? (But is is mostly C++, but some codecs seem to have C implementations...) (p7zip might be easier..) http://www.7-zip.org/ Gert
Fwd: Winehq donation and DATA COMPRESSION
correct from address -- Forwarded message -- From: Gert van den Berg On Sat, Jan 30, 2010 at 15:58, Gerold Jens Wucherpfennig gjwucherpfen...@gmx.net wrote: BTW I've done some cabinet.dll stuff some years ago. Can anybody give me a hint to some easy-to-understand data compression documentation? I want to complete the cabinet.dll archive creation compression, if I get the required knowledge. It's so difficult... :-( 7-zip might have some usable code under a LGPL license (many files are public domain as well)? (But is is mostly C++, but some codecs seem to have C implementations...) (p7zip might be easier..) http://www.7-zip.org/ Gert
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Wed, Dec 2, 2009 at 18:05, Ken Thomases k...@codeweavers.com wrote: Are you using Terminal.app or some other terminal application? If Terminal.app, have you turned off the Set LANG environment variable on startup setting in preferences? (That's the name on Leopard. If I recall, that setting is slightly different in Snow Leopard: Set locale environment variables on startup or something like that.) I'm using Terminal.app using default settings (AFAIK, except for colors). Set locale variables at startup is enabled. I don't see settings for en_ZA* in /usr/share/locale (af_ZA does exist, but if my applications turn Afrikaans I'll go insane ;-) ) (And OS X does not have a language settign for Afrikaans) Actually, I think that Wine should respect the LC_* variables if they are set. So, the precedence order would be LC_ALL LC_* Mac OS X System Preferences LANG. As far as I can figure out, no LC_* variable, except LC_ALL specific the actual locale? They only determine individual settings, which overwrites the default for the locale, as set by LANG? (Not sure if it effectively means set everything to LANG's locale, overwrite individual settings from LC_* if they are defined) If one of the LC_* variables are set, that expresses user intent (because those variables are not set by Terminal.app automatically). Also, it is useful to allow the user to override the System Preferences on a category-by-category basis. Mine gets set to C / UTF-8(for LC_CTYPE) of some reason... Gert
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Wed, Dec 2, 2009 at 22:52, Ken Thomases k...@codeweavers.com wrote: On Dec 2, 2009, at 1:22 PM, Gert van den Berg wrote: As far as I can figure out, no LC_* variable, except LC_ALL specific the actual locale? They only determine individual settings, which overwrites the default for the locale, as set by LANG? (Not sure if it effectively means set everything to LANG's locale, overwrite individual settings from LC_* if they are defined) I'm not sure what you mean here. Are you referring to the general Unix meaning of these variables or Wine's use of them? General *nix meaning. What I meant is that LC_* (not LC_ALL) don't have a setting that says the locale is say en_ZA it only has we have number (LC_NUMERIC) from en_ZA, times (LC_TIME) from en_UK, sort things (LC_COLLATE) according to en_AU, determine whether something is a letter / number and how to change their case (LC_CTYPE) according to UTF-8, ect. LANG is only setting that really maps to Wine / Windows' sCountry and Locale settings. (if all LC_* variables are set, LANG only determine things not in any of the LC_* variables) LC_* does not have anything to determine the actual UI language either. What I meant above, is that you should be able to get the equivalent effect (to the POSIX default) by setting everything to LANG's setting and then changing them from the LC_* variables. E.g. if LANG is fr_FR (not sure if that is an actual name) and LC_TIME is en_US, set environment up for French, change settings affected by LC_TIME to US English. Setting LANG to French and all individual settings to en_US, shoulld reslut in a system where the country is France, Locale code is 0x040c, UI is French, but date / time / number / currency settings, etc. is that of en_US. Considering how OS X seem to set variables, that might work as well... My interpretation of your proposed logic for OS X: Set up everything to OS X setting, overwrite everything if LANG is set, overwrite further settings from LC_*, overwrite everything from LC_ALL if that is set. (the slow unoptimized way that might result in some settings being overwritten 4 times before settling on a value...) Resulting order: LC_ALL LC_* LANG OS X settings. As near as I can tell, Wine only probes the locale information by invoking setlocale(category, NULL). It doesn't directly examine the environment variables. Furthermore, it only queries using the individual categories, not LC_ALL. It uses setlocale(LC_ALL, ) once to tell the C library to initialize itself from the environment. So, I'm not sure how setting all of the LC_* variables to a given value can be different from setting LC_ALL to that value. Interpreting it as above, settings LC_ALL is equivalent to setting all LC_ variables and setting LANG to LC_ALL's value. If one of the LC_* variables are set, that expresses user intent (because those variables are not set by Terminal.app automatically). Also, it is useful to allow the user to override the System Preferences on a category-by-category basis. Mine gets set to C / UTF-8(for LC_CTYPE) of some reason... Maybe Terminal.app is setting LC_CTYPE when it can't set LANG. Check what's actually set in your environment: env | egrep ^(LANG|LC_) Sorry, only LC_CTYPE is actually set, to UTF-8. (form the locale command's output one would think that it does the same, which it obviously doesn't) Looking at the current values, your order for OS X makes sense. If the actual effect is similar to the result of the overwriting above, you can overwrite settings as in *nix, but OS X's ones are used by default. (Not sure what it will do if OS X actually knows your locale?) Gert
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Tue, Dec 1, 2009 at 06:12, Ken Thomases k...@codeweavers.com wrote: On Nov 30, 2009, at 9:34 PM, James McKenzie wrote: The idea behind most of the MacIntosh 'magic' is that the user is deliberately oblivous to this. I agree that Wine (well, anything) should meet the user's expectations without the user having to even be aware of their expectations. Unfortunately, respecting LANG does not lead to this... An important question is: Which environment should Wine emulate under OS X? Unix apps under OS X, Windows in the same locale as OS X or OS X-native apps? (I tend to prefer emulating OS X by default and allowing overrides using LC_ALL (in order to allow one override method on all platforms, which LANG is unsuitable for, since it is a last resort option)) In addition Wine should leave the registry settings alone if the settings on which they were based were left unchanged. This allows a user to fully customize Wine's regional settings without changing anything in the environment where Wine is run. I just ran the set command in a terminal.app session, of which I have several running right now, and it was set to en_US.utf8, which is what I expect because the 'American' flag is displayed in the top information bar (also called the 'Apple' bar.) Gert may want to run the set command in a terminal session and given what was said, the LANG setting should be en_ZA.utf8, which is what I expect for South African English. I'm paste it in here soon... My Ubuntu settings is: mo...@mohagpc:~$ locale LANG=en_ZA.UTF-8 LANGUAGE= LC_CTYPE=en_ZA.UTF-8 LC_NUMERIC=en_ZA.UTF-8 LC_TIME=en_ZA.UTF-8 LC_COLLATE=en_ZA.UTF-8 LC_MONETARY=en_ZA.UTF-8 LC_MESSAGES=en_ZA.UTF-8 LC_PAPER=en_ZA.UTF-8 LC_NAME=en_ZA.UTF-8 LC_ADDRESS=en_ZA.UTF-8 LC_TELEPHONE=en_ZA.UTF-8 LC_MEASUREMENT=en_ZA.UTF-8 LC_IDENTIFICATION=en_ZA.UTF-8 LC_ALL= My OS X settings is: (Language set to English, Formats set to South Africa) MoHaGLaptop:~ mohag$ locale LANG= LC_COLLATE=C LC_CTYPE=UTF-8 LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LC_ALL= I would interpret that as default language, C for numbers, currency, etc, which would not be correct. (I think a (Perl/Python if any of them support native locale under all OSes?) script to quickly test the behaviour under Wine / OS X / *nix might be handy to figure out what applications are actually seeing) But, more importantly for this discussion, the fact that LANG will be appropriate for you and probably Gert does not mean it will be appropriate often enough for Wine to rely on. As I have said, there are many ways in which users configure their language and formats settings that will not be properly reflected in LANG (and, indeed, cannot be). The Wine project could use this as a default with the Mac, which is not POSIX compliant. You are suggesting using a proxy for the real thing rather than the real thing. If we want to maintain the magic, Wine should just use the settings from System Preferences directly (via CFLocale, CFNumberFormatter, and CFDateFormatter), with an optional way to override them for those rare users who want Wine's behavior to deviate from the system's. That makes sense to me... (If Wine tries to be a good OS X app under OS X, rather than a good POSIX app under OS X) (And what is suggested was current Wine settings of environment remained the same, LC_ALL (to allow for similar override everywhere), platform specific settings (e.g. individual settings from OS X's Formats settings), LC_* (which only contains specific settings, not country / language), LANG (for unset settings, and locale/country itself). On OS X this should mean that the variables other than LC_ALL only gets looked at if reading the OS X settings fail for some reason) For consistency with *nix override via LC_ALL makes sense (ignoring all other LC_*/LANG settings on OS X, in favour of OS X specific settings) LANG doesn't help maintain the magic. It's a hindrance. LC_ALL should be used to override settings, not LANG. LANG doesn't work (on Linux at least) if LC_ALL is defined. Telling users to use LANG if it only works in certain cases does not make sense... mo...@mohagpc:~$ LC_ALL=en_US.UTF-8 LANG=en_ZA.UTF-8 wine regedit /E - 'HKEY_CURRENT_USER\Control Panel\International'|egrep Country|Locale iCountry=1 Locale=0409 sCountry=United States mo...@mohagpc:~$ LC_ALL=en_ZA.UTF-8 LANG=en_US.UTF-8 wine regedit /E - 'HKEY_CURRENT_USER\Control Panel\International'|egrep Country|Locale iCountry=27 Locale=1c09 sCountry=South Africa I'm actually quite impressed with Wine's handling of the locale under Linux, it seem to be possible to overwrite the individual settings with LC_*, which I did not think was possible based on Vitality's comments on Wine-users. In addition it seems not to mess around with the settings if the environment stays the same. (Which is mostly the behaviour that I prefer, since it starts with defaults based on my settings (whether it is based on
Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.
On Mon, Nov 30, 2009 at 22:01, Ken Thomases k...@codeweavers.com wrote: On Nov 30, 2009, at 4:35 AM, joerg-cyril.hoe...@t-systems.com joerg-cyril.hoe...@t-systems.com wrote: What's the relationship between LC_xyz and LANG? The official answer for programs using glibc is: the library will test the environment variables LC_ALL, LC_CTYPE, and LANG in that order But is glibc actually used on MacOS?? POSIX specs: http://www.opengroup.org/onlinepubs/007908799/xbd/envvar.html#tag_002_002 Short version: Order of checking: LC_ALL LC_whatever LANG Not sure how Wine's registry integration is implemented... I would think that the most compatible (with the host *nix environment) way would be: Check saved locale variable values, if none was changed from last run, use current registry settings. If any was changed in a way that would affect behavior, rerun relevant parts below logic. (e.g. do not rerun if LC_ALL stayed the same, since that override EVERYTHING). If variable affecting locale code was not changed, change only the relevant settings. If LC_ALL is defined, set locale code from that, else set it from LANG default to Windows default locale. Fill in defaults for locale. If LC_ALL was not used above, go through LC_whatever and overwrite settings in registry according to that. This leaves settings at defaults (preferably Windows defaults) for language if only $LANG is set. It uses the Unix settings if they are set, for consistency with the host OS and allow the settings to be changed as for Unix apps. Saving the values and comparing it, also allows the user to change the settings, and not loose it each time Wine starts. On my OS X 10.6, (Set to English, South African currency / numbers (Which is actually correctly uses a decimal comma, unlike Ubuntu / Windows)) LC_ALL is blank, LANG is blank LC_CTYPE is UTF-8 (affecting toupper, etc according to POSIX page), all others are C. Following above logic, this would result in US English settings everywhere. (Not sure if Apple might be modifying the behavior of localized output functions to match settings, even if C is set, need to test). ( http://images.apple.com/macosx/technology/docs/L416017A_UNIX_TB_FF.pdf might help if OS X specific overwrites are needed. IMHO, it should try replicating the OS X preferences (setting each registry setting according to (potentially custom) settings in OS X after setting locale code according to language and country), with a way to overwrite. (LC_ALL would by my preferred method, since it has the highest precedence in POSIX). This should then result in the following locale logic: Saved Wine settings (if nothing changed) LC_ALL OS specific LC_* LANG C. As far as I can tell, this should result in a configuration that mimics the host OS, unless specifically overwritten. Some settings might not be easy to map to the Wine version, and if no setting Wine setting exist, a warning should be printed (e.g. if Windows uses locale code rather than a separate setting for something POSIX has a separate variable, a warning should be printed if the POSIX settings would result in different behavior than configurable from Windows) In addition, if any settings exist in Wine that can not by set by LC_whatever, it should be easy to edit the Wine value from Winecfg / Wine control panel. (If an OS specific method allows it to be overwritten, it may be left out on those OSes) Gert
Re: Another article that makes me want Wine to run in a sandbox
On Sun, Nov 8, 2009 at 03:55, Dan Kegel d...@kegel.com wrote: On Sat, Nov 7, 2009 at 3:40 PM, James McKenzie jjmckenzi...@earthlink.net wrote: You really underestimate the stupidity of people. I expect that people will do utterly stupid things, there's no two ways around that, it's human nature. That being the case, I think there are still opportunities for providing a safe computing experience without compromising the user's convenience. Convincing packagers to recommend (not sure if anything but clam supports this...) / have clamav as a dependency might help (Although it would probably help if Wine uses libclamav to scan all files before running/load even if the clamav daemon is not running and libclam is present...) (No idea what infrastructure that would require, but it sould need a way to turn it of, etc... Also not sure if that is something Wine is supposed to do...) Gert
Re: Please write audio tests (was: Playing ULAW sample correctly?)
On Wed, Nov 4, 2009 at 12:48, joerg-cyril.hoe...@t-systems.com wrote: Hi, 1. generate a PCM sine wave tone (like winmm/tests/wave.c); Actually any repetitive signal may not be good enough for general purpose, sine or square. Perhaps add some change in volume? For instance, there currently is a bug somewhere that causes Wine to repeat the first second of an intro animation's sound (bug #18182, comment #3) instead of continuing. This would probably not be detected. Also, the µ-law speech sample I fed to the MCI produces stuttering. Perhaps that would not be heard with a sine wave, if the periods match. A chirp (frequency sweep) might help for most of these issues? (Another sound with volume sweeps might be needed for other issues?) Chirps are quite easy to generate. (I'm not familiar with Wine's code yet though...) http://en.wikipedia.org/wiki/Chirp Gert
Re: Removing active maintainers
On Sat, Jun 27, 2009 at 02:32, Dan Kegeld...@kegel.com wrote: (What's missing is the ability to add howto's and notes at the application level, i.e. one level higher than the version level where they all go right now, but that's not usually a dealbreaker.) The usefulness of app-level howo's depend a lot on the application. It should work really good for things like games, while it would not work at all for things like Office. As long as the version-level howto's are kept, application level howto's / notes might be useful, even if just for pointing out which version is prefered for Wine. Gert
Re: Removing active maintainers
On Fri, Jun 26, 2009 at 11:51, Pauli Nieminensuok...@gmail.com wrote: Then also add automatic system that removes points from comments based on how old they are. I don't have any good number for this now but feeling is that for high traffic applications something like a point per week might work while low traffic apps should have a point every 3 months. For something that works irrespective of the app's popularity, removing a point after every n (or multiple of n) votes, with n the amount of comments on the app which is visible by default?
Re: Removing active maintainers
On Thu, Jun 25, 2009 at 17:10, Susan Craginsusancra...@earthlink.net wrote: With regard to Dragon NaturallySpeaking, I have the following comments. ... Version 9 should be entirely deleted. That refers to the early 9.0 Preferred release, which is not available any more. 9.0 Preferred has been replaced by 9.5 Preferred, which is garbage like Standard. We should not have people buying DNS 9 Preferred and thinking it is installable when it is not. Versions should not be deleted, especially not for programs sold on actual disks. A user may dig up an old copy somewhere and wonder whether it would work. If the version is deleted, he/she will not know and/or may recreate the page with his results. Gert
Re: wine compatible logo needed
On Tue, Jun 23, 2009 at 18:33, Stefan Dösingerstefandoesin...@gmx.at wrote: One problem of such a logo is that Wine changes constantly, and apps may break any time. So if we wanted to make such a logo official, that would be a two-party contract *) The app developer tests his app with wine *) The Wine community tests this app before releasing a new Wine release. Currently we cannot do our part due to lack of resources, especially with the bi-weekly snapshots. We have a very small set of supported apps in the stable releases, but we don't know how far we can grow this as-is. I thought that's what stable releases are for... A Works with Wine 1.0 logo might be a lot easier. (I'm sure quite a few Windows XP-logoed apps broke on Vista) Since quite a few distributions include only the stable version anyway, it is probably a lot easier for users. Gert
Re: Test patch
On Mon, Jun 22, 2009 at 04:01, Austin Englishaustinengl...@gmail.com wrote: The 'patch file' listed in the README should be deleted, since it's no longer provided. It seem to be sent to wine-releases.
Re: PowerPC MacOSX work...
On Thu, May 28, 2009 at 04:00, James McKenzie jjmckenzi...@earthlink.net wrote: The question is: Were there any programs written for WindowsNT for the PPC? I don't know of any, off hand. A few seem to exist... Probably nothing without a x86 versions though. Compatibility with PowerPC NT applications might at least give a few programs, even if just MS's applications that got bundled with PPC NT, to test with. It would probably not have much (if any) real-world uses, but it might point out portability issues that might affect other architectures, which might have more applications available, such as x86_64 and Itanium.
Re: PowerPC MacOSX work...
On Mon, May 25, 2009 at 13:44, Stefan Dösinger stefandoesin...@gmx.at wrote: The main trouble is that Windows apps are x86, so in order to run anything but builtin notepad you'll need a CPU emulator. In that case, just compile wine as x86 binary and run it in the emulator as well. Just a random question: Any chance that PowerPC Windows apps might work on a PPC Wine build? A PowerPC port of Windows NT (3.51 and 4 according to Wikipedia) briefly existed Don't know if any apps more than those bundled with Windows existed. (Here's one: http://www.jmcgowan.com/ppc.html ) Gert
Re: Fwd: [Wine] The easiest way to convert Mod/Tod video from JVC and any vi
If it is mostly automated spam, it might help to try and confuse the scripts by inserting traps for them that users can't see (fields hidden via CSS, etc...) http://jkroon.blogs.uls.co.za/it/spam/ahead-of-the-spammers-for-once Human spammers are a totally different issue... And most solutions that I can think of would either increase moderator load (such as moderating a user's first post, which is probably not supported by phpbb anyway...), or require a lot of manual maintenance (Keyword based filters)... What the spam do seem to have in common: External images (and usually lots of external images) and external links... Quite a few sites ask the users to solve simple maths problems as well, but that could not be too hard to bypass... Gert
Re: wine shirts
On Mon, Mar 2, 2009 at 7:54 PM, Dan Kegel d...@kegel.com wrote: Herve wrote: http://img522.imageshack.us/img522/8526/wines2.jpg Not bad! Now for text... something like Linux + Wine Dissolve Windows headaches fast! :-) Wine cures your Windows hangover! :)
Re: Malware on Wine review
On Thu, Feb 26, 2009 at 2:50 AM, Ben Klein shackl...@gmail.com wrote: 2009/2/26 King InuYasha ngomp...@gmail.com: Also, NTFS DOES have a concept of execute bits, but Windows itself does not use them. An implementation of this is the trusted app scheme in the properties in Windows Vista and above (I don't remember if XPSP2 had it also). Although this scheme is mostly broken, it was intended to stop the execution of apps just downloaded from the internet from a non-trusted source. NTFS has the concept of metadata. Windows does not use it as an equivalent for +x bit though. And even if it did, it wouldn't be a big help for Wine, because Wine doesn't like NTFS :) http://msdn.microsoft.com/en-us/library/bb776297(VS.85).aspx (And I mentioned it in my blog post mentioned earlier) Gert
Re: Malware on Wine review
Not sure exactly where in the thread this fits in, but here goes On Tue, Feb 24, 2009 at 1:58 AM, Zachary Goldberg zg...@bluesata.com wrote: 2009/2/23 Dan Kegel d...@kegel.com: Ben Klein shackl...@gmail.com wrote: http://www.avertlabs.com/research/blog/index.php/2009/02/23/running-windows-malware-in-linux/ Do not set the file association for Windows executables with Wine. This would enable running Windows executables in Wine by simply double clicking them. I saw a patch floating by to turn this on by default recently. Maybe we should make it off by default, but easy to turn on...? This would annoy all the people that the association targets. We can either make it easy to run all Windows apps (malware and legit) via file manager, or none at all. Yes, exactly. The default should be off, and it should be easy to turn on. - Dan I disagree on this point. Is malware via Wine on Linux really a problem commonly affecting users? What happened to replicated Window's behavior bug for bug? User X might ask: double clicking an exe works in Windows why shouldn't it in Linux? Why should user X have to go through an extra step to do something on Linux than they would on Windows? I posted my opinion on the matter on my blog. It basically says Try to make like XP SP2 for downloaded files, but do it for files on drives marked as noexec as well http://blog.mohag.net/2009/02/sane-rules-for-determining-likely.html Gert
Re: An idea for the appdb
On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead kaz...@gmail.com wrote: I can also see what you mean about spyware, but other apps retrieve stuff from the web if there is a connection (CDDB, and album covers are two examples). Wine transmitting every application I run to someone else would be rather worrying... It should rather be opt-in. Such as Wine has detected that it is the first time you run this application, do you want to check AppDb for more information (Yes/No/Ask again/Never ask for any application) It must be easy to disable globally as well... It might have some other uses as well such as A newer version of the application works better, etc. I might be handy to allow automatic submission of test data to AppDb (which IMHO might be more useful than just retrieving...), which should automatically include the Wine executables' checksums + version, distro info (if accessible from lsb-release, parts of the uname output kernel checksum, which might be used to detect the distro), kernel version, cpu architecture, X server name and version, graphics driver name and version, DLL overrides, etc. This might help modified wine versions and the level of tweaks to be detected by AppDb automatically. (There should be a very specific opt-in process for this data's submission though, such as letting the user manually upload a file with this data and fully disclosing the file's contents) This kind of data can be handy for bug reports as well. Gert
Re: Wine being targeted for adware
On Thu, Jan 15, 2009 at 7:50 PM, Austin English austinengl...@gmail.com wrote: Of course, Wine is open source, so if someone wants to edit it for that purpose, by all means, do so. I'm not sure that Wine _should_ do so though, at least, not now. Networking on a per app basis I can see an argument for, since Windows Firewall is now included and provides such a feature. Can't SELinux or something similar disable network access per-application? I would think that this kind of functionality should be provided by the OS, not by Wine. (Having control over what can / can't get to the network can be real handy for purposes such as server-hardening.) (Solaris Trusted Extensions seem to provide this kind of functionality...) Wine should probably at least provide APIs that can be used by anti-malware applications... (I'm not sure about recent applications, but, IIRC, older ones under Windows 9x used to use drivers for on-access scanning which is not currently supported in Wine) Gert
