When will 0.3.15 release?

[Dave3434]

i hope reactos becomes just stable as windows 2000 was.

[Black_Fox]

So again, are there x86 Tablets/Phone devices?

I didn't do any (re)search, but I just stumbled upon ZTE GRAND IN yesterday that uses Intel Atom Z2460.

[BlackRabbit]

All those are ARM devices. They aren't currently ReactOS compatible. So again, are there x86 Tablets/Phone devices?

There are some. Intel is pushing the XOLO, for example. But caveat emptor: The device is being sold in India, not the USA. One primary reason is that Intel currently enjoys healthy margins from their semi-monopoly of PC x86 platforms. They would essentially start down the path of self-cannibalization if they were to try to compete with the cheap ARM devices made in China, because the general public would become aware of what digital designers have known for a long time: x86 CPU's are over-priced. This trend will continue. The Microsoft/Intel duopoly will fight tooth-and-nail to maintain tight control over Windows-centric computing.

[Z98]

And how are they overpriced?

[BlackRabbit]

There are multiple interpretations of being "over-priced":

• On an similar-product basis, meaning that, if there were 20 companies producing Atom chips, Intel's profit margins would be much lower.
• On a comparable-product basis, meaning that, if an an alternate CPU architecture were allowed to replace x86, providing roughly same performance, Intel's profict margins would be much lower.
• On a dissimilar-product basis, meaning that, if market dynamics allowed taking advantage of reduced-power, fewer-features, etc. in exchange for lower cost, there would be a non-linear drop in price. The "1/5-the-quality" product would have a cost that is significantly less than 1/5 the cost of the better product. ARM is an obvious example.

  TI delivers multiple ARM microprocessor and microcontroller offerings that start at prices as low as $1 and deliver performance levels up to 5GHz.

This page summarizes some of the issues.

See also:

how-the-processor-wars-will-benefit-consumers-most

[Z98]

Based on your links, I'm inferring that you don't want to pay the price Intel is charging for its Atom line. Fair enough, but there is almost no pressure for Intel to offer their Atom line at lower prices. If you want obscenely cheap x86 processors, go with VIA. It's what the majority of Chinese manufacturers do when they want to stick an x86 processor into a small form factor system. Of course you get a system with significantly worse performance than what Intel can pull off, but if your main focus is on price and you're willing to take the performance hit, there is an alternative. Since no one else can come close to producing an x86 processor that matches the power usage and performance of the Atom, Intel is free to charge whatever the market will bear. That they do not seem to need to drop the price is an indication that the market is willing to accept the current price. And the cost quoted in that second link can't possibly be including R&D and NRE costs. Intel sinks billions into its fabs, both in researching how to actually move to the next process node and then actually building the tools to do so. That cost has to be recouped in the price of their products. Recouping material costs is relatively trivial compared to trying to recoup and pay for new R&D costs.

And if you don't care about the x86 ISA, ARM is of course the other choice available. That Intel can keep prices where they are again indicates that there is a sufficiently large market for their products at the current price point to allow Intel to make a profit and reinvest in their R&D. That no one else has been able to compete with Intel sufficiently to force down prices should be an indication of just how expensive trying to do so is. Considering how badly AMD has been floundering, the obvious question is, are the markets Intel's processors target even large enough to support two competitive companies engaged in a price war. Cause if it's not, then it's a moot point how much prices are cut if the pipeline of future products are gutted as a result of lack of funds for R&D.

[BlackRabbit]

ARM port. Are there rapsberry-pi x86 alternatives? Or Interl x86 micros similar to ARM ones for phablets/tablets devices?

I just realized what you were asking. Yes, there are numerous small-form-factor x86-like devices. Most of them were around long before Raspberry Pi.

Here is a picture of a tiny Atom-based computer:

[ external image ]

One might ask:

If this is true, that it has been possible for over a decade to put Windows on a tiny x86 computer and tinker with it, why is Raspberri Pi all-of-a-sudden so popularr?

One reason cost. But another important reason is accessibility of two kinds:

• The device is accessible because newbie tinkerers know that they will not be alone as they learn. The Arduino exploits this human need for social security.
• The device is accessible in the physical sense, meaning that leads come from the device that allow it to interface to something else, like a driver to a stepper-motor. Notice in the picture above that the Atom-based PC does not present any GPIO headers.

To an electrical engineer, all of this is somewhat silly. The motherboard on my Dell PC, for example, has support for much more I/O than it appears. All one needs to do is add the headers to positions that are clearly marked and labeled. I mention this to say that perception is important. Even though low-priced ARM systems have been possible for over a decade, simply by using the telephone to order the components from an electronics supplier, the fact that it has been packaged, presented, and developed within the context of a community draws people. These same people are not yet aware that they can have an "open-source-Windows-clone" on their Raspberry Pi's (actually RPi is missing some hardware like real-time-clock). If they were shown, there would be a massive influx of contributors. But the integration of such contributors would need to be managed carefully. Throwing them the source code, cmake, Visual Studio, a few debug tools, etc...and saying, "OK, start hacking, good luck!" would work for some, but not for most. Their initial experience matters.

But I must reiterate. If ReactOS is serious about generating money to support the foundation, the most lucrative path, IMO, is what I mentioned earlier in this thread: stabilize it just enough to put it into ARM-based devices, then package it, and sell it to the large number of corporations that would very much like to run a Windows-like OS on ARM without paying Microsoft "exhorbitant" fees ($90US / unit, in some cases).

[BlackRabbit]

And if you don't care about the x86 ISA, ARM is of course the other choice available. That Intel can keep prices where they are again indicates that there is a sufficiently large market for their products at the current price point to allow Intel to make a profit and reinvest in their R&D. That no one else has been able to compete with Intel sufficiently to force down prices should be an indication of just how expensive trying to do so is. Considering how badly AMD has been floundering, the obvious question is, are the markets Intel's processors target even large enough to support two competitive companies engaged in a price war. Cause if it's not, then it's a moot point how much prices are cut if the pipeline of future products are gutted as a result of lack of funds for R&D.

I think Intel was a monopoly, then became part at duopoly. And as you pointed out, semiconductor operations is not cheap. It's not like creating a plant for purifying water, where, if you produce the product, competitively, the market will very quickly accept your product. The barrier to entry is relatively low. A fab, on the other hand, is a $500,000,000US proposition before a single device is sold. The risk is there for the PC OEM, as well as the chip maker. I do agree that Intel spends a huge amount of money on R&D.

I only focus on ARM right now because 1+ billion devices cannot be wrong.

[vicmarcal]

... stabilize it just enough to put it into ARM-based devices, then package it, and sell it to the large number of corporations that would very much like to run a Windows-like OS on ARM without paying Microsoft "exhorbitant" fees ($90US / unit, in some cases).

1)This is not a problem of stability but about full-port to ARM.

We can have an unstable ARM port. But the Port is needed.Unless...thanks to ReactOS, the embedded x86 begins to be a serious ARM competitor.

[PascalDragon]

PascalDragon, and what about the Android's Java VM?

What do you mean here?

You do know that there is nothing stopping you from writing native applications on Android and Tizen that leverage the full functionality of the underlying Linux kernel? E.g. for Android there exists an app that contains a QEMU binary or one that provies an IDE for a native Android port of the Free Pascal compiler. On Android Google does not stop you from doing this. And Tizen is even more a "normal" Linux than Android is.

Forgive me for being skeptical, but every time that I hear a claim of "native" Android support, I go to take a look, and what I see is, to put it lightly, fictitious. I have taken quick looks at Android's NDK for example. This is not a native application platform development tool, despite what Google claims. Not really. They allow some native code, then they force you to invoke the native code using JNI. I have no interest in JNI whatsoever.

You need to differentiate here. If you need access to the GUI (including touch nput) then you need to use JNI for this. Since 2..3 you don't even need to write an Activity in Java anymore and can do that completely in native code (of course there is still the code for interfacing with the GUI). If you don't need GUI access you can basically write a typical Linux command line application which just needs to link to Android's C library bionic (the NDK provides the necessary tools and libraries for this). You can then start this program either through the debug shell (I did this already with an Hello World Free Pascal program) or you can use fork/exec in your app library to start it (and interact with it through pipes).

QEMU on Android, if I understand correctly, does not count. It is an emulator.

I'm not talking about QEMU because it's an emulator. I'm mentioning it, because it is a native ARM binary which uses a special version of SDL for Android to display the machine's content.

Tizen, from what I understand, is trying to go the HTML-5 route with web applications. For native applications, a framework is provided, to which the developer must conform. If the developer tries to write a "normal" Linux application, it will not work. I could be wrong, and would be happy if I am.

According to the Wikipedia entry about Tizen you only need to comply to the packaging rules, so you need to use a specific format for packages, but otherwise you are completely free to write you application in the ways you prefer.

Regards,
Sven

[BlackRabbit]

You need to differentiate here. If you need access to the GUI (including touch nput) then you need to use JNI for this.

Well, I do want GUI access. I want the same unrestricted access that I would get running Linux on a desktop by writing my application in C/C++ with no need for any other languages or shells or frameworks or whatever.

[PascalDragon]

You need to differentiate here. If you need access to the GUI (including touch nput) then you need to use JNI for this.

Well, I do want GUI access. I want the same unrestricted access that I would get running Linux on a desktop by writing my application in C/C++ with no need for any other languages or shells or frameworks or whatever.

And that should be considered part of the operating system. On Windows you need to use the WinAPI to access the GUI on normal Linux systems you need to access the X server or at least the framebuffer, on Mac OS X you need to use the Objective C based Cocoa framework and on Android you need to use the Java based GUI APIs. That's part of the ecosystem there.

There is however also a port of Qt5 being worked on, the Lazarus project provides also experimental Android support (both use the Java APIs user the hood, but provide their usual native access) and if you are really adventurous then there is a X server for Android for which you "just" need X libraries to link against.

Regards,
Sven

[BlackRabbit]

Well, I do want GUI access. I want the same unrestricted access that I would get running Linux on a desktop by writing my application in C/C++ with no need for any other languages or shells or frameworks or whatever.

And that should be considered part of the operating system. On Windows you need to use the WinAPI to access the GUI on normal Linux systems you need to access the X server or at least the framebuffer, on Mac OS X you need to use the Objective C based Cocoa framework and on Android you need to use the Java based GUI APIs. That's part of the ecosystem there

The definition of native has been changed. It use to be that native development meant that, starting with a high-level language, that language would be compiled into byte code, and the resulting image would be entirely executed by the CPU. There would never be a chance for an interpreter to intervene.

With Android/WP7/WP8, the true image is not the image that the programmer creates by his own script, but another image, and interpreter, that executes the programmer's image, and might allow some of the programmer's image to run against the CPU. For this reason, these models are better described as hybrid development. The examples that you give for Win32 and X both have something in common: the entire image of the program executes directly against the CPU. At no point is the image interpreted by another image that itself executes against the CPU.

This is why I think that we should articulate our definition of OS:

• Android has Linux at its core, but is it Linux?
• WP7 has Windows CE at its core, but is it Windows CE?
• WP8 has Windows NT at its core, but is it Windows
• If Windows 9 retains the Windows NT core, but the entire desktop becomes a web browser, using HTML5 and The Cloud, which the programmer must use to execute hybrid pseudo-native applications, including access to Win32 API, is it still Windows?
• If I were to take WINE, put it on Linux, close-off the other parts of Linux so that all programs must go through WINE, then recreate support for X Windows by running an X Server that was originally written (natively) for Windows on the WINE layer, and recreated XLib from Win32 code that also runs on WINE, what do I call the resulting OS? Linux? Windows? WINE-On-Linux?
• If I take an OS, that has a well-known API, and wrap another API layer around it, then restrictively and incrementally give access to parts of the original API that I deem necessary, is it the same OS?

I am looking for an OS where the only machine that interprets my image is the CPU itself. Note that giving the appearance that this is happening is not an objective.

[Z98]

Definition of byte code: Instructions designed for efficient execution by a software interpreter.

The moment you mention byte code you're not doing "unmanaged" development.

You say you think the definition of an OS should be articulated, but what you seem to actually want is a clarification on what information is imparted by the name of an OS. The definition of "OS" is itself relatively unambiguous.

[BlackRabbit]

More clearly stated:

I want the bits of an image that are generated by compiling my C/C++ code to be interpreted by a physical CPU that most-likely consists of registers and combinatorial logic that conforms to a von-Neumann architecture. I want the entirety of my image to be interpreted as such. At no point do I want there be an intervening software interpreter, unless one counts the micro-code interpreter that exists inside the physical CPU.