Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I guess this is a question in two parts:

Does Qualcomm plan to release an emulator that runs under Linux? Or is anyone else working on such a project?

And if not, would anyone find such an application useful?

I do most of my development under Linux, and find it annoying to boot into Windows to experiment with Brew[0]. The basics do not appear difficult (basically creating a refcounted base class with some wrappered function calls) so it seems strange if no one has tried it.

Yours looking for a new project to sink his teeth into :)

Steev
[0] I'm just playing with the tech in an attempt to get a job, amongst other things :)

I'd be interested in a portable Emulator, but I do my development on Mac OS X, not Linux.
I'll help with such a project if you decide to start one. I'd prefer it be Open Source, but would consider other options.
SDL or WxWindows would be good choices for a platform to implement this on.

I'd be interested in a portable Emulator, but I do my development on Mac OS X, not Linux.
I'll help with such a project if you decide to start one. I'd prefer it be Open Source, but would consider other options.
SDL or WxWindows would be good choices for a platform to implement this on.

Well, it would certainly be Open Source (possibly LGPL, as opposed to GPL). My current API leanings would be SDL (I'm moderately proficient in it, and it has better bitmap graphic support, as I understand it, than wxWindows). However, I'm a cross platform junkie, so expect an abstract class called CBrewGraphics :) if you prefer wx, or want native gfx code.
I have doodled a basic architecture, so after Christmas (when my current todo list is exhausted) I'll should be able to start some heavy duty coding
:cool:

Well, it would certainly be Open Source (possibly LGPL, as opposed to GPL). My current API leanings would be SDL (I'm moderately proficient in it, and it has better bitmap graphic support, as I understand it, than wxWindows). However, I'm a cross platform junkie, so expect an abstract class called CBrewGraphics :) if you prefer wx, or want native gfx code.
I have doodled a basic architecture, so after Christmas (when my current todo list is exhausted) I'll should be able to start some heavy duty coding
:cool:

Are you suggesting you plan to write a BREW emulator for Linux? Good luck, man. Since there's virtually no information available about the inner workings of Brew I think are you wasting your time at best. How can you emulate something you no nothing about, other than maybe the screen dimensions and color depth?

Are you suggesting you plan to write a BREW emulator for Linux? Good luck, man. Since there's virtually no information available about the inner workings of Brew I think are you wasting your time at best. How can you emulate something you no nothing about, other than maybe the screen dimensions and color depth?

Yes, I am planning an emulator. Naturally, how much of the emulator gets written will vary depending on the interest shown, and how much I need for my experiments.
Basically, the first pass (as I see it) invoves writing a means of wrapping SDL code so that it can be called through interface pointers. This is not actually that hard, since your only need to instaniate classes and fill in function pointers which get returned to the application. An application which is, in essense just an object file.
The phone component then sits along side to send other messages (phone lid open/close, eg). All the phone O/S needs (for most purposes) the ability to start/stop applications. Later versions may include socket code to support the networking/sms/phone components.
Does these sound more reasonable to you, or have I overlooked something fundamental?

Yes, I am planning an emulator. Naturally, how much of the emulator gets written will vary depending on the interest shown, and how much I need for my experiments.
Basically, the first pass (as I see it) invoves writing a means of wrapping SDL code so that it can be called through interface pointers. This is not actually that hard, since your only need to instaniate classes and fill in function pointers which get returned to the application. An application which is, in essense just an object file.
The phone component then sits along side to send other messages (phone lid open/close, eg). All the phone O/S needs (for most purposes) the ability to start/stop applications. Later versions may include socket code to support the networking/sms/phone components.
Does these sound more reasonable to you, or have I overlooked something fundamental?

Steev,
I have the feeling you are overlooking some of the most important issues that I am not sure how you plan to resolve these. For an emulator to be of any use it needs to be at least somewhat mimick the behavior and capabilities of the original piece of equipment. And that goes way beyond just displaying a few bitmaps.
but your problems start right there already. How do you plan to include BCI support? The BCI image format is not publicly documented and I have no idea how you would create an interface to handle BCIs. The same is essentially true for the pure voice format.
Then, how would you know how to properly emulate things such as the idiosyncrasies of, say the ISOUNDPLAYER API, or something like the ICIPHER, IRSA and many other APIs without having proper documentation on their actual implementation.
I don't want to discourage your project, but I am not sure if you are aware of the scope of your undertaking if you want your emulator to be of any value.
Add to that that the emulator should adequately mimick each handset's flaws, firmware bugs and other issues, and I believe you will be just straight out of luck.

Steev,
I have the feeling you are overlooking some of the most important issues that I am not sure how you plan to resolve these. For an emulator to be of any use it needs to be at least somewhat mimick the behavior and capabilities of the original piece of equipment. And that goes way beyond just displaying a few bitmaps.
but your problems start right there already. How do you plan to include BCI support? The BCI image format is not publicly documented and I have no idea how you would create an interface to handle BCIs. The same is essentially true for the pure voice format.
Then, how would you know how to properly emulate things such as the idiosyncrasies of, say the ISOUNDPLAYER API, or something like the ICIPHER, IRSA and many other APIs without having proper documentation on their actual implementation.
I don't want to discourage your project, but I am not sure if you are aware of the scope of your undertaking if you want your emulator to be of any value.
Add to that that the emulator should adequately mimick each handset's flaws, firmware bugs and other issues, and I believe you will be just straight out of luck.

Have you tried to run the emulator under WINE?
-Aaron

Have you tried to run the emulator under WINE?
-Aaron

SDL is fine with me. I've ported a couple games that used SDL to the Mac already so I'm somewhat familiar with it.
I agree wholeheartedly with Dragon that this is not going to be a simple project. It will probably be several years before an Open Source emulator approaches the completeness of the official Qualcomm version.
However, I think it can still be useful even in the early stages, especially to applications that don't use the majority of the Brew APIs. My current Brew game, for example, doesn't use BCI, and barely uses ISHELL and IFILE. A quick grep through the code reveals that we use 63 different API calls, most of which are trivial to implement.
Finally, I think there are some things we could do much better than the current emulator does, which could give people a reason to use our emulator even if it otherwise isn't as full featured. The current emulator doesn't do a very good job emulating the speed of the actual devices. We could also do a better job mimicing known bugs in the devices.
And the nice thing about it being an Open Source project is that we wouldn't need to do it all ourselves. Things like BCI support and specific devices might be added by folks who find it otherwise useful but need that support.
Finally, while WINE might work for Linux, it won't work for Mac OS X. I have run the emulator under Virtual PC on Mac OS X, but Virtual PC doesn't run on my G5, and probably won't until mid year. Plus, it's just annoying to have to fire up a different operating system to do something that's basic to your workflow.

SDL is fine with me. I've ported a couple games that used SDL to the Mac already so I'm somewhat familiar with it.
I agree wholeheartedly with Dragon that this is not going to be a simple project. It will probably be several years before an Open Source emulator approaches the completeness of the official Qualcomm version.
However, I think it can still be useful even in the early stages, especially to applications that don't use the majority of the Brew APIs. My current Brew game, for example, doesn't use BCI, and barely uses ISHELL and IFILE. A quick grep through the code reveals that we use 63 different API calls, most of which are trivial to implement.
Finally, I think there are some things we could do much better than the current emulator does, which could give people a reason to use our emulator even if it otherwise isn't as full featured. The current emulator doesn't do a very good job emulating the speed of the actual devices. We could also do a better job mimicing known bugs in the devices.
And the nice thing about it being an Open Source project is that we wouldn't need to do it all ourselves. Things like BCI support and specific devices might be added by folks who find it otherwise useful but need that support.
Finally, while WINE might work for Linux, it won't work for Mac OS X. I have run the emulator under Virtual PC on Mac OS X, but Virtual PC doesn't run on my G5, and probably won't until mid year. Plus, it's just annoying to have to fire up a different operating system to do something that's basic to your workflow.

Quote:Originally posted by aisaksen
Have you tried to run the emulator under WINE?
-Aaron
I have succeeded in getting old versions of the emulator working with some of my DLLs. However, for me, running the emulator under Linux is not the issue, so much as being able to develop under Linux.
To manage the latter with WINE would mean DevStudio (or similar) and its debugger would have to run under it. If I were employing that amount of effort I'd probably look to VMWare, before WINE.

Quote:Originally posted by aisaksen
Have you tried to run the emulator under WINE?
-Aaron
I have succeeded in getting old versions of the emulator working with some of my DLLs. However, for me, running the emulator under Linux is not the issue, so much as being able to develop under Linux.
To manage the latter with WINE would mean DevStudio (or similar) and its debugger would have to run under it. If I were employing that amount of effort I'd probably look to VMWare, before WINE.

Something I'd love to see in an open source emulator are hooks for automated testing. Scripting tools for capturing screen shots, memory dumps, logging and sending events, etc.
As for Dragon's suggestion that the emulator "should adequately mimick each handset's flaws, firmware bugs and other issues" the current Qualcomm emulator doesn't, so it might not be that important a goal. Even the sound APIs in the Qualcomm version are not completely implemented (even though not that difficult).
-Aaron

Something I'd love to see in an open source emulator are hooks for automated testing. Scripting tools for capturing screen shots, memory dumps, logging and sending events, etc.
As for Dragon's suggestion that the emulator "should adequately mimick each handset's flaws, firmware bugs and other issues" the current Qualcomm emulator doesn't, so it might not be that important a goal. Even the sound APIs in the Qualcomm version are not completely implemented (even though not that difficult).
-Aaron

The qualcomm simulator does have hooks for automated testing.
you can trace memory, log it, simulate events etc.
Personally i think YAS would be a waste of time, except for the .01% of non windows based developers out there. Plus i bet qualcomm might have a thing or two to say about it :)
A real emulator would be a lot better, and then you don't have to figure out the formats etc.

The qualcomm simulator does have hooks for automated testing.
you can trace memory, log it, simulate events etc.
Personally i think YAS would be a waste of time, except for the .01% of non windows based developers out there. Plus i bet qualcomm might have a thing or two to say about it :)
A real emulator would be a lot better, and then you don't have to figure out the formats etc.

The emulator has some of these feature, but they are not as full featured as they could be. For example, you can't get the output of DBGPRINTF messages in the Grinder perl scripts, so you can't programatically control what keys you send based on the output message.
I am not so sure that it would be a waste of time to have an open source emulator. It is useful for Windows developers also, and having some competition would likely improve the Qualcomm emulator. If someone wants to build one on their own time/dollar, I wouldn't discourage it.
-Aaron

The emulator has some of these feature, but they are not as full featured as they could be. For example, you can't get the output of DBGPRINTF messages in the Grinder perl scripts, so you can't programatically control what keys you send based on the output message.
I am not so sure that it would be a waste of time to have an open source emulator. It is useful for Windows developers also, and having some competition would likely improve the Qualcomm emulator. If someone wants to build one on their own time/dollar, I wouldn't discourage it.
-Aaron

Maybe you can't but i can assure you, others can. Sure there are things the current simulator could use, but its best to go straight for the phone most of the time anyway.
I think it'd be not that useful if its just a copy of the brew simulator thats current (beyond the tiny amount of non windows developers), it'd be behind too, and like i said i betcha qualcomm would come knocking before you got it finished. Plus unless you want the inferior performance of gcc you'd need a port of ADS to make it useful as a devkit, plus all the other tools.
Now an emulator, would be a whole different kettle of fish sticks, however they don't like you having the firmware, and again they'd come knocking, but legally they'd have less to stand on, but they have other ways of punishing you once they locate you, hopefully they'd get some common sense and buy it from you, but while we are wishing for the highly unlikely, i'll ask for hardware framebuffers , dropping all the GUI crap" they" develop and source for the toolsets, too.

Maybe you can't but i can assure you, others can. Sure there are things the current simulator could use, but its best to go straight for the phone most of the time anyway.
I think it'd be not that useful if its just a copy of the brew simulator thats current (beyond the tiny amount of non windows developers), it'd be behind too, and like i said i betcha qualcomm would come knocking before you got it finished. Plus unless you want the inferior performance of gcc you'd need a port of ADS to make it useful as a devkit, plus all the other tools.
Now an emulator, would be a whole different kettle of fish sticks, however they don't like you having the firmware, and again they'd come knocking, but legally they'd have less to stand on, but they have other ways of punishing you once they locate you, hopefully they'd get some common sense and buy it from you, but while we are wishing for the highly unlikely, i'll ask for hardware framebuffers , dropping all the GUI crap" they" develop and source for the toolsets, too.

Quote:Originally posted by Steev
And if not, would anyone find such an application useful?
I would most certainly find it useful. I've been using Linux and Unix environments for 10 years, and this WindowsXP laptop I've got for doing my BREW development can be quite frustrating. (I hadn't used Windows on a regular basis since Win95 back in 1998, and even then I preferred MacOS7 and Solaris :^) )
A dose of Mozilla, The Gimp, Cygwin, OpenOffice.org and PuTTY helped in the usability area (except I still only have the one desktop... blah!), but for development, I'd really prefer a Unix base, all the way.
If anyone from Qualcomm's listening, consider this my vote! :^)

Quote:Originally posted by Steev
And if not, would anyone find such an application useful?
I would most certainly find it useful. I've been using Linux and Unix environments for 10 years, and this WindowsXP laptop I've got for doing my BREW development can be quite frustrating. (I hadn't used Windows on a regular basis since Win95 back in 1998, and even then I preferred MacOS7 and Solaris :^) )
A dose of Mozilla, The Gimp, Cygwin, OpenOffice.org and PuTTY helped in the usability area (except I still only have the one desktop... blah!), but for development, I'd really prefer a Unix base, all the way.
If anyone from Qualcomm's listening, consider this my vote! :^)

Quote:Originally posted by ezavada
SDL or WxWindows would be good choices for a platform to implement this on.
I've done a dozen or so games in SDL, and they've been ported to everything from the Sega Dreamcast to QNX to PDAs. I can vouche for its usefulness. :^)
I've never used it, but have also heard good things about wxWindows. I like the idea that it uses the underlying environment's native GUI. (Gimp for Windows, which is GTK+ based, seems a little alien on this XP box. Though I'm obviously used to it from 5+ years using Gimp under Linux...)

Quote:Originally posted by ezavada
SDL or WxWindows would be good choices for a platform to implement this on.
I've done a dozen or so games in SDL, and they've been ported to everything from the Sega Dreamcast to QNX to PDAs. I can vouche for its usefulness. :^)
I've never used it, but have also heard good things about wxWindows. I like the idea that it uses the underlying environment's native GUI. (Gimp for Windows, which is GTK+ based, seems a little alien on this XP box. Though I'm obviously used to it from 5+ years using Gimp under Linux...)

people interested, please vote for thread http://brewforums.qualcomm.com/showthread.php?s=&threadid=3109
and lets see if with enough interest shown, qualcomm releases a portable emulator

people interested, please vote for thread http://brewforums.qualcomm.com/showthread.php?s=&threadid=3109
and lets see if with enough interest shown, qualcomm releases a portable emulator

Nice idea, but i think (unfortunaly) few ppl from qualcomm will read this :(
Btw an opensource version (eg on sourceforge) would be so great, but i cannot even think they will ever release something like that..
/kUfa

Nice idea, but i think (unfortunaly) few ppl from qualcomm will read this :(
Btw an opensource version (eg on sourceforge) would be so great, but i cannot even think they will ever release something like that..
/kUfa

well, if enough people show interest here, i can start sending them every post :)

well, if enough people show interest here, i can start sending them every post :)

BTW, i already sent them e-mails about that
i'd suggest everybody interested in doing the same also

BTW, i already sent them e-mails about that
i'd suggest everybody interested in doing the same also

Tellarin,
I think you have to start coming back to reality one of these days. Just becasue you and maybe a few other people *want* them to make their emulator open-spource does not mean they will. In fact I don't think they will even take you seriously. But apart from that I know that Qualcomm's company policies would never allow them to go such a route, no matter how much pressure you think you could put on them. It's like asking Microsoft to make an open-source or Macintsoh version of Visual Studio. Do you see the paradox in that? I hope...

Tellarin,
I think you have to start coming back to reality one of these days. Just becasue you and maybe a few other people *want* them to make their emulator open-spource does not mean they will. In fact I don't think they will even take you seriously. But apart from that I know that Qualcomm's company policies would never allow them to go such a route, no matter how much pressure you think you could put on them. It's like asking Microsoft to make an open-source or Macintsoh version of Visual Studio. Do you see the paradox in that? I hope...

Dragon,
i agree with you, they will never do that. A good proof is the way they "support" gcc hehe ;)
But your example is maybe not appropriate. They are not making any money from the tools. They are not selling them, but they are making money when developers submit applications, and when those one are bought. Microsoft sells VisualStudio, Qualcomm does not sell the simulator.
And "open source tools" are common: you can buy level editors etc and you will of course receive the source code. But here, for security reasons (among many others) it's impossible. An opensource (or even only unix, mac..) version of the emulator would be "great", but what can we do with it? Will anyone spend several hours to make a port? Will your phone be supported under unix? etc..
/kUfa

Dragon,
i agree with you, they will never do that. A good proof is the way they "support" gcc hehe ;)
But your example is maybe not appropriate. They are not making any money from the tools. They are not selling them, but they are making money when developers submit applications, and when those one are bought. Microsoft sells VisualStudio, Qualcomm does not sell the simulator.
And "open source tools" are common: you can buy level editors etc and you will of course receive the source code. But here, for security reasons (among many others) it's impossible. An opensource (or even only unix, mac..) version of the emulator would be "great", but what can we do with it? Will anyone spend several hours to make a port? Will your phone be supported under unix? etc..
/kUfa

kUfa, dragons point is valid, lets compare similar things, EVC for instance, MS give that away for free, yet theres no source available.
Personally I don't want qualcomm to release the same tools for other OS's since their tools and tech support is bad enough with just one OS, its easier to move the tiny amount of non windows developers to windows ( as again you'll still need all the other tools to develop not just the emulator)
I'd rather have them improve the current SDK and Brew OS than make an OSX version, the needs of the many outweigh the needs of the 1 ;)

kUfa, dragons point is valid, lets compare similar things, EVC for instance, MS give that away for free, yet theres no source available.
Personally I don't want qualcomm to release the same tools for other OS's since their tools and tech support is bad enough with just one OS, its easier to move the tiny amount of non windows developers to windows ( as again you'll still need all the other tools to develop not just the emulator)
I'd rather have them improve the current SDK and Brew OS than make an OSX version, the needs of the many outweigh the needs of the 1 ;)

Yes, I agree, my example may not have been very good. I was just trying to show the *absurdity* of the hope... :)

Yes, I agree, my example may not have been very good. I was just trying to show the *absurdity* of the hope... :)

As M2M (Machine to Machine) becomes more popular, supporting Linux is going to be more important. Kufa's point that the tools are free is an excellent point. Also, the community is small enough that the improvements/bug fixes that we would make to the emulator would probably be worth it.
However, I do agree with Dragon that is is highly unlikely that Qualcomm would invest money to do the port, because the Emulator is definitely a WIN32 app. For example, a lot the sound functions, BMP drawing functions, are just wrappers around WIN32 calls. And when a WIN32 call doesn't exist, the emulator just doesn't implement the function.
-Aaron

As M2M (Machine to Machine) becomes more popular, supporting Linux is going to be more important. Kufa's point that the tools are free is an excellent point. Also, the community is small enough that the improvements/bug fixes that we would make to the emulator would probably be worth it.
However, I do agree with Dragon that is is highly unlikely that Qualcomm would invest money to do the port, because the Emulator is definitely a WIN32 app. For example, a lot the sound functions, BMP drawing functions, are just wrappers around WIN32 calls. And when a WIN32 call doesn't exist, the emulator just doesn't implement the function.
-Aaron

Dragon,
i think it is a good idea to have open source tools, but that is not what i am proposing here
what i said is that i would like to have the development tools available in other platforms, specially the emulator
and that it would not be difficult at all for Qualcomm to provide such tools

Dragon,
i think it is a good idea to have open source tools, but that is not what i am proposing here
what i said is that i would like to have the development tools available in other platforms, specially the emulator
and that it would not be difficult at all for Qualcomm to provide such tools

And that's where you are sorely mistaken...
Ultimately Charlie's comments are the most succinct. Qualcomm is having a hard time creating decent tools on Windows only. They are not even maintained at all and we have to live with bugs, typically, until a new Brew SDK comes out to surplant the old tools, only to find and deal with the new bugs in those versions.
I do believe Qualcomm could really use a decent internal or external tools group but from everything I've heard and seen it's just not going to happen. If you take the handful of existing people working on the Brew tools and put them through the wrangler to also support Linux and OS/X or whatnot, you know that in the end, all tools will suffer from it across the board, and right now they're clearly not good enough to allow for any more degradation.

And that's where you are sorely mistaken...
Ultimately Charlie's comments are the most succinct. Qualcomm is having a hard time creating decent tools on Windows only. They are not even maintained at all and we have to live with bugs, typically, until a new Brew SDK comes out to surplant the old tools, only to find and deal with the new bugs in those versions.
I do believe Qualcomm could really use a decent internal or external tools group but from everything I've heard and seen it's just not going to happen. If you take the handful of existing people working on the Brew tools and put them through the wrangler to also support Linux and OS/X or whatnot, you know that in the end, all tools will suffer from it across the board, and right now they're clearly not good enough to allow for any more degradation.

Opening the source to the emulator would exactly solve the problem of Qualcomm not spending enough effort on bugs/development.
Then the developers, who care the most about it, would do the fixes for free, costing Qualcomm nothing. And, Qualcomm gets a more stable emulator which potentially attracts more developers (or turns away less).

Opening the source to the emulator would exactly solve the problem of Qualcomm not spending enough effort on bugs/development.
Then the developers, who care the most about it, would do the fixes for free, costing Qualcomm nothing. And, Qualcomm gets a more stable emulator which potentially attracts more developers (or turns away less).

regarding the current emulator being only wrappers over windows calls, it would not be that for Qualcomm to change that and really implement the calls, or better, to use some other layer of software under the emulator on other platforms
howere i might agree with charliex, that it'd be a great idea to have them improve the current SDK, than to spend a lot of effort on ports
and don't subestimate the number of people that use unix for development, they might not be focused on producing software for cellphones using BREW, but there are lots of companies with unix (*nix) development environments; and the number is growing with small ones working with Linux

regarding the current emulator being only wrappers over windows calls, it would not be that for Qualcomm to change that and really implement the calls, or better, to use some other layer of software under the emulator on other platforms
howere i might agree with charliex, that it'd be a great idea to have them improve the current SDK, than to spend a lot of effort on ports
and don't subestimate the number of people that use unix for development, they might not be focused on producing software for cellphones using BREW, but there are lots of companies with unix (*nix) development environments; and the number is growing with small ones working with Linux

of course, someone at Qualcomm has to manage the open source project, and that would distract from the core task of supporting current developers.

of course, someone at Qualcomm has to manage the open source project, and that would distract from the core task of supporting current developers.

Dragon,
Qualcomm is not having a hard time creating decent tools on windows, they just don't seem to care too much
if they don't care about providing a good development environment for developers, that's another problem
the problem is not the number of platforms supported, although (as i said) i agree that "supporting" other platforms would spread the little effort they make today to provide the SDK and that the current tools can't stand any more degradation.

Dragon,
Qualcomm is not having a hard time creating decent tools on windows, they just don't seem to care too much
if they don't care about providing a good development environment for developers, that's another problem
the problem is not the number of platforms supported, although (as i said) i agree that "supporting" other platforms would spread the little effort they make today to provide the SDK and that the current tools can't stand any more degradation.

aisaksen,
Of course it would be great to have tool open-source and, of course, there is a good chance they would get significantly better as a resutl of that. No one's arguing that. That however doesn't change the fact that Qualcomm is not in the business of creating open-source tool communities and that their corporate strategy is going in an entirely different direction.
Tellarin,
I'll say it again, ANYTHING that takes time away from the current tools development would be detrimental to the majority of the Brew developer community, because the tools are about as bad as tools come and if they get any worse - even a tiny little bit - we're doomed because then we're seeing the day when we REALLY can't even connect to our phones anymore, or when you can't build BAR files any longer, or whatnot. The windowed 3.0 BAR editor is already at the point that it has become practically ununusable with all its bugs, quirks and misguided UI.

aisaksen,
Of course it would be great to have tool open-source and, of course, there is a good chance they would get significantly better as a resutl of that. No one's arguing that. That however doesn't change the fact that Qualcomm is not in the business of creating open-source tool communities and that their corporate strategy is going in an entirely different direction.
Tellarin,
I'll say it again, ANYTHING that takes time away from the current tools development would be detrimental to the majority of the Brew developer community, because the tools are about as bad as tools come and if they get any worse - even a tiny little bit - we're doomed because then we're seeing the day when we REALLY can't even connect to our phones anymore, or when you can't build BAR files any longer, or whatnot. The windowed 3.0 BAR editor is already at the point that it has become practically ununusable with all its bugs, quirks and misguided UI.

I would not go so far to say that Qualcomm does not care. There is just a finite amount of resources they can throw at BREW while its in its early stages.

I would not go so far to say that Qualcomm does not care. There is just a finite amount of resources they can throw at BREW while its in its early stages.

Well, brew is not the only business of Qualcomm. And if everything is ok for them atm, i do not see why they would want to change something: i dont think they want to restructure the way they develop, and they probably want to keep the full control of what's going on..
/kUfa

Well, brew is not the only business of Qualcomm. And if everything is ok for them atm, i do not see why they would want to change something: i dont think they want to restructure the way they develop, and they probably want to keep the full control of what's going on..
/kUfa

The current toolset provided by qualcom is woefully inadequate, it took them forever to put in some very simple things like sound, and its really badly implemented, as are a lot of other things.
We should have things like device debugging, an emulator rather than an a simulator, better memory tracking tools, code tracing etc
We should not be relying on a win32 app thats running inside another windows app pretending to be a poor mans version of an ARM based phone, its not rocket science, there are many ARM cores availble, with a memory map and access to the firmware a real emulator would be fairly easy to write than the current win32 based simulator,since ARM themsevles have the core, and it does work, actually simulating the hardware is a lot simpler than recoding the API and OS to run on another OS, plus its a lot more useful. But its looking like the current win32 is here to stay.
The bottom line for qualcomm is how much revenue will be created if they ported their tools to another OS, or open sourced, the answer is probably, less than they do now.
I don't underestimate how many people use linux for develooping brew, since the simulator is only available on windows, then its pretty obvious how many are using linux for that.
The compiler is only available on windows and solaris, gcc isn't very widely used for brew development, and none of the other tools are ported over to linux.
Most people using solaris only use the arm compiler to generate mod's since they don't own the ADS compiler, and the publishers supply them.
I think open source / linux enthusiasts/zealots tend to over estimate its worth, half the time they just want to source to tinker with, which in itself isn't a bad thing, however the rest of us want to ship. I'm not saying unix is useless, far from it, but I don't thing theres a good enough reason to move over, its open source, or unix, for open source/unix sake.
Until ARM ADS appears on OSX or linux etc, i still don't see the value of porting the emulator, gcc is a very poor second, especially against the latest ADS compiler, but you can just about use it, for a lot of games its perfectly viable.
Then there are all the support tools, which are all written in MFC, not an easy undertaking to rewrite, and again wheres the benefit to qualcomm.
I don't see anyone providing any real reasons to move over the whole SDK to linux, other than a few people want to use another OS, etc,.
Will it generate more revenue for us, qualcomm, will it make the development process any easier ? Again , no i don't believe so, it'll just add burden to an already over taxed SDK group.
More tools doing a better job of simulating the real phone, or JTAG made available to more phones or documenting the existing on phone debug support to and improving the current applications so they are more reliable, that will generate more revenue for everyone involved from verizon, qualcomm and us.
But at the end of the day, i'd just be happier if they fixed the bugs in the OS, i can work around the bad developer tools, there are very few systems that have really good dev tools, and we've always worked around them, but but bad target OS or bad target hardware is another story.
I'm pretty sure the qualcomm engineering group is working hard, and have more than enough work piled up without any more being added. The unfortunate choice in their SDK design was made early in the whole process, but now they are stuck with it, they might revamp it and bring out an easily maintainable open source effort, but i've yet to see any hardware developer do such a thing.

The current toolset provided by qualcom is woefully inadequate, it took them forever to put in some very simple things like sound, and its really badly implemented, as are a lot of other things.
We should have things like device debugging, an emulator rather than an a simulator, better memory tracking tools, code tracing etc
We should not be relying on a win32 app thats running inside another windows app pretending to be a poor mans version of an ARM based phone, its not rocket science, there are many ARM cores availble, with a memory map and access to the firmware a real emulator would be fairly easy to write than the current win32 based simulator,since ARM themsevles have the core, and it does work, actually simulating the hardware is a lot simpler than recoding the API and OS to run on another OS, plus its a lot more useful. But its looking like the current win32 is here to stay.
The bottom line for qualcomm is how much revenue will be created if they ported their tools to another OS, or open sourced, the answer is probably, less than they do now.
I don't underestimate how many people use linux for develooping brew, since the simulator is only available on windows, then its pretty obvious how many are using linux for that.
The compiler is only available on windows and solaris, gcc isn't very widely used for brew development, and none of the other tools are ported over to linux.
Most people using solaris only use the arm compiler to generate mod's since they don't own the ADS compiler, and the publishers supply them.
I think open source / linux enthusiasts/zealots tend to over estimate its worth, half the time they just want to source to tinker with, which in itself isn't a bad thing, however the rest of us want to ship. I'm not saying unix is useless, far from it, but I don't thing theres a good enough reason to move over, its open source, or unix, for open source/unix sake.
Until ARM ADS appears on OSX or linux etc, i still don't see the value of porting the emulator, gcc is a very poor second, especially against the latest ADS compiler, but you can just about use it, for a lot of games its perfectly viable.
Then there are all the support tools, which are all written in MFC, not an easy undertaking to rewrite, and again wheres the benefit to qualcomm.
I don't see anyone providing any real reasons to move over the whole SDK to linux, other than a few people want to use another OS, etc,.
Will it generate more revenue for us, qualcomm, will it make the development process any easier ? Again , no i don't believe so, it'll just add burden to an already over taxed SDK group.
More tools doing a better job of simulating the real phone, or JTAG made available to more phones or documenting the existing on phone debug support to and improving the current applications so they are more reliable, that will generate more revenue for everyone involved from verizon, qualcomm and us.
But at the end of the day, i'd just be happier if they fixed the bugs in the OS, i can work around the bad developer tools, there are very few systems that have really good dev tools, and we've always worked around them, but but bad target OS or bad target hardware is another story.
I'm pretty sure the qualcomm engineering group is working hard, and have more than enough work piled up without any more being added. The unfortunate choice in their SDK design was made early in the whole process, but now they are stuck with it, they might revamp it and bring out an easily maintainable open source effort, but i've yet to see any hardware developer do such a thing.

Quote:Originally posted by aisaksen
However, I do agree with Dragon that is is highly unlikely that Qualcomm would invest money to do the port, because the Emulator is definitely a WIN32 app. For example, a lot the sound functions, BMP drawing functions, are just wrappers around WIN32 calls.
Hehe - Sounds like SDL. I tell SDL to draw a bitmap, and it does it. It does it using Win32 API under Win32. It does it using Xlib under X-Window. It does it using Qt API on the Sharp Zaurus PDA. It does it with MacOS and OSX APIs under MacOS and MacOSX. :)
Another poster's comment that, at least for games, the set of API calls they use is actually very small, seems true for me as well.
I'm getting very tempted to look into making a 'wrapper' that lets me use SDL in place of the BREW calls. Then I can develop on my Linux box all I want. When I'm ready to test on the phone (which I only do after quite a bit of coding and testing under the simulator), I can move back to WinXP for a few minutes.
;)

Quote:Originally posted by aisaksen
However, I do agree with Dragon that is is highly unlikely that Qualcomm would invest money to do the port, because the Emulator is definitely a WIN32 app. For example, a lot the sound functions, BMP drawing functions, are just wrappers around WIN32 calls.
Hehe - Sounds like SDL. I tell SDL to draw a bitmap, and it does it. It does it using Win32 API under Win32. It does it using Xlib under X-Window. It does it using Qt API on the Sharp Zaurus PDA. It does it with MacOS and OSX APIs under MacOS and MacOSX. :)
Another poster's comment that, at least for games, the set of API calls they use is actually very small, seems true for me as well.
I'm getting very tempted to look into making a 'wrapper' that lets me use SDL in place of the BREW calls. Then I can develop on my Linux box all I want. When I'm ready to test on the phone (which I only do after quite a bit of coding and testing under the simulator), I can move back to WinXP for a few minutes.
;)

Dragon,
as i said in my last post
i agree that "supporting" other platforms now would spread the little effort they make today to provide the SDK
and ALL,
regarding the rest of the discussion i mostly agree with charliex (but not necessarily with the way he expressed himself in some parts of his post)
except that i really think that adding support for development in other platforms would only add more developers to BREW
now might not be the moment, but i think it should be done (as i think Qualcomm should pay more attention to the developers, it has resources to do that)
but enough, for me it's end of the discussion

Dragon,
as i said in my last post
i agree that "supporting" other platforms now would spread the little effort they make today to provide the SDK
and ALL,
regarding the rest of the discussion i mostly agree with charliex (but not necessarily with the way he expressed himself in some parts of his post)
except that i really think that adding support for development in other platforms would only add more developers to BREW
now might not be the moment, but i think it should be done (as i think Qualcomm should pay more attention to the developers, it has resources to do that)
but enough, for me it's end of the discussion

I think in essence we all agree on the same thing, which is...
In a perfect world it would be great, if...
but we all know it's not going to happen.

I think in essence we all agree on the same thing, which is...
In a perfect world it would be great, if...
but we all know it's not going to happen.

I agree Qualcomm is unlikely to release an Open Source 'emulator' any time soon. Is there any legal reason that we, in the community, couldn't come up with something of our own, though?
I realize it will be a tall order, but this isn't one of this projects that can't start small and grow.
For extremely basic apps (e.g., simple, non-networked games), I imagine we could have a suitable 'wrapper' within a week or two.

I agree Qualcomm is unlikely to release an Open Source 'emulator' any time soon. Is there any legal reason that we, in the community, couldn't come up with something of our own, though?
I realize it will be a tall order, but this isn't one of this projects that can't start small and grow.
For extremely basic apps (e.g., simple, non-networked games), I imagine we could have a suitable 'wrapper' within a week or two.

you'd have to reverse engineer some of their formats, which if you read the license agreement for the SDK is strictly prohibited, plus it can be tricky. Plus whos got time ;)
technically someone who'd never seen the SDK or signed the agreements could be told the specifications required, the clean room approach, but even that these days is very dubious at best.
Qualcomm might be happy to allow it, you never know, but typically they launch on it with full force of their lawyers, citing trade secrets and so on, unfortunately these days common sense and business aren't always able to co-exist, it'd be really dififuclt getting an official statement from them i bet (unless it was one saying no).
Writing an emulator vs a simulator is legally more sound, but you'd need firmware, however you can still legally distribute it without firmware etc.
bill kendrick has a good approach from prototyping, just abstract it, it works well if its used carefully, theres an awful lot you can do with sdl you can't on a phone, and with poor technical direction you can end up with a worthless prototype, i've seen it many times. I say this for completeness, nothing implied about anyone in particular.
Quote:
(but not necessarily with the way he expressed himself in some parts of his post)
I'm not quite sure what that is meant to imply ;)

you'd have to reverse engineer some of their formats, which if you read the license agreement for the SDK is strictly prohibited, plus it can be tricky. Plus whos got time ;)
technically someone who'd never seen the SDK or signed the agreements could be told the specifications required, the clean room approach, but even that these days is very dubious at best.
Qualcomm might be happy to allow it, you never know, but typically they launch on it with full force of their lawyers, citing trade secrets and so on, unfortunately these days common sense and business aren't always able to co-exist, it'd be really dififuclt getting an official statement from them i bet (unless it was one saying no).
Writing an emulator vs a simulator is legally more sound, but you'd need firmware, however you can still legally distribute it without firmware etc.
bill kendrick has a good approach from prototyping, just abstract it, it works well if its used carefully, theres an awful lot you can do with sdl you can't on a phone, and with poor technical direction you can end up with a worthless prototype, i've seen it many times. I say this for completeness, nothing implied about anyone in particular.
Quote:
(but not necessarily with the way he expressed himself in some parts of his post)
I'm not quite sure what that is meant to imply ;)

Well, true I probably can't just got out and say "Here's some (L)GPL'd code that can open and read a BCI format image." or "Here's a program to load resources from a Quallcomm BREW 'BAR" resource file."
No reason you can't fake it, though. From an API point of view, I just ask the library "Hey, get me resource such-n-such from 'foo.bar'". I don't really care, when doing initial development, whether it's an ACTUAL ".bar" file, or somethign else.
This can bite one in the butt down the road, but it seems the current, official BREW stuff (at least that I've used) can have the same problem.
See my recent complaint about vibration working oddly on hardware. The Windows 'emulator' didn't help me one bit with respects to that, so it doesn't win any points there. ;)
Obviously, there's a place for the 'official' emulator (simulator), and nothing will ever replace a stack of 30 different models of phones to test on. ;) But for rapid development, all I worry about is C compiler, and something that does what the API should be doing on the phone, so I can see if it looks right and works well.
I'm willing to put my keystrokes where my mouth is and help out, if people are actually interested in creating some 'wrapper' API, especially if it's around SDL, since I know it so well. (And that, in turn, welcomes our MacOSX, BeOS, Un*x, and Windows friends.)

Well, true I probably can't just got out and say "Here's some (L)GPL'd code that can open and read a BCI format image." or "Here's a program to load resources from a Quallcomm BREW 'BAR" resource file."
No reason you can't fake it, though. From an API point of view, I just ask the library "Hey, get me resource such-n-such from 'foo.bar'". I don't really care, when doing initial development, whether it's an ACTUAL ".bar" file, or somethign else.
This can bite one in the butt down the road, but it seems the current, official BREW stuff (at least that I've used) can have the same problem.
See my recent complaint about vibration working oddly on hardware. The Windows 'emulator' didn't help me one bit with respects to that, so it doesn't win any points there. ;)
Obviously, there's a place for the 'official' emulator (simulator), and nothing will ever replace a stack of 30 different models of phones to test on. ;) But for rapid development, all I worry about is C compiler, and something that does what the API should be doing on the phone, so I can see if it looks right and works well.
I'm willing to put my keystrokes where my mouth is and help out, if people are actually interested in creating some 'wrapper' API, especially if it's around SDL, since I know it so well. (And that, in turn, welcomes our MacOSX, BeOS, Un*x, and Windows friends.)

1. Yes. Better tools would be good. Very good. Please?!?!
2. Firmware in the phones needs to be tested better, and bugs need to be fixed before the handset ships. The crappy state of the handsets out there is just pathetic. I mean ... an A530 drawns lines in the wrong color for crying out loud. You'd think someone somewhere would have spotted that and fixed it before release.
3. I don't think writing a true emulator would be anywhere near the easy task that Charlie seems to think it is ;) Even with the firmware and memory map, you still have to deal with IO lines and interrupts for input, etc which is potentially different on every device. Then you have to drive those correctly to emulate the other connected hardware for sound, display, etc. Not to mention all of the phone tasks (dealing with the CDMA network, etc). All of that gets routed through the CPU in various ways and while I certainly think it's possible to do it for a single device (witness the game device emulators) doing it in a generic way that allows the development to keep pace with the steady stream of new devices seems like a daunting task to say the least. I think some kind of hacked up hardware debugger is more likely, and even that seems highly unlikely to me since I suspect it's going to require manuf support (remember, these are the same people that can't get an A530 to draw a line in the correct color).
4. For now, a simulator is going to have to be sufficient for us. I've been able to make games with it, and now that I've mapped out (most of) the handset bugs in the APIs that affect me all I really need the simulator for is debugging my own game code and making sure the screen sizes are right.
5. The Linux tool they're talking about building would be able to perform a similar task to the Win32 simulator and I guess it could be useful to them. I'm with Charlie in thinking that a Linux simulator would be next to useless to people doing professional work, but since when has such concerns ever stopped the Open Source community? ;)
Tom

1. Yes. Better tools would be good. Very good. Please?!?!
2. Firmware in the phones needs to be tested better, and bugs need to be fixed before the handset ships. The crappy state of the handsets out there is just pathetic. I mean ... an A530 drawns lines in the wrong color for crying out loud. You'd think someone somewhere would have spotted that and fixed it before release.
3. I don't think writing a true emulator would be anywhere near the easy task that Charlie seems to think it is ;) Even with the firmware and memory map, you still have to deal with IO lines and interrupts for input, etc which is potentially different on every device. Then you have to drive those correctly to emulate the other connected hardware for sound, display, etc. Not to mention all of the phone tasks (dealing with the CDMA network, etc). All of that gets routed through the CPU in various ways and while I certainly think it's possible to do it for a single device (witness the game device emulators) doing it in a generic way that allows the development to keep pace with the steady stream of new devices seems like a daunting task to say the least. I think some kind of hacked up hardware debugger is more likely, and even that seems highly unlikely to me since I suspect it's going to require manuf support (remember, these are the same people that can't get an A530 to draw a line in the correct color).
4. For now, a simulator is going to have to be sufficient for us. I've been able to make games with it, and now that I've mapped out (most of) the handset bugs in the APIs that affect me all I really need the simulator for is debugging my own game code and making sure the screen sizes are right.
5. The Linux tool they're talking about building would be able to perform a similar task to the Win32 simulator and I guess it could be useful to them. I'm with Charlie in thinking that a Linux simulator would be next to useless to people doing professional work, but since when has such concerns ever stopped the Open Source community? ;)
Tom

3. I don't think writing a true emulator......
Well as you know there are many many emulators that deal with simulation of complex hardware, even the atari 2600 is a beast to emulate properly. Its really not all that hard when you have all the documentation and speciifcations.
However, a lot of the phone already has software emulation, the software used to design the device can often spit out a software emulator anyway, the ARM core is already done, I'd imagine Qualcomm have a lot more of the core done.
ARM provide a number of simulation tools already.
Plus theres the whole phone side you don't really need, its the analog side thats trickier.
I'm saying its easy in this sense
Qualcomm writing an emulator with all the information available, and a considerable part of the system already written, is a lot easier than writing a simulator with little to no information at all, plus theres no legal hassles.
but 4. is a good point and one i didnt really make strong enough, i dont think it'll change since it never did on other systems for the same reasons, games are still being made, the decks full as it were. We just build up our own custom toolsets which seperates the levels of developers too.

3. I don't think writing a true emulator......
Well as you know there are many many emulators that deal with simulation of complex hardware, even the atari 2600 is a beast to emulate properly. Its really not all that hard when you have all the documentation and speciifcations.
However, a lot of the phone already has software emulation, the software used to design the device can often spit out a software emulator anyway, the ARM core is already done, I'd imagine Qualcomm have a lot more of the core done.
ARM provide a number of simulation tools already.
Plus theres the whole phone side you don't really need, its the analog side thats trickier.
I'm saying its easy in this sense
Qualcomm writing an emulator with all the information available, and a considerable part of the system already written, is a lot easier than writing a simulator with little to no information at all, plus theres no legal hassles.
but 4. is a good point and one i didnt really make strong enough, i dont think it'll change since it never did on other systems for the same reasons, games are still being made, the decks full as it were. We just build up our own custom toolsets which seperates the levels of developers too.

Quote:Originally posted by Vexxed
5. The Linux tool they're talking about building would be able to perform a similar task to the Win32 simulator
And would also run on Win32, MacOSX, BeOS, etc., etc., etc. :^)
In a perfect world, an Open Source simulator would surpass the capabilities and usefulness of the proprietary one, and eventually even Qualcomm would adopt it.
Hey, crazier things have happened!
Point being - I never suggested this should be only a Linux tool :) No reason for it not to run anywhere anyone would want it to.
(My Open Source games run on OSes I've never even used or seen before, for example. All thanks to the fact that they're Open Source ;) )

Quote:Originally posted by Vexxed
5. The Linux tool they're talking about building would be able to perform a similar task to the Win32 simulator
And would also run on Win32, MacOSX, BeOS, etc., etc., etc. :^)
In a perfect world, an Open Source simulator would surpass the capabilities and usefulness of the proprietary one, and eventually even Qualcomm would adopt it.
Hey, crazier things have happened!
Point being - I never suggested this should be only a Linux tool :) No reason for it not to run anywhere anyone would want it to.
(My Open Source games run on OSes I've never even used or seen before, for example. All thanks to the fact that they're Open Source ;) )

Maybe they source code is that buggy they will be afraid to make it opensource :D

Maybe they source code is that buggy they will be afraid to make it opensource :D

Quote:Originally posted by charliex
technically someone who'd never seen the SDK or signed the agreements could be told the specifications required, the clean room approach, but even that these days is very dubious at best.
I'd never signed any agreement when I walked into my local bookshop, picked up a book on Brew programming in C++, read it, and thought 'I know how to do that'.:cool:
The resource formats, true, they'd be legally sticky, but as already pointed out on this forum - we don't need them. An open source simulator would have it's own methods.

Quote:Originally posted by charliex
technically someone who'd never seen the SDK or signed the agreements could be told the specifications required, the clean room approach, but even that these days is very dubious at best.
I'd never signed any agreement when I walked into my local bookshop, picked up a book on Brew programming in C++, read it, and thought 'I know how to do that'.:cool:
The resource formats, true, they'd be legally sticky, but as already pointed out on this forum - we don't need them. An open source simulator would have it's own methods.

Quote:Originally posted by billkendrick
I'm willing to put my keystrokes where my mouth is and help out, if people are actually interested in creating some 'wrapper' API, especially if it's around SDL, since I know it so well. (And that, in turn, welcomes our MacOSX, BeOS, Un*x, and Windows friends.)
Cool! I've created a sourceforge project, and will be transcribing some of my original paper design to code/text next week.
At this time, I'm planning an API-based simulator in C++, using SDL for the gfx/audio. The resources will have their own (open) format that have no relation to the Qualcomm ones.

Quote:Originally posted by billkendrick
I'm willing to put my keystrokes where my mouth is and help out, if people are actually interested in creating some 'wrapper' API, especially if it's around SDL, since I know it so well. (And that, in turn, welcomes our MacOSX, BeOS, Un*x, and Windows friends.)
Cool! I've created a sourceforge project, and will be transcribing some of my original paper design to code/text next week.
At this time, I'm planning an API-based simulator in C++, using SDL for the gfx/audio. The resources will have their own (open) format that have no relation to the Qualcomm ones.

Do you really believe this book-thingie was an argument? You have evidently never met an entertainment or technology lawyer if you believe that comment had any validity. Heck, I don't even understand the logic behind it becasue the book has nothing to do with Brew's intellectual properties, trademarks or anything like it.
Whether you like it or not, the fact remains that Qualcomm could theoretically slap you with a lawsuit for something as trivial as creating a public interface function called "IDISPLAY_Update()" - especially within the context of a Brew emulator.
But be that as it may, what you're essentially saying is that you will be making everything up as you go along. You won't be infringing on any trademarks, service marks, intellectual properties - which is federal law - and you won't reverse engineer any of Qualcomm's technology or file formats - which you signed when you downloaded the SDK. You just make it all up...
Yes, I can certainly see the use in that. ;)
...and I can already see yet another abandoned SourceForge project in the making - like 99% of them. No offense meant.

Do you really believe this book-thingie was an argument? You have evidently never met an entertainment or technology lawyer if you believe that comment had any validity. Heck, I don't even understand the logic behind it becasue the book has nothing to do with Brew's intellectual properties, trademarks or anything like it.
Whether you like it or not, the fact remains that Qualcomm could theoretically slap you with a lawsuit for something as trivial as creating a public interface function called "IDISPLAY_Update()" - especially within the context of a Brew emulator.
But be that as it may, what you're essentially saying is that you will be making everything up as you go along. You won't be infringing on any trademarks, service marks, intellectual properties - which is federal law - and you won't reverse engineer any of Qualcomm's technology or file formats - which you signed when you downloaded the SDK. You just make it all up...
Yes, I can certainly see the use in that. ;)
...and I can already see yet another abandoned SourceForge project in the making - like 99% of them. No offense meant.

Quote:
I'd never signed any agreement when I walked into my local bookshop, picked up a book on Brew programming in C++, read it, and thought 'I know how to do that'.
you accepted the agreement if you downloaded, or installed the SDK though.
Plus being a member of this group (since its a closed group to be a member) allows you direct information.

Quote:
I'd never signed any agreement when I walked into my local bookshop, picked up a book on Brew programming in C++, read it, and thought 'I know how to do that'.
you accepted the agreement if you downloaded, or installed the SDK though.
Plus being a member of this group (since its a closed group to be a member) allows you direct information.

I'm amazed at the amount of effort folks are spending trying to discourage people from attempting an open source emulation tool.
Yes, Qualcomm could slap a cease and desist letter or even a lawsuit on such an effort. But anyone can do that to anybody. Doesn't mean they'll win.
Qualcomm isn't making money by selling their Win32 based-emulator, they make money by licensing the API to manufacturers to put it into their phones, and by taking a small percentage off of the sales of all the apps that use Brew.
Having a broader suite of tools can only benefit Qualcomm. It will give them a larger and more enthusiastic developer community, and result in the creation of more Brew apps. This in turn directly benefits their bottom line by making it easier to find licensors for their technologies and by increasing the number of apps they are getting a % on.
If I were a Qualcomm stockholder, I'd be mightly annoyed if they started suing people who are helping them improve their bottom line at zero cost.
What's the name of the Source Forge project? I'd like to help out.
Ed

I'm amazed at the amount of effort folks are spending trying to discourage people from attempting an open source emulation tool.
Yes, Qualcomm could slap a cease and desist letter or even a lawsuit on such an effort. But anyone can do that to anybody. Doesn't mean they'll win.
Qualcomm isn't making money by selling their Win32 based-emulator, they make money by licensing the API to manufacturers to put it into their phones, and by taking a small percentage off of the sales of all the apps that use Brew.
Having a broader suite of tools can only benefit Qualcomm. It will give them a larger and more enthusiastic developer community, and result in the creation of more Brew apps. This in turn directly benefits their bottom line by making it easier to find licensors for their technologies and by increasing the number of apps they are getting a % on.
If I were a Qualcomm stockholder, I'd be mightly annoyed if they started suing people who are helping them improve their bottom line at zero cost.
What's the name of the Source Forge project? I'd like to help out.
Ed

although qualcomm doesnt sell the simulator, they do make money indirectly from it, but not for the simulator itself.
shareholders are probably more in tune with IP protection, in order to protect qualcomms software interests, formats, algorithms etc, they have to actively pursue anyone ripping it off.
its really simple its the 80/20% rule the open source people are well below the 20% margin, brew is doing really well, as are the developers, any serious developer is already making money from them ,and anyone serious about getting in is hopefully smart enough to be platform agnostic and use what is needed for the job at hand.
if youve got time to sit and write an open source simulator, then you are wasting time when you could just install windows and get developing content, no publisher is going to be very happy when you ship late for that reason ;)
people kept telling us to port our windows games to linux, look what happened there (lokigames)

although qualcomm doesnt sell the simulator, they do make money indirectly from it, but not for the simulator itself.
shareholders are probably more in tune with IP protection, in order to protect qualcomms software interests, formats, algorithms etc, they have to actively pursue anyone ripping it off.
its really simple its the 80/20% rule the open source people are well below the 20% margin, brew is doing really well, as are the developers, any serious developer is already making money from them ,and anyone serious about getting in is hopefully smart enough to be platform agnostic and use what is needed for the job at hand.
if youve got time to sit and write an open source simulator, then you are wasting time when you could just install windows and get developing content, no publisher is going to be very happy when you ship late for that reason ;)
people kept telling us to port our windows games to linux, look what happened there (lokigames)

I have recieved word from BREW support concerning an open emulator, and their willingness to release source code.
"Due to a variety of reasons, Qualcomm has not shown any interest in releasing
source code to the public or dedicating any resources to achieving this
objective. However, I wish you luck in your efforts."
The last sentance gives me hope that they wouldn't start cramming lawyers down my throats if something started to happen.
It's not quite the full endorsement I was hoping for, but is certainly a blessing of a minor magnitude.
:)
Does that change anybody's opinions? [a yes or no will suffice, I know most people's position already and how passionate they are, concerning it ;) ]

I have recieved word from BREW support concerning an open emulator, and their willingness to release source code.
"Due to a variety of reasons, Qualcomm has not shown any interest in releasing
source code to the public or dedicating any resources to achieving this
objective. However, I wish you luck in your efforts."
The last sentance gives me hope that they wouldn't start cramming lawyers down my throats if something started to happen.
It's not quite the full endorsement I was hoping for, but is certainly a blessing of a minor magnitude.
:)
Does that change anybody's opinions? [a yes or no will suffice, I know most people's position already and how passionate they are, concerning it ;) ]

Hi Steev
I am quite interested in this project. In fact I am working on my own BREW emulator for Symbian OS (and possibly for WinCE in the future) - I want to be able to run mod files without recompilation on these devices.
I suppose that around 90% of code will be the same for all the platforms. So, if you are interested in cooperation just let me know.
Zim

Hi Steev
I am quite interested in this project. In fact I am working on my own BREW emulator for Symbian OS (and possibly for WinCE in the future) - I want to be able to run mod files without recompilation on these devices.
I suppose that around 90% of code will be the same for all the platforms. So, if you are interested in cooperation just let me know.
Zim

Quote:Originally posted by ziemowit
I suppose that around 90% of code will be the same for all the platforms. So, if you are interested in cooperation just let me know.
It probably would. And am certainly interesting in co-operating.
How far have you got? Have you got implementations of any parts of the API? My architecture ideas were meant to be documented by now, but job hunting has taken too much of my time :( Once that's done we'll have a clearer picture of how best to proceed.

Quote:Originally posted by ziemowit
I suppose that around 90% of code will be the same for all the platforms. So, if you are interested in cooperation just let me know.
It probably would. And am certainly interesting in co-operating.
How far have you got? Have you got implementations of any parts of the API? My architecture ideas were meant to be documented by now, but job hunting has taken too much of my time :( Once that's done we'll have a clearer picture of how best to proceed.

Hi!
I am already running some simple applications on Symbian phone. At the moment I have a basic framework, 60% of helpers, a few functions from IShell and IDisplay interface without support for bitmaps implemented. I think I will have idisplay sample running by the end of the week.
Zim

Hi!
I am already running some simple applications on Symbian phone. At the moment I have a basic framework, 60% of helpers, a few functions from IShell and IDisplay interface without support for bitmaps implemented. I think I will have idisplay sample running by the end of the week.
Zim

it will work nice under wine

it will work nice under wine

Did it work under wine? Which steps must I go through to get it done? :confused:

Did it work under wine? Which steps must I go through to get it done? :confused:

If qualcomm would like to give linux support they might follow the same way google did:
they released google earth and picasa linux versions which works under linux just by implementing wine api under their own source code, that way they have a software which will not have to be an open source project but they can support linux as well.

If qualcomm would like to give linux support they might follow the same way google did:
they released google earth and picasa linux versions which works under linux just by implementing wine api under their own source code, that way they have a software which will not have to be an open source project but they can support linux as well.

Steev wrote:I have recieved word from BREW support concerning an open emulator, and their willingness to release source code.
"Due to a variety of reasons, Qualcomm has not shown any interest in releasing
source code to the public or dedicating any resources to achieving this
objective. However, I wish you luck in your efforts."
The last sentance gives me hope that they wouldn't start cramming lawyers down my throats if something started to happen.
To me, that reads like an engineer written reply. It might have some high up blessing, it might not - but I certainly wouldn't count on it. The best I would expect of that is a) that the engineers will not point out your activities to the lawyers, because they (possibly) implicitly support them. That will, however, make no difference to the lawyers should they bump into what you're doing, and b) the lawyers would issue a cease and desist rather than a lawsuit. I really wouldn't count on any more than that.

Steev wrote:I have recieved word from BREW support concerning an open emulator, and their willingness to release source code.
"Due to a variety of reasons, Qualcomm has not shown any interest in releasing
source code to the public or dedicating any resources to achieving this
objective. However, I wish you luck in your efforts."
The last sentance gives me hope that they wouldn't start cramming lawyers down my throats if something started to happen.
To me, that reads like an engineer written reply. It might have some high up blessing, it might not - but I certainly wouldn't count on it. The best I would expect of that is a) that the engineers will not point out your activities to the lawyers, because they (possibly) implicitly support them. That will, however, make no difference to the lawyers should they bump into what you're doing, and b) the lawyers would issue a cease and desist rather than a lawsuit. I really wouldn't count on any more than that.