USB passthrough does work but I don’t trust Windoze much, so I would often want to backup (in Windoze) AndroidProjects to my memory stick and then ‘switch’ the USB stick over to Ubuntu so as to ‘backup’ the AndroidProjects to my /home/AndroidProjects in Ubuntu’s. Also, the B4aBridge Android app (running on my Android phone) is flaky, the Android emulator runs at tortoise speed when in VirtualBox, and as I implied previously the phone is difficult to get Basic4android to connect with by usb so as to install a .apk onto it & it’s difficult to get basic4android to put a .apk onto the phone’s sdcard . Even more gripes!
Ubuntu 11.10, AMD64.
How do I change the $PATH? And, since winecfg works (and it does not exist in /usr/bin/), shouldn’t wine work too?
Well I would have expected so, as /usr/local/bin should also be in your $PATH, and obviously IS or you’d have to enter the full path to winecfg.
I’m guessing something (some config file or other) got left behind when you uninstalled the old version of WINE, that is telling winecfg to look in /usr/bin
I installed it on 11.10 64bit too … I’ll get back to you when I’m sat at that PC (later this evening).
This may be due to wine being a 32bit application … there have been multiple bugs filed with 32bit apps not being “found” in 64bit Oneiric, though an update was supposed to have fixed the issue.
Try this …
sudo apt-get install --reinstall libc6-i386
now does:
wine --version
returns anything ?
A few links to bug reports:
and
and
As I said, I’m not the best person to ask for help with getting Windows apps to work in WINE, but I wish you good luck with your Android project 
If I get the chance, I’ll see what I can come up with as far as getting Basic4android to work (if indeed it’s possible) … but I wouldn’t hold your breathe, application configuration in WINE isn’t really my strong point
Strangest thing… It works now, but only in newly opened Terminal windows. The old terminal window threw an error message when I tried to run wine, but the new window does it just fine.
By the way, shouldn’t I be using a 64-bit version of Wine? Wouldn’t that give it access to more CPU power or something?
Firstly, I’m glad WINE 1.5.1 is now working … and thanks the feedback
Secondly …
NO … 64bit is only about memory addressing space … ie. 32bit OS’s can only access up to 4GB of memory, 64bit can (using 48bit addressing) theoretically handle 256TB, but there are usually other factors that limit it to less than that, but whatever the actual 64bit limit is, it will be more than you’re ever likely to need, or probably be able to afford.
WINE is supposed to be 32bit
You CAN build a 64bit version of WINE for using 64bit Windows applications … but (I gather) it is less reliable for 32bit applications (which most are), and there are even problems with some Windows 64bit application binary interfaces.
You’d use the same source code, (and instructions above) but use
./configure --enable-win64
instead of
./configure
But there’s really no point unless you have more than 4GB of RAM, and NEED to run a Windows 64bit application … and even then you’d likely be creating other problems for yourself.
More info here:
http://wiki.winehq.org/Wine64
Confirming that the install went fine for me in Peppermint 2 64-bit.
Thanks for the update, nice to know for sure it works in Peppermint too.
Below are extracts from a sequence of emails between me & Scott Ritchie of the Ubuntu Wine team:
My initial email:
I understand that wine 1.5 is now available. Are you going to put it
into the ppa for Lucid?
Scott Ritchie of the Ubuntu Wine team:
Currently I plan to intentionally not backport 1.5.x to lucid, maverick,
or natty because the libraries there are too out of date. If someone
has serious issues and thinks they can fix them with newer wine, they
probably also need newer alsaplugins library (and a few others) – this
will nudge upgrades in those cases, lower expectations in others, and
probably save us a lot of irrelevant bug reports.
I believe this also jives with upstream desires, which wants to drop
code supporting super old versions of libraries as well. Lucid is
beginning to show its age.
My response:
Thanks for your reply. Interesting about not backporting wine1.5.x to Lucid. I use Lucid because (for me) Ubuntu STS versions do not have sufficient length of support & tend to be more buggy than LTS versions. I do not intend to use Precise for at least a few months after release as it has the look of too many bugs for my taste. Anyway, I’ve compiled wine 1.5.1 & it works fine under Lucid 64 bit.
BTW do you know any way of getting the wine dev team to sort out particular bugs in wine or even of finding out when they might be sorted? The bug I want sorted is 30085.
His reply email to me was:
Not really, because in principle we often don’t know ourselves. Even a
very well defined and documented bug could have multiple causes – you
work very hard at fixing the topmost error and the bug ends up still
being there. Sometimes it’s turtles all the way down.
Similarly, often bugs are fixed without anyone realizing. Wine
development tries to focus on reimplementing the Windows API correctly
(with Apps used to demonstrate correctness and roughly measure
priority). So, if we’re doing it right, we probably fix a whole bunch
of bugs we didn’t even know were there in apps we didn’t really test.
This is why “is this still an issue?” is such a common sort of thing to
see on Wine bug reports - in a traditional software project someone
might be able to close bugs as they do em.
Odd reply that, not wanting to support software that uses libraries contained in one of their LTS releases BEFORE end of life.
Though I haven’t tried it in Lucid, I’ve noticed no problems in Natty and Oneiric, including audio.
When he mentions “upstream” wishes, I’m supposing he means Debian, well I don’t see it as Debian’s job to support Ubuntu LTS releases … so maybe its partly an internal politics issue.
I must say it smacks a bit of:- We can’t be ars*d, just move on to Precise, which brings a whole new meaning to Long Term Support.
Thanks for the info, very interesting
I must also add that this feeds into my growing (and published on the forum) disillusionment with Canonical/Ubuntu.
It might have been an interesting exercise to have put that up on the Ubuntu forum and invite comments, then watch all the “Ubuntu Fans” jump to their defence (or not) 
Particularly if you have masochistic tendencies
@Mark Greaves
I did consider putting it up on Ubuntu Forums. However, I really want Wine bug 30085 fixed and I thought that it might cause it never to be fixed. Though looking at Scott Ritchie’s replies & responses on the Wine Mailing List when I asked how to expedite Wine bug fixes, I’m starting to think that it will never be fixed anyway. I don’t understand why a member of the Ubuntu Wine team should imply that he’s speaking on behalf of all of the Wine org (sorry if that’s not the correct name for the organisation controlling Wine fixes): does anybody know about the relationship between Canonical & the Wine org? I don’t know if it’s due to the recent changes at the top in Canonical, but they seem to be attempting to compete with Microsoft in the arrogance & patronising stakes. By the look of what Linux Mint are doing, they seem to be listening to their user base re the dislike of Unity & therefore providing Gnome3 based alternative interfaces (i.e. MGSE, Cinnamon, MATE).
PS is it possible to put a spelling checker function when posting to this forum?
Spell checking is a function of your web browser … which browser are you using ?
Just through reading launchpad, I’ve come to the conclusion that reporting a bug in Ubuntu is all about helping them, and make no difference to if/when they come out with a fix.
There are ongoing bugs with tons of postings, that have been going on since “Hardy” and before and are still unresolved … so it seems to be a “we’ll do it if/when we feel like it” affair
Indeed they seem to mark a bug as closed at the drop of a hat and without any investigation.
IMHO Launchpad (though a good source of “user” input and fixes) … is purely to help Ubuntu track bugs they ARE interested in … not to guide them in WHICH bugs they should be interested in.
That said … bugs in WINE should really be reported on the WineHQ Bugzilla page:
http://bugs.winehq.org/
As far as the Ubuntu WINE PPA team are concerned … it’s my guess that all they do is build Ubuntu compatible .deb packages from the WINE source code.
Bugs in WINE itself (unless they are specific to the way it works in Ubuntu) are beyond their remit.
Mark,
I use Firefox 11.0: I’ve obviously missed how to spell check in the browser. As I was typing, the word ‘behaviour’ got underlined by a wavy red line. So it’s an immediate spell checker in Firefox i.e. spell checking was there all the time but without my realising. I previously thought that you had to do spell checking in Firefox by explicit command!
I’ve noticed that Ubuntu often close bugs without proper investigation. Their behaviour is just like help desks (within IT departments) who close bugs without user agreement: I suspect so that the figures look good on their department reports.
Bug 30085 is on the WineHQ Bugzilla page (not Launchpad Ubuntu): apologies if I didn’t make that clear.
Given that your paraphrased statement that “all that the Ubuntu WINE PPA team do is build Ubuntu compatible .deb packages from the WINE source code” is true, it just shows Canonical’s arrogance. I’m not sure that WineHQ is any better. When I posted to the Wine Mailing List about trying to fix bug 30085, one of the replies was to the effect that one bug had been notified for a few years and had taken 2 years to fix once work had started on it: this posting was made by someone who was proud of the work done by the WineHQ team!
I’d just like to point out that Canonical and the WINE team are not affiliated with each other. WINE is a compatibility layer available for Mac, Linux & BSD.
The WINE team can be ignorant at times, but you need to remember they’ve got a lot of bugs to fix, in saying that, there is a database of applications which lists if they work or not.
In my experience, the WINE team have been very helpful towards me. Although they don’t exactly word things in simple english most of the time.
I must agree with BkS on this one … I’m not going to knock the WINE devs who do a damn fine job with limited resources.
Getting Windows applications to run without using M$ code was never going to be perfect, and is a continually moving target with new versions of all the Windows apps, and Windows itself being released.
My guess is they work on the bugs that have a lot of people asking for a fix, yet is quite easy … and the harder stuff or stuff with only a few asking will get left behind.
As I said … limited resources dictates the way forward … so they’ll fix what helps most people quickly.
Canonical on the other hand, have the resources, but just don’t appear to care.
Re replies to my provocative criticism of WineHQ’s support:
Re the limited number of Wine devs, contrast this with the Gambas developer app (including a compiler, IDE, libraries, online help) which was authored by one person (Benoït Misasini) where he has just released a new version 3 months after a major new release with this new version fixing 150 bugs & containing 120 enhancements. He also treats the issue recorders with respect - see below for some examples of the Wine staff’s attiitude.
WineHQ website is not intuitive to use e.g. recording bugs when ‘logging’ an app, recording test results for a new version of a previously ‘logged’ app, should record a bug as well as recording a test result when ‘logging’ an app (otherwise I have the feeling that their devs will never look at that app).
After ‘logging’ an app on WineHQ website, logger is flooded by automated emails from WineHQ.
Winetricks - snotty emails/comments that winetricks issues should be posted on another website e.g. when ‘logging’ details of .Net2.0SP1 not working under winetricks as well as directly under Wine.
I feel that when they confirm a Wine bug, they should publicise a target date of when it will be further investigated.
Regarding prioritisation: if it’s done by number of tests recorded, then I feel that this will inevitably lead to fixes being done mainly for games. IMO more weighting should be given to those bugs apertaining to ‘business’ apps. I’ve looked at Crossover Office & that seems like just another layer being added to Wine rather than emphasis on more business apps working under Wine.
When I’ve tried to interact with the Wine staff, I get the brushoff e.g. fixing bug 30085.
From what I’ve heard from others, Wine has a very poor reputation in businesses & academia.
OK, it’s not my job to defend WINE, and I’d agree about their website and method for bug reporting … and to a certain extent I speak from a point of ignorance (not using WINE much, so never having reported a bug), but I will say that I seem to remember 1.5.1 coming out within weeks of 1.5.0 (which granted was a developer release) so they are fixing things, and apparently quite quickly.
Crossover Office, and Cadega … IMHO leaches living off WINE … but just an opinion
I’d also agree that WINE should concentrate more on business apps than games (which seems their main focus) … but again, that’s just my opinion, as I don’t at present see Linux as a games platform (that’s for Xboxes and the like) … but I realise I’m probably in a minority there, and I’m not privy to WINE’s user base statistics.
IMHO, Businesses and Academia should (at present) be smart enough to run applications in their native OS’s, or even better find a Linux alternative … and they do, so maybe the need for WINE to support business apps could be viewed as irrelevant.
I have no doubt that the Gambas dev is doing a fine job … but I don’t see the connection, Gambas is a “single goal” project whereas WINE is having to try keep up with a moving target and many goals, I’d also suspect WINE has a LOT more users therefore a LOT more bugs reported, so getting round to all of them would be a much greater challenge.
I see WINE as what it is … an attempt to get non-native apps to work in Linux … but I have to ask … WHY ?, Gambas on the other hand is not flying “against the wind” as it were, so will not have the same problems.
Don’t get me wrong, I’m not a “supporter” of WINE, in my opinion it’s probably detracting from Linux strengths and development … why SHOULD Linux support Windows applications, lets get Linux native ones instead … Whilst Linux feels the need to be or emulate Windows it’s always going to suffer a second rate existence, and worse still, be SEEN to have an inferiority complex.
Linux has historically done extremely well in the areas where it hasn’t tried to be anything other than itself … servers, devices, etc.
[EDIT]
DISCLAIMER #1: The above was written by a fickle git whos “opinions” change on a minute by minute basis … and who was too lazy to check any facts … so please take with a “pinch of salt”
Sorry if that response seems to zig-zag a bit, having a lazy day off, so I’d not long woke up … it ended up as much a “thinking out loud” exercise as anything else
DISCLAIMER #2: Disclaimer #1 only added so I don’t feel the need to defend anything stupid that I may have said in the main body … a “get out clause” if you will
DISCLAIMER #3: Disclaimer #2 written by a complete chicken.
DISCLAIMER #4: Variable convictions may apply.
DISCLAIMER #5: All disclaimers will be considered null and void without the written consent of the form Admin … see below.
Mark,
We seem to be mainly in agreement.
One point that I should have made about Business apps: what prevents many small SMEs moving from Windows to Linux (particularly when replacing PCs) is that they have ‘legacy’ custom apps written using .Net. If Wine could be used for running these, it would help moving from Windows to Wine. Gambas should allow many Visual Basic (with more difficulty VB.Net ones) apps to be ‘converted’ from VB to Gambas.
The connection between Gambas & Wine is that Gambas dev/maintenance is being done in a professional manner whereas IMO Wine dev/maintenance is amateurish as evidenced by comments in my last posting. On a simplistic level, with the release of Gambas 3.1 at the weekend there are <20 outstanding bugs whereas AFAIK there are over 7,000 bugs in Wine. Please look at Gambas Issues webpage to see how Benoït Minisini handles bugs & enhancements and compare that to IMO the mess that WineHQ uses on their webpages…
I would like to see Android app dev being possible with Gambas. I would then not have to use Basic4android (which is inferior to Gambas as a language & its IDE & other ways). Below is part of a discussion on Gambas Mailing Lists:
On 04/09/2012 02:12 AM, John Rose wrote:
> My starter posting on this topic was misleading in that it implied that
> I wanted Gambas to dev apps on Android which would run on Android.
> That’s one possibility. However, it seems likely to me that this would
> require purchase of a high spec Android tablet to make dev not painful.
I agree. Being able to write code in BASIC+SQL on my phone is a neat
trick, but that's all it is... a trick. Even on my tablet, it's not
really a viable development environment, and probably wouldn't be even
if it had a GUI designer. I've done bug fixing on clients' web apps and
maintained their databases from my phone and tablet, but wouldn't want
to spend all day coding on either of them. If I end up ever doing
BASIC+SQL work for some reason, I'll be sshing to my phone from my
laptop to write the code, or possibly writing the code on my laptop and
using Dropbox or sftp to push it up.
What might be a nice solution would be a transpiler that would take
Gambas object code and compile it into Dalvik (Android JVM) bytecode.
When RMS suggested something similar for Gambas in general some years
ago, I thought it was a dumb idea, but in this case, it makes a lot of
sense to me.
I wouldn't have any idea where to begin, and even if I did, how to
handle GUI toolkit translation issues, how to make apps that look like
Android apps (with gesture and multitouch support) instead of desktop
apps jammed onto a tiny screen, etc. I don't think any of the commercial
options (such as Basic4Android) has addressed many of those issues
either, because they're not going to be easy to deal with. Desktop and
touch-based apps are fundamentally different (even if Microsoft and
Ubuntu would like to pretend otherwise).
Games might be an exception to this rule, but generally speaking,
creating an IDE that allows full-featured mobile and desktop apps to be
created from the same source is a really tall order.