Android—Why Dalvik?

  • Thread starter Lawrence D'Oliveiro
  • Start date
G

Gene Wirchenko

Thanks, but I don't need compliments from you.

I have little tolerance for Lawrence's debate tactics, which ARE stupid.
I'm a pretty blunt, shoot-from-the-hip kinda guy.

And if you are not careful with that, you will alienate people
rather quickly. I will leave it to you to determine whether doing so
is wise or not.
You, on the other hand, are someone who apparently just decided to jump
into this discussion and not add anything useful to it.

Oh, it is quite useful. You need not use it, and I see that you
are not.
Have a nice life.

I intend to.

Sincerely,

Gene Wirchenko
 
L

Lawrence D'Oliveiro

Gene Wirchenko said:
And if you are not careful with that, you will alienate people
rather quickly. I will leave it to you to determine whether doing so
is wise or not.

Don’t worry about him. I come across this sort of bullshit all the time. You
can tell the type: when they find they’re on the losing end of the argument,
they resort to abusive, ad-hominem attacks. This way, they hope to distract
attention from the actual point. The trick is to keep bringing them back to
the point.

Sometimes this makes them angrier, which can be a source of amusement in
itself. :)
 
L

Lawrence D'Oliveiro

Gene Wirchenko said:
Several might not be enough either.

And you might not have to prove <not-rareness> but <in general
use> or <in general use in one or more niches>.

That’s why I quoted well-known examples which most people would recognize.
 
A

Arved Sandstrom

Don’t worry about him. I come across this sort of bullshit all the time. You
can tell the type: when they find they’re on the losing end of the argument,
they resort to abusive, ad-hominem attacks. This way, they hope to distract
attention from the actual point. The trick is to keep bringing them back to
the point.

Sometimes this makes them angrier, which can be a source of amusement in
itself. :)

"I come across this sort of bullshit all the time".

There is a simple, glaringly obvious reason for that. Albeit not the one
you cherish.

AHS
 
M

Michael Wojcik

Steve said:
So, he and his friend can say whatever they want to about me

I don't know that Gene Wirchenko is Lawrence's friend. He *is* a
relative Usenet old-timer, having been posting since the mid-1990s
(since 1995, I think), and like most of us Usenet fogeys has some
opinions about the medium. He's also a contributor to RISKS and other
forums. You certainly needn't agree with him, but I wouldn't recommend
ignoring him out of spite, either.
 
M

Michael Wojcik

Lawrence said:
How did you get that brain scan?

I believe Joshua was contesting the former word in your phrase "just
technology", and not the latter. Health - even if by that we mean just
"systematized health care" - is not "just" technology. We do not have
mechanical doctors.
 
M

Michael Wojcik

Lawrence said:
No, what you mention are themselves just technologies, not domains.

This is a painfully foolish line of argument. (I am saddened that you
appear to have convinced even one person with it. What are they
teaching in school these days?)
Engineering is just a collection of technologies;

Humans are a collection of molecules; that does not make them molecules.
finance is technology
(insofar as it is mathematically-based);

Humans are carbon-based; that does not make them carbon.
health is nothing without
technology these days;

Humans are nothing without oxygen; that does not make them oxygen.
same with education, aeronautics, etc, etc.

Cetera indeed.

Even a less-foolish formulation of this line of thought - a pure
instrumentalist world view - has been thoroughly critiqued by any
number of sophisticated thinkers, from Jurgen Habermas (not one of my
favorites, but not stupid either) to Andrew Feenberg to Donna Haraway
and so on.
 
M

Michael Wojcik

Steve said:
yeah, yeah, nice ad-hominem. Since you're going to be obnoxious, kindly
tell me how many different architectures are in *wide* use today?

In wide use?

8-bitters were still in the majority, according to the last reliable
statistics I saw. Circa 2003, they represented ninety-some percent of
all CPUs sold.

There are still healthy markets for 16-bitters, DSPs, FPGAs, etc, too,
in the embedded space.

IBM sells about a billion dollars worth of z-architecture CPUs each
financial quarter. They sell lots of POWER chips, both on the high end
(p and i systems) and embedded.

ARM outsells x86.

SPARC and ia64 still have some market share.

GPUs and CPU-GPU hybrids are growing fast as general-purpose systems.

There are 50 million Cell-powered PS3s. 75 million Wiis with POWER
CPUs. 54 million or so XBox 360s; its Xenon CPU is either a POWER
derivative or a Cell derivative or both, depending on your
interpretation. And that's a significant software market.
 
A

Abu Yahya

I was curious earlier, and downloaded the Android SDK, and made an
inconvenient observation:
the emulator is slow...

emulating an older version of Android, it is ok, but trying to emulate a
newer version, performance is unusably slow.


maybe a similar issue might apply to iOS, meaning that maybe the
emulated version is not an adequate representation of how it will behave
on real HW...

I must mention that it's not the case with the iOS simulator. I've been
using it for sometime now, and it always starts in a snap and responds
amazingly well. It's the envy of my colleagues who code for the Android
and Blackberry platforms using Eclipse, where the emulators take forever
to load.
 
G

Gene Wirchenko

I don't know that Gene Wirchenko is Lawrence's friend. He *is* a

I am not.
relative Usenet old-timer, having been posting since the mid-1990s
(since 1995, I think), and like most of us Usenet fogeys has some

Yes. Coincidentally the end of September, but no matter.
opinions about the medium. He's also a contributor to RISKS and other

And of manners in general.
forums. You certainly needn't agree with him, but I wouldn't recommend

RISKS is great, and I am pleased to be able to contribute.
ignoring him out of spite, either.

Quite.

Sincerely,

Gene Wirchenko
 
B

BGB

I must mention that it's not the case with the iOS simulator. I've been
using it for sometime now, and it always starts in a snap and responds
amazingly well. It's the envy of my colleagues who code for the Android
and Blackberry platforms using Eclipse, where the emulators take forever
to load.

maybe Apple knows more what they are doing?...


I tried simulating Android 3.1, but the emulated OS was generally very
unreponsive, like basically "click, hold, wait several seconds,
something happens, ..." eventually got a lock image on the screen, and
it would no longer do anything past this point...


Android 2.x is a bit more responsive though, but still not really an
example of raw speed either (turning off some graphical effects though,
like menu-transition and scrolling effects, did make it a bit faster
though).

I also observed that they have a shell, but the shell sort of sucks (not
nearly as good as Bash...).

I am wondering it this is more a matter with fundamental limitations
(say, Android takes too much processing power or requires simulating a
GPU or similar), QEMU (not simulating ARM efficiently, ...), or with
Google (say, they wrote inefficient HW emulation code, ...).


in total, I am not terribly impressed either with the emulator or with
the NDK tools (strange build setup, ...).

since I don't have a smartphone either, there is not a whole lot of real
reason for me to bother with all this.


or such...
 
A

Arved Sandstrom

Lawrence said:
How about this one <http://www.blender.org/>, with a million lines of C
code, last I counted. Or this one <http://dev.mysql.com/>. Or this one
<http://www.libreoffice.org/>. Or this one <http://httpd.apache.org/>.

So your claim is that the total number of C and C++ programs, minus
four, is less than "a lot"?

Though to be honest, I don't really see what the point is. I think
Joshua is overestimating the number of C and C++ programs that are
specific to Linux and won't build on OpenBSD or Solaris. There are
definitely some, but IME they're usually the ones that deliberately
use features peculiar to Linux, for whatever reason.

(A better argument might have been the number of C and C++ programs
that run on x86 Linux but either don't build or fail on one of the
pickier UNIXes, such as HP-UX for Itanium. But even then it's a quibble.)


What's more important is the generally poor quality of C code. (I
think much C++ is also poorly written, but arguing that is more
complicated, because it's a far larger language with more latitude for
programmer choice.)

So let's look at your examples.

Blender: Has about 260 open bugs, including memory allocation issues
and assertion failures. Much of the source is C++, which I'm not going
to look at now; but the C source is problematic. For example, there
are a few uses of strncpy. strncpy has broken semantics; it is never
the right choice. Blender also includes its own implementation of
strncpy (BLI_strncpy), for no readily apparent reason, and most of the
code uses that; but it's sub-optimal. It also uses strcpy extensively,
and I'm not convinced all of those are safe, for example in the
makesrna implementation. That's just from a minute of glancing at the
source.

MySQL: 145 bugs filed in the past 30 days, some of which are clearly
coding errors (eg #61303, #61208). I don't want to take the time right
now to prowl through the sources, but the project does not have a
great track record; see CVE-2009-2446, CVE-2006-1516 through
CVE-2006-1518, CVE-2010-3676 through CVE-2010-3683, and so on.

LibreOffice: A fork of the OOo code, which does not have a great track
record. Consider CVE-2010-3450 through -3454, etc. And while those
CVEs don't list LibreOffice among vulnerable products, the SuSE
LibreOffice update claims it's vulnerable (see [1]). I suspect the
relative lack of official vulnerability reports for LibreOffice is
because they're generally reported against OOo instead. And since LO
has significant additional features on top of the OOo base, it has a
lot more room for additional mistakes.

Apache: An outlier project, with excellent funding and a great many
eyes on the code. That hasn't kept it free of errors. Take a look at
the brand-new CVE-2011-1921, for example. Or CVE-2011-1928, a classic
error in C code, caused by a fix to the earlier CVE-2011-0419. '0419
and '1928 are only DoS vulnerabilities; but that's bad enough.


And these are extremely popular projects, so they get a lot of
attention. Less-used and less-examined code tends to be much worse.


[1] http://secunia.com/advisories/43837/
I'll throw a few more into the mix. These are two pieces of C/C++
software that I had reason to use at work a few months. One well-known,
one not so much so.

Case A: I needed to write a web services client in C. So I went with
Axis 2 C. My initial build attempt was on Mac OS X 10.6, which is a
certified UNIX 03. It didn't. Come to find out that some fellows have
worked out the handful of (relatively simple) patches needed to fix the
#ifdef's for Mac OS X. Seeing as how Axis 2 C purports to be implemented
with portability this wasn't a good start.

I got the sucker built on Mac OS X. After generating the stubs for a
working WSDL (you need to use a Java-based tool to do this), I
discovered real soon that an important struct that is used frequently in
generated stub code (by used I mean often used by value; e.g.
de-referenced pointers) had its full declaration buried in a .c
implementation file for the _library_; not in the corresponding header.

It has been quite a while since I wrote any C prior to this, but I
figured this wasn't quite right. Especially since there was no way the
client code would compile with just the headers for the Axis 2 C
library. So maybe I'm missing something really obvious here, but there's
no denying the fact that in two different ways what should have compiled
out of the box did not. The error was a standard "storage size not
known" kind of thing. It was easy enough to fix (with some refactoring
of the Axis 2 C library, and re-building it), which makes the situation
worse somehow.

I eventually dispensed with Axis 2 C altogether - this experience didn't
make me happy, and a different design decision let me move to
higher-level .NET APIs. NOt to mention, the Axis 2 C API docs sucked, so
I ended up generating some useful ones using Doxygen - another black
mark - *and* the API itself could have been better.

I might note that I ran across one comment by an Axis 2 C developer
where he said that the model to be followed was

"typedef done inside the header and the struct declaration is in
source...in a case you still want to move the struct to the header (it
is not a much recommended approach in c programming) ... [Ed. How-To
description of procedure follows]"

Maybe I missed something in my years away from C, but those
recommendations were new to me.

Case B: I was working with the source code for a Windows printer driver
that I wished to modify. I tried to build it with VC++, several
versions, and just could not easily do it - the code was studded with
UNIX API calls. As soon as I hacked one problem it led to others.

To this day I can't understand why a group of developers - moreover, a
group of developers who were "good" enough to write a working and fairly
sophisticated Windows printer driver - insisted on thoroughly mixing
Windows code with UNIXish code. It's jarring to see the use of UNIX I/O
in the same source along with MS-inspired Hungarian notation and MFC
macros. It's hard to read...plus I hate a lot of those macros.

I eventually only succeeded in building this driver from source by using
a very specific version of the Dev-C++ IDE, namely the one with an exact
version of mingw included. Even a later version of standalone mingw on
the command line, using the *supplied Makefile*, would not build this
driver. It had to be the mingw included with Dev-C++...using that makefile.

Again, maybe it's just me, but this smacks of laziness and user
unfriendliness. I respect the efforts put in by the mingw and cygwin
people, but the point of those is to make it easier to use existing UNIX
stuff on Windows. If you have the opportunity to write a C/C++ Windows
printer driver *from scratch* you write it the Microsoft way, IMHO.

This team did one other thing which I really, really disliked. Their
printer driver - it created image files actually - uses libpng, libjpeg,
libtiff and zlib. Each and every one of these builds OK on Windows,
producing a DLL and LIB along with headers that can be used by other
projects in the usual way...I know, because I've built them on Windows
enough times over the years. What these guys did was pull in all of the
source for these libraries, and bundled them in with their own code. So
the printer driver build was intimately intermingled with compiling and
linking the code for those 4 libraries.

I'm sorry, but that's just not the way it's supposed to work.

In this case too the experience leaves me with the impression that it's
working but substandard C/C++ code. Cutting corners to suit your own
development preferences means you might be cutting corners somewhere else.

AHS
 
J

Joshua Cranmer

What these guys did was pull in all of the
source for these libraries, and bundled them in with their own code. So
the printer driver build was intimately intermingled with compiling and
linking the code for those 4 libraries.

I'm sorry, but that's just not the way it's supposed to work.

I don't know Windows development as well as I do Linux, but in Linux at
least, it is "very hard" to link userspace libraries into kernel
modules, so I suspect that Windows drivers have the same issue: you need
to have those libraries statically linked in.
 
A

Arved Sandstrom

I don't know Windows development as well as I do Linux, but in Linux at
least, it is "very hard" to link userspace libraries into kernel
modules, so I suspect that Windows drivers have the same issue: you need
to have those libraries statically linked in.
I appreciate the point you make. In this case the thing is based on the
MS universal printer driver (Unidrv), and the UI and rendering plugins
for that, plus the port monitor that the project also supplies, are all
user-mode DLLs. Furthermore, the function of _this_ port monitor is
ultimately to write image files, not to communicate with kernel-mode
port drivers even.

AHS
 
S

Stefan Ram

Michael Wojcik said:
VB.NET is in many ways closer to C# than it is to historical BASIC.
It's trivial to compile VB.NET into MSIL and then decompile it back
into C#, or vice versa (if you avoid newer C# features that aren't
supported in VB.NET yet).

VB is not called »VB.NET« anymore.

When one writes code in VB, then compiles it into IL, one
can't but avoid newer C# features that aren't supported in
VB yet!

There also are features in VB not supported in C#.

"Visual Basic is a full-fledged modern object-oriented
language with many unique features, such as static
typing where possible but dynamic typing where
necessary, declarative event handling, deep XML
integration with optional layered XSD types, highly
expressive query comprehension syntax, type inference,
etc. etc. This makes Visual Basic actually more
interesting to researchers and practitioners than the
"popular" static languages such as Java, C# and dynamic
languages such as Ruby or JavaScript."

Erik Meijer
 
S

Stefan Ram

Michael Wojcik said:
LibreOffice: A fork of the OOo code, which does not have a great track
record. Consider CVE-2010-3450 through -3454, etc. And while those
CVEs don't list LibreOffice among vulnerable products, the SuSE
LibreOffice update claims it's vulnerable (see [1]). I suspect the
relative lack of official vulnerability reports for LibreOffice is
because they're generally reported against OOo instead. And since LO
has significant additional features on top of the OOo base, it has a
lot more room for additional mistakes.

So, where is my Java Office Suite?

1997 Lotus wrote an Office Suite in Java, but it has been withdrawn.
 
B

BGB

Michael Wojcik said:
LibreOffice: A fork of the OOo code, which does not have a great track
record. Consider CVE-2010-3450 through -3454, etc. And while those
CVEs don't list LibreOffice among vulnerable products, the SuSE
LibreOffice update claims it's vulnerable (see [1]). I suspect the
relative lack of official vulnerability reports for LibreOffice is
because they're generally reported against OOo instead. And since LO
has significant additional features on top of the OOo base, it has a
lot more room for additional mistakes.

So, where is my Java Office Suite?

1997 Lotus wrote an Office Suite in Java, but it has been withdrawn.

OpenOffice is written partly in Java...

I am not sure what or how much, as personally I have not looked at its code.
 
A

Arved Sandstrom

VB is not called »VB.NET« anymore.

That's true, and I guess it hasn't officially ever been VB.NET except
for the 2003 version. In the real world, though, a lot of coding still
happens in classic VB. I've had to do fairly extensive work the past few
years in VB6, work which is not readily possible in VB (.NET). For ease
of discussion I'll often refer to VB7 and later as VB.NET, and I'm not
alone in this.
When one writes code in VB, then compiles it into IL, one
can't but avoid newer C# features that aren't supported in
VB yet!

There also are features in VB not supported in C#.

"Visual Basic is a full-fledged modern object-oriented
language with many unique features, such as static
typing where possible but dynamic typing where
necessary, declarative event handling, deep XML
integration with optional layered XSD types, highly
expressive query comprehension syntax, type inference,
etc. etc. This makes Visual Basic actually more
interesting to researchers and practitioners than the
"popular" static languages such as Java, C# and dynamic
languages such as Ruby or JavaScript."

Erik Meijer
Those are 2007 comments if I'm not mistaken. I'm using C# 4.0 in a
current WPF project, and I'm not sure that there's any of those features
that I'm _not_ using right now. Microsoft has very rapid development
cycles for its languages (as you know), and while that's sometimes a
PITA it's often a bonus. One side-effect of that is that if a given
version of VB has something cool, and a given version of C# doesn't,
then most of the time the next version of C# will.

Recall that C# 4.0 is mostly about dynamic features.

OT for CLJP: writing desktop apps in C# 4.0 and WPF (XAML heavy) is yet
another eye-opener for me. I'm mostly a Java SE/Java EE guy and so every
time I get a chance to do some pro work in C# it's refreshing.
Particularly GUI work. To this day if I wanted a GUI in the Java world
I'd go with a web app. If there's one thing MS seems to have gotten
right forever, and Java has struggled with, it's desktop apps and all
the tooling for it.

And I hate to say it but ever since I started using C# (with C# 2.0 in
my case, I barely scratched the surface of 1.0) it's always struck me as
being a jump or two ahead of Java. Most of that I attribute to the
dynamicism of the Microsoft language factory, contrasted to the problems
of the JSR process. But it's certainly been the case for me that it just
seems to be easier to get things done with C# than with Java, version by
version. Particularly with desktop apps.

This is core language mind you. I think Java EE on the other hand
generally has had a definite edge over anything that Microsoft has
produced, and Java EE 6 is more of the same. But not necessarily by much
- Java web apps got a jump on MS in particular with JSF, but a few years
later MS levelled the playing field with ASP.NET MVC, and for a whole
spectrum of web apps these days I'd toss a coin to choose between JSF
2.x and ASP.NET MVC 2 or 3.

AHS
 
S

Stefan Ram

Arved Sandstrom said:
OT for CLJP: writing desktop apps in C# 4.0 and WPF (XAML heavy) is yet
another eye-opener for me. I'm mostly a Java SE/Java EE guy and so every
time I get a chance to do some pro work in C# it's refreshing.
Particularly GUI work.

Last time I looked, the library did not even offered me
lay-out managers, and wanted me to specify the component
geometry in some screen unit.

I tried to code my way around this and build GUIs without a
hard-coded geometry.

For example, when I tried to create a form with a button,
an input field and an output field, I had to set its size
/manually/ (what a disgust, just look at the »5«!):

form.Size = new System.Drawing.Size( button.Size.Width, 5 * input.Size.Height )

, and there was no default layout mangager which would do
this for me. But maybe I just did not known the most elegant
way to do this in C#?
 
M

Michael Wojcik

Arved said:
I might note that I ran across one comment by an Axis 2 C developer
where he said that the model to be followed was

"typedef done inside the header and the struct declaration is in
source...in a case you still want to move the struct to the header (it
is not a much recommended approach in c programming) ... [Ed. How-To
description of procedure follows]"

Maybe I missed something in my years away from C, but those
recommendations were new to me.

His description's not quite right, but incomplete structure
declarations are an important aspect of encapsulation in C.

Ignore any mention of "typedef" for a moment. typedef is a misnomer,
since it doesn't define a type, just an alias for an existing type.
(It's also of questionable utility. Some people think it's useful for
defining complex function-pointer types; I say if you don't understand
C's function-pointer syntax, don't write C code.)

In C, new types are defined using the struct keyword (and sometimes
union, but that's really just a specialized struct). The struct
keyword can do either or both of two things:

- define a structure type
- introduce a type name into the struct-tag namespace

The former is necessary if you want to inspect the contents of an
object of the type, evaluate its size or the size of the type, etc.
But it is not necessary to define certain derivative types, such as
the const-qualified equivalent type, or the associated pointer type.

The latter is what lets you encapsulate. In a header, you provide an
incomplete structure declaration and an API that uses the pointer type
derived from it:

struct foo;
struct foo *CreateFoo();
DoThingToFoo(struct foo *, ...);
PureFunctionOnFoo(const struct foo *, ...);
DeleteFoo(struct foo *);

Consumers of your API have no access to the implementation of struct
foo, so they're insulated from any changes to it. And since struct foo
* is a perfectly good object pointer, they can do whatever they'd do
with any other pointer, except dereference it.

(You can of course wrap "struct foo" in a typedef, if the people who
use your API are too lazy to type the word "struct".)

Note the initial "struct foo;" is necessary. Otherwise the use of an
unknown "struct foo" in the declarations of the API would only
introduce the type name in "prototype scope", which ends at the end of
each declaration. Prototype scope is basically useless.

This is a useful and fairly widely used technique - though not nearly
as widely as it should be. Of course, the API has to provide for
whatever its consumers need, since the consumers don't have direct
access to the contents of the structure, can't allocate or copy one, etc.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top