Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: BGB Newsgroups: comp.lang.java.programmer Subject: Re: Android?Why Dalvik? Date: Mon, 30 May 2011 13:09:47 -0700 Organization: albasani.net Lines: 98 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net 9U+zmCfel0XGow+M3hIAogSBmp+JA88K88vPI4wFSdfI619V9fb0jiC59O7K3Av/b9mZS14kYYSeeQmG/ItAgYFo1aGaUD6iIfEN4oF2Br0kEcHx6b+Ehq14F7v8JbqE NNTP-Posting-Date: Mon, 30 May 2011 20:12:48 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="Xm7/qKmWeW/roOHx1RZc2fMH09DQns3L13wGQI2E9N7/rWowuv5gAUnjwrmdKcAg0mfXKbagCFESQ4jjK515BFUtuhvcjRNQVhX7/Xe8UZgFKS+kVbEcPGINdr0BlIr2"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:CcFmBIO9VYEN9Y0E6T9dX2NurtU= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4757 On 5/30/2011 11:24 AM, Steve Sobol wrote: > In article, BGB says... > > >> "well, this is a Windows' app, of course it doesn't work on Mac or >> Linux...", despite that all 3 versions will likely build from the same >> source. > > I'd bet, these days, that the root cause of that situation is the fact > that the three operating systems have *completely* different GUI's. > for source compatibility, yes, cross-platform GUI is a big issue. for binary compatibility, the much bigger issue is the lack of a common set of binary formats, as well as different CPU architectures and operating modes. a VM could address this. > And actually, Linux alone has *two* (more than two, technically, but > only two popular ones) > > You have the Windows UI, the Cocoa UI on Mac, and KDE or Gnome running > under X11 on Linux. > granted... my ideas for running C in a bytecoded VM, also just happened to include ways of basically delaying final type specialization, many cases of handling "#ifdef" blocks, ... until JIT time. but, I don't believe this to be insurmountable with a VM. granted, it is not as simple as with a homogeneous environment say like the Java/JVM model, since this would reasonably need to deal with a good deal more inter-OS variations (and still leaves the issue that code which is not written in a portable way, will still not be portable). but, if the VM can do its part, this at least is a start. so, say, things like: #ifdef _WIN32 void MyApp_SomeWindowsFunction() { ... } #endif #ifdef linux void MyApp_SomeLinuxFunction() { ... } #endif void MyApp_SomeFunction() { ... #ifdef _WIN32 MyApp_SomeWindowsFunction(); #endif ... #ifdef linux MyApp_SomeLinuxFunction(); #endif ... } would delay handling of the ifdef blocks until one is compiling the code in the JIT. in my prior VM design, this had generally worked by internally transforming many of these ifdef conditionals into attributes, where the attribute would be a JIT-time conditional (whether or not to include a given code-block). typically, statement-level ifdefs were handled by folding the code into its own block, which shares lexical bindings with the parent. a restriction to all this though was that #ifdef and similar had to follow proper block nesting, which is not true of true C ifdef's. related restrictions also existed on the use of macros, ... likewise, not all types could be entirely known at compile-time, and so the JIT would have to handle some amount of the type-specialization, ... or such...