Without running a virtual Windows session (XP, Vista, etc.) will it, or is it, be possible - most likely using Wine, Wine HQ , to upgrade the OS?

Sorry in advance for starting a new thread but I didn't see this topic raised and I'm curious.

Wirelessly posted (life goes on! yes it is tough)

Nope at the time can't be done

Telling me something can't be done doesn't help me very much. However with your experience here at the forums, judging by the number of posts you have contributed, I am willing to judge more likely than not that what you wrote is really the current state of *nix/BB support in this area. However I was hoping for, but I did not explicitly ask for (so I certainly cannot blame you for your terse answer), for a knowledge of the stumbling blocks of attempting to do this. If anyone would be so kind as to tell me what problems exist in attempting to upgrade from a *nix I would be ever so greatful.

the ONLY software that allows for an OS update has to be run on Windows. There is no Linux/Unix/Mac support at this time. The Desktop Manager software requires an installation of Windows to run. Going forward the device will be able to update OTA, but it cannot at this time.

So an emulator, like WineHQ, is simply not developed enough for all processes RIM requires to take place at an upgrade at the moment?

That would be my assumption yes. I am sure someone out there with better programming skills than I can create the emulator, or alter it, so that it *could* run, but my understanding at this time is that it cannot.

One main issue stems from the use of the USB driver for the device, there is no documentation as to the protocols used; several very well versed developers (read: kernel module maintainers) have been trying to get RIM to provide documentation; to my knowledge, nothing has been given over. Most assuredly there are some other things in the way (the more high level items on the command/response structure, for instance) that are also not released to the public; these border on intellectual property rights I bet.

Several groups and/or individuals have been working on reverse engineering the protocols used and have many things working (see the Barry suite of tools), but the process of upgrading an OS is quite a ways beyond a simple chatter to and from the device. It may happen in the future (where there's a will, there's a way) but as a non-programming nerd you're going to get nowhere by thinking just using Wine will do the job. It's far, far more complicated and out of the reach of mere mortals at this stage.

I realize the limitations, capabilities, what ever one wants to call them of Barry and I also am on the periphery of understanding the usb driver issues but it just never made sense why an emulator could never do what Windows did. I get it now. The thread was created out of an interest in understanding the current situation in upgrading the OS in Linux. I program, not very well mind you, but as is the problem with everyone these days I have no time.

In any event thank you rivviepop for shedding light on OS upgrading, as I am strictly a GNU/Linux user - the BB was a poor choice for my needs but Barry has made it at least tolerable and midpssh etc. all help to make it a worthwhile product regardless of its limitations.

thanks again

As much as i love using linux, this is the reason why i dual boot and the ONLY reason i go into windows.

Same here, on both my Linux and OS X machines ... The only reason I keep windows around is primarily because of my blackberry.

i have a windows xp machine running under vmware and use the desktop manager in there. just make sure you have Barry installed/configured.

jsntrenkler, are you saying you can do firmware upgrades with the blackberry desktop manager via xp as virtual machine? Please confirm, as if so, this is the route I will take.

Just a tought, in windows we have javaloader to do some task for blackberry. Probably we can make it works on linux? Load application, wipe etc...?

Lets remember that Wine is not an emulator but a Win API layer...

it should be possible, using the vmware usb passthrough option

I think this is true to most Linux users that dual boot or keep a vm session on hand. This is certainly the case for me. I dream every night that I will wake up to read that glorious post that some great development team save given me back that four GB of wasted partition space. A guy can dream!

Also, the only way I've seen the updates delivered is through a windows executable. For this to be useful on linux, someone has to have windows to break out and repackage the content.

I only need the BBDM for updates. I install most apps OTA and sync all content OTA with my corporate BES.

I'm in the same boat.. I have a couple of Linux machines and a Mac. No windows machines, so I just run a VM on my MBP for backup/sync and OS upgrades. Works OK, though I would much rather see actual Linux & Mac support from RIM. I won't hold my breath, though

Yeah, it works fine in VMWare.

Hi,

After having developped bjavaloader (in the barry project), I'm intend to develop bfupdate... (barry firmware update)

I have already some USB traces (get USBsnoop for Windows).

But I need a lot of USB traces to be able to write a robust application (firmware update is critical !)

Can you make USB traces and join a README with :
Blackberry product used : xxx
OS intial : xxx (before the firmware update process)
OS final : xxx (after the firmware update process)
Then publish these traces on a web site

Regards,

Nicolas

You are wrong. WINE is an emulator. It emulates the Win32 API. it is an urban myth that WINE stands for "WIne is Not an Emulator". Please google the issue before following up. The initial plans for WINE state is an emulator. Emulator's happen in SW as well as HW.

It is not "the WIN API layer" : it is something which emulates the Win API layer.

check this rileyrg -> WineHQ - Debunking Wine Myths

As Wine's name says: "Wine Is Not an Emulator": Wine does not emulate the Intel x86 processor.

An emulator is NOT only "emulating" HW.

It can also "emulate" an API.

It is NOT the Win API. It emulates the winapi.

Google some more and and find the original Wine plans. Wine is an emulator. And was from day one.

Yes, yes, it's all semantics.

here, I'll do it for you:

Read Wines history : the first NG created for it was ...

comp.emulators.ms-windows.wine

Yes, its not a full emulator in terms of what some people think of as HW emulation. But it does, in the meaning of the word, emulate what the equivalent Windows libararies would do. Rather than end up in an endless spiral, think about it and try to see my point. In the same way than a x86 emulator would read the opcode and do relevant things, Wine intercepts the win api call and "does relevant things".

The term emulation is not limited to HW.

They might have dropped the "emulator" part because of the confusion to those only partially aware of the full range of what an emulator does.

Incidentally:

(I cant post links, but google up the text to find)

"System emulators come in two basic flavors, machine architecture emulators and operating system emulators. Wine is a complete package that emulates the Windows operating system. Windows itself is not required. Wine includes its own versions of the Windows system DLLs, but you can use the native Windows versions if you prefer. Depending on the intended use, the system may require other native support software expected by your applications. "

Or visit the wine section at forums.emulator-zone.com.

You would be able to find other articles disagreeing but ALL they tend to do is repeat the mantra that "WIne is Not an Emulator". Whereas the ORIGINAL naming was indeed

WINdows Emulator.

Which makes a lot more sense if anyone were to think about how it would be named at the start of the project.

People are of course welcome to their own opinions on the matter. And there are plenty of links to people who think "emulation" is (for whatever reason) limited to x86 opcode substitutions.

To call the WINE win api layer a "compatability layer" is misleading since its more than a layer : its a rebuild, or emulation, of the Windows codebase based on the documented functionalities of the functions therein.

Well once again, check this -> FAQ - The Official Wine Wiki

I agree with you about wine being an emulator. An Emulation refers to the ability of a computer program or electronic device to imitate another program or device.
But if the wine project people want their name out of the "WINdows Emulator" business, its their right.

Sure it is.

It doesn't change the fact that it IS an emulator and started life as an emulator.

I have provided links to show this.

Wine actually does not emulate windows. It just provides API functionality same as windows. It may be implemented differently, causing issues.

In fact its name points it out... Wine Is Not Emulator. Yes, it is regressive name. ;)

Err, its not possible. End of story. And even with vmware/virtualbox with Windows I could not get it to work.

Wrong. Wine emulates the Win 32 API.

Its original name was WINdows Emulator.

They changed it because some people got confused between HW and SW emulation.

The clue is also that it originally was in the emulator newsgroups.

There is lots to google but trust me.

The term "emulate" does not mean "perfect" in any way and you are right that the WINE does not work with Desktop Manager but more surprisingly runnign real Windows under VMWare or Virtualbox still does not work for updating SW on the Storm.

Desktop Manager worked fine for me with VMware, but not VirtualBox.

That said, I never tried an OS upgrade with it -- only backups.

never will be.