OSDev.org

berkus wrote: But what is it capable of? Dalvik, for example, is a Java VM with JIT and full support for the whole Java range of applications. And it's still fairly compact.

berkus wrote: I understand you do not want to compare raw LLVM with VCMI, fair, but let's take Horizon - project based entirely on LLVM, including JIT, managed bytecode execution etc. How VCMI is more capable than Horizon? What additional benefits would it provide (let's imagine for a moment that you quickly wrote a decent cross-platform JIT for VCMI)? Again, Horizon at the moment doesn't specify exact interfaces, it merely provides a mechanism to run different components in a colocated address space safely and efficiently. You can tack interfaces on top rather easily - just specify them and adhere to them. Provided that LLVM can generate bitcode from a variety of languages, plus the fact that the JIT is capable of pretty nice optimizatins based on more information available in the bitcode - it will just blow the dust out of VCMI on any real test as I see it.

berkus wrote: Can you provide objective metrics which make VCMI better for running portable applications than for instance LLVM?

berkus wrote: I do not see a specified interfaces to the VCMI either, which means there can be different implementations? Which means it is inherently non-portable?

#include <stdlib.h>
#include <stdarg.h>

#ifndef _STDIO_H
#define _STDIO_H

#define EOF (-1)

typedef struct _FILE FILE;

extern FILE *stdin,*stdout,*stderr;

int vsprintf(char *buf, const char *fmt, va_list args);
int sprintf(char * buf, const char *fmt, ...);

void vfprintf(FILE *f,const char *fmt,va_list args);
void fprintf(FILE *,const char *fmt,...);

void printf(const char *fmt, ...);

FILE *fopen(char *,char *);
int fclose(FILE *);
int fwrite(void *,size_t,size_t,FILE *);
int fread(void *,size_t,size_t,FILE *);
int fgetc(FILE *);
int fputc(int,FILE *);
int ferror(FILE *);

#define getc(f) fgetc(f)
#define putchar(c) fputc(c,stdout)
#define getchar() fgetc(stdin)
#endif

/* stdlib.h */

#ifndef _STDLIB_H
#define _STDLIB_H

#define NULL ((void *)0)

#define long int
typedef int size_t;

void *malloc(int);
void free(void *);
void exit(int);
void *realloc(void *,size_t);
char *getenv(const char *name);
int atoi(char *s);

#define alloca malloc

#endif

So far I see easier ways to share applications between two arbitrary OSes - one can just plainly emulate the whole 2nd OS API and be done with it.

NickJohnson wrote:But none of those headers include anything about graphics or anything platform-dependent (which is C's problem in the first place: it's standard library is tiny.) You will have to add much much more glue to get anything out of your VM other than command line output.

NickJohnson wrote:Also, WINE took a long time to make because it was completely reverse engineered. If Windows' API were completely open/documented, it would have taken a heck of a lot less time than 15 years.

lybredyne wrote:I will make an announcement when we release the code early next year ( Jan or Feb ) and we will see if any one is interested.

The reason I made this initial announcement was to let people know it was coming.
Not to cause an argument.

inx wrote: Not trying to criticize or offend, simply to inform, but this alone is setting yourself up for a hearty round of criticism.
The software industry as a whole is plagued with vaporware announcements, and with hobbyist projects, OSDev especially,
they're more the rule than the exception.

inx wrote: The latter point is especially poignant. If you need the reassurance before you commit the time and (metaphorical) sweat,
this is not the hobby for you. We will not value your plans, only your results, and even then, you're more likely to get
brotherly criticism than a parade. This is not a bad thing, it's just how things are.

berkus wrote: As far as I see you didn't even study the existing field of platform abstraction techniques and just jumped in to do something. It may be brave, but this is software development, not pirate plunder. I've no idea what you are capable of doing, but you could've started with thinking first

Creature wrote:I like the idea of having applications that are (almost) fully cross-platform, but I'm always weary of the possible overhead it involves. Do you have any plans to add other languages such as C++?

berkus wrote:Can I see the benchmarks? Like Horizon has at least a minimal benchmark, can you run the same on yours and post the results?

fronty wrote:How well does your C compiler compare to other compilers? It won't be very useful if the virtual machine is fast if compilers can't generate proper code for it.

lybredyne wrote:The compiler we wrote is mostly C99 compliant.
The compiler is not self hosting.