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

Developer

Forums

Forums:

allow C# programming language

What is the Need of C# ?
C, C++ works perfectly well and is efficient too ?
Regards

What is the Need of C# ?
C, C++ works perfectly well and is efficient too ?
Regards

I don't think that C# would really mesh well with the BREW runtime environment. We would more or less need to completely redesign BREW from the ground up.
But, it is a nice little programming language. Who knows, maybe someday somebody will port Mono onto BREW (if that's even possible).

I don't think that C# would really mesh well with the BREW runtime environment. We would more or less need to completely redesign BREW from the ground up.
But, it is a nice little programming language. Who knows, maybe someday somebody will port Mono onto BREW (if that's even possible).

I think if you want an interpreted language you can try java, there are projects for a j2me vm for brew, not sure how it is going on.
but if you really like c#, you can always code your own .NET vm to brew yourself, you don't need to wait for others, asn can make money from it when done

I think if you want an interpreted language you can try java, there are projects for a j2me vm for brew, not sure how it is going on.
but if you really like c#, you can always code your own .NET vm to brew yourself, you don't need to wait for others, asn can make money from it when done

What's next? Someone wants Prolog or ADA on a Brew phone? The world didn't need C# to begin with...

What's next? Someone wants Prolog or ADA on a Brew phone? The world didn't need C# to begin with...

i'd like the current brewos/sdk to work a lot better, before we get other ones ;)

i'd like the current brewos/sdk to work a lot better, before we get other ones ;)

Very good point. Can't believe that argument slipped my mind. :-)

Very good point. Can't believe that argument slipped my mind. :-)

True, but don't you think that's less a technical issue than it is one of clout?
It just doesn't seem to me that QC has the wherewithal to stand up to large handset manufacturers and say "Uh. No. That's not good enough. You've gotta fix these problems before you can call that a BREW phone."
I mean, does anyone believe that the SE47, for instance, actually passed a Brew test suite? Or that its problems (transparent text is pretty basic stuff) were unknown when it was deployed?
Yeah, yeah. Sorry about that. Rant mode off.... :)
-jim

True, but don't you think that's less a technical issue than it is one of clout?
It just doesn't seem to me that QC has the wherewithal to stand up to large handset manufacturers and say "Uh. No. That's not good enough. You've gotta fix these problems before you can call that a BREW phone."
I mean, does anyone believe that the SE47, for instance, actually passed a Brew test suite? Or that its problems (transparent text is pretty basic stuff) were unknown when it was deployed?
Yeah, yeah. Sorry about that. Rant mode off.... :)
-jim

Well, I guess QC wouldn't do that (standup against large handset ODM vendor) untill BREW is established itself as serious threat to Symbian or became major leader.

Well, I guess QC wouldn't do that (standup against large handset ODM vendor) untill BREW is established itself as serious threat to Symbian or became major leader.

I think they could take that position - and should - but don't. There is no reason to believe why QC shouldn't have enough wait to make certain demands in connection with the licensing of their technology. With a bit of a presentation it should be easy enough for both OEMs and carriers to also see that it would be to their own benefit as well, actually.
Hower QC takes an extremely defensive stand on these issues and rather not dare put their power to the test, sadly, which is a weakness and only gives leeway to competitors.

I think they could take that position - and should - but don't. There is no reason to believe why QC shouldn't have enough wait to make certain demands in connection with the licensing of their technology. With a bit of a presentation it should be easy enough for both OEMs and carriers to also see that it would be to their own benefit as well, actually.
Hower QC takes an extremely defensive stand on these issues and rather not dare put their power to the test, sadly, which is a weakness and only gives leeway to competitors.

from what i remember, the handset makers are the ones that run the compliance testing not qualcom, for a lot of the problems qualcomm gets the blame, but most of the times its the oems at fault, however that doesn't mean qualcomm shouldnt have been a bit more stringent about compliance, say like sgi and opengl.
however opengl was the defacto standard and sgi could force whatever rules they wanted, brew is an upcoming underdog so they more than likely have to bend to the OEMs, lg for instance is a powerful company.
theres a number of phones that have glaring problems, i have a hard time understanding, like the c343, i actually talked to the engineers at motorola who ran those tests on the phone and it was just that the tests didn't check for that particular problem (pressing keys during sound playback), so part of it is the lack of a complete conformance test, as well as the sheer numbers of handsets.
but then the navigation system in my car displays --.-- instead of the time from 8PM to 12midnight, quality control these days is minimal and the variations is tremendous.
but the se47 is a strange one, same as the 8600 i cant understand that one either.

from what i remember, the handset makers are the ones that run the compliance testing not qualcom, for a lot of the problems qualcomm gets the blame, but most of the times its the oems at fault, however that doesn't mean qualcomm shouldnt have been a bit more stringent about compliance, say like sgi and opengl.
however opengl was the defacto standard and sgi could force whatever rules they wanted, brew is an upcoming underdog so they more than likely have to bend to the OEMs, lg for instance is a powerful company.
theres a number of phones that have glaring problems, i have a hard time understanding, like the c343, i actually talked to the engineers at motorola who ran those tests on the phone and it was just that the tests didn't check for that particular problem (pressing keys during sound playback), so part of it is the lack of a complete conformance test, as well as the sheer numbers of handsets.
but then the navigation system in my car displays --.-- instead of the time from 8PM to 12midnight, quality control these days is minimal and the variations is tremendous.
but the se47 is a strange one, same as the 8600 i cant understand that one either.

regarding BREW handset "compliance" testing - all of the players take part in this. Qualcomm provide a quite detailed test tool to the OEMS to assist in the testing. The carriers also have this tool and use it to review the OEM test results, along with performing their own carrier specific testing. Qualcomm themselves also review the handsets using the above tool plus their own internal testing before the handset is released to NSTL.
Having said this, what it really boils down to is that the carrier decides what devices it will be offering, and will make those decisions based on both commercial and technical criteria. Qualcomm does not have much of a stick to beat up on the OEMS as the major commercial relationship is between OEM<->Carrier, although they have been doing a lot to make things better over the last couple of years.

regarding BREW handset "compliance" testing - all of the players take part in this. Qualcomm provide a quite detailed test tool to the OEMS to assist in the testing. The carriers also have this tool and use it to review the OEM test results, along with performing their own carrier specific testing. Qualcomm themselves also review the handsets using the above tool plus their own internal testing before the handset is released to NSTL.
Having said this, what it really boils down to is that the carrier decides what devices it will be offering, and will make those decisions based on both commercial and technical criteria. Qualcomm does not have much of a stick to beat up on the OEMS as the major commercial relationship is between OEM<->Carrier, although they have been doing a lot to make things better over the last couple of years.

Yeah, that may all be true, but you're missing the point, which is that the firmware implementations on those phones need to be controlled more diligently.

Yeah, that may all be true, but you're missing the point, which is that the firmware implementations on those phones need to be controlled more diligently.

therein lies the problem - how does "qualcomm control the firmware implementations" when the commercial decision making is not under qualcomms control?

therein lies the problem - how does "qualcomm control the firmware implementations" when the commercial decision making is not under qualcomms control?

A handset doesn't get to say that it supports Brew unless Qualcomm says it does.
You are correct, however, in that QC has a pretty small stick - particularly since the "Brew" brand is entirely hidden from the end user.
With regard to compliace suites, I think it's pretty clear from postings on this board that the coverage of those suites is in many places pretty spotty.
IWEB_, for one, seems pretty solid. I make _very_ heavy use of it (posting/loading both text and binary data) in Neverwinter Nights Mobile and once I got through the initial quirks, I've never had any problems with it on any of the handsets I've tested it on, nor has there ever been an NSTL failure because of it.
Behavior of ISOUNDPLAYER_, on the other hand, is so inconsistent across platforms that developers find we can only use a small subset of its documented features. I mean, setting the volume doesn't even work on most handsets.
And, to flog a dead horse yet again: How does one explain the SE47? Drawing transparent text is a pretty basic feature. Hard to imagine a compliance suite that doesn't cover it.
-jim

A handset doesn't get to say that it supports Brew unless Qualcomm says it does.
You are correct, however, in that QC has a pretty small stick - particularly since the "Brew" brand is entirely hidden from the end user.
With regard to compliace suites, I think it's pretty clear from postings on this board that the coverage of those suites is in many places pretty spotty.
IWEB_, for one, seems pretty solid. I make _very_ heavy use of it (posting/loading both text and binary data) in Neverwinter Nights Mobile and once I got through the initial quirks, I've never had any problems with it on any of the handsets I've tested it on, nor has there ever been an NSTL failure because of it.
Behavior of ISOUNDPLAYER_, on the other hand, is so inconsistent across platforms that developers find we can only use a small subset of its documented features. I mean, setting the volume doesn't even work on most handsets.
And, to flog a dead horse yet again: How does one explain the SE47? Drawing transparent text is a pretty basic feature. Hard to imagine a compliance suite that doesn't cover it.
-jim

You know, I suspect this thread should get moved and/or retitled.
It's an interesting conversation, but really has nothing to do with C#... (I'm not even sure why I read it in the first place) :)
-jiim

You know, I suspect this thread should get moved and/or retitled.
It's an interesting conversation, but really has nothing to do with C#... (I'm not even sure why I read it in the first place) :)
-jiim

jiim,
Thats not entirely true. Its mostly the carriers decision whether to go commercial with a handset, and unless the handset has serious problems, Qualcomm will go with the carriers decision. Qualcomm can work ehind the scenes to encourage the OEMs to do it better but thats about it. What Qualcomm can do is look at the relationships between carrier<->qualcomm<->oem and encourage a better form of infromation sharing. At the moment, Qualcomm will not disclose issues discovered in their testing to the carrier - a truly bizzare situation!
There are also a few carriers where Qualcomm is entirely out of the loop.
As for the SE47 (and other handsets), there are some carriers that decided not to offer it as a BREW product , partly because of its problems, partly for comercial reasons. The test tools themselves have improved out of sight over the last 18 months.
(BTW, I agree that this thread should be moved)

jiim,
Thats not entirely true. Its mostly the carriers decision whether to go commercial with a handset, and unless the handset has serious problems, Qualcomm will go with the carriers decision. Qualcomm can work ehind the scenes to encourage the OEMs to do it better but thats about it. What Qualcomm can do is look at the relationships between carrier<->qualcomm<->oem and encourage a better form of infromation sharing. At the moment, Qualcomm will not disclose issues discovered in their testing to the carrier - a truly bizzare situation!
There are also a few carriers where Qualcomm is entirely out of the loop.
As for the SE47 (and other handsets), there are some carriers that decided not to offer it as a BREW product , partly because of its problems, partly for comercial reasons. The test tools themselves have improved out of sight over the last 18 months.
(BTW, I agree that this thread should be moved)

Title has been changed.

Title has been changed.