New DDE C++ (CFront) video released: DDT Debugging techniques for C++ In-Depth

As Rick has mentioned, the real challenge will be replicating the original RISC OS API

Actually Rick said “don’t”. 😋

It is an API that depends heavily on the behaviour of the original ARM (26/32 bit) processor.
You could sort of fake it within ARM64, but at the cost of potentially making it impossible to port to other platforms and recreating some of the mistakes of the past.

Let’s look at it from another angle. If we want to see RISC OS continue in the future, what exactly are we wanting to preserve?
The behaviour of the desktop?
The fact that it’s a lightweight OS that doesn’t take an entire DVD to install itself?
That programs are self contained and measure kilobytes and megabytes rather than hundreds of megabytes just for something basic like a wrapper around a website?
That a usable (if not nippy) system can be set up with a 700MHz processor with 256MB of memory and a 2GB SD card?

what exactly are we wanting to preserve?

• The (usually) instant reaction to user input.
• The sequential nature of the above
• The windowing system that doesn’t bring windows to the front whenever you touch them
• When something can’t perform the task you ask it to, it stops and doesn’t lock up the whole system
• No constant swapping to disc.
• Lightweight, runs from ROM/RAM

What could be better:

• Prioritise sound over video, video over text, user over everything
• Easier to program in, port to
• Utilise multiple cores

That a usable (if not nippy) system can be set up with a 700MHz processor with 256MB of memory and a 2GB SD card?

There will be a 64bit ARM system with 256 MiB of memory and a 700MHz CPU? Why would anyone want to use that? No matter if it runs RISC OS or Linux or whatever.

Give me a shout when I can use Java for RISC OS development

Java? Java?!

It’s that language that has been in the top 3 of programming languages for the last 20 years. Vastly popular everywhere – except RISC OS (let’s ignore that brief episode in 1996/1997 with the NC and Acorn’s Java 1.0.2 implementation – I think I still have that enthusiastic article in the “Clan Acorn” magazine somewhere). Just in case you didn’t know :-)

What with Oracle’s shenanigans, the wise are moving on from Java.

Nice completely misleading “The Register” article you linked there. “Java” and “Oracle Java” is not the same. Saying “Java” like it is synonymous with “Oracle Java” without mentioning “OpenJDK” is just spreading FUD. Or plain old incompetence – who knows.

Basically nobody cares about “Oracle Java” (that is where the licensing madness happens, as is to be expected from Oracle – ever read the license agreement for the Oracle DB? Or their “per virtual CPU” licensing details?). Even in my area of expertise (large Enterprise customers running a large number of Java software), everyone uses OpenJDK. When it comes to small companies or single developers, the same.

Some move from Java to Kotlin or Scala or even Groovy, but very few move away from the JVM ecosystem. And there are a lot of good reasons for staying.

everybody insists that the DDE should be used now and forever for all things RISC OS

It exists and it works with the RISC OS way of doing things.

Like not supporting VFP? Like not having an Aarch64 backend? Like being always behind the latest C developments? Like having a really crappy debugger? Like having no meaningful way to profile applications? A true 80s style development environment.

All this discussion about alternatives is good and right (as, as has been noted, C might have been the answer fifty years ago but time moves on), however it’s all moot until the time a functional compiler exists.

It is basically a question of judgement which path takes the least resources while leading to acceptable results: first work on proper tooling and saving time and effort in the long run, or adjust the existing tooling and keep wasting time forever. Depending on the end result you want to achieve, the second path might even be the better one.

That being said, there’s roughly zero chance that a future RISC OS will be API compatible with the current one, so maybe we need an entirely new language to go with the new OS, and all the assembler/BASIC/C stuff can remain as parts of “legacy RISC OS”.

You keep saying that, but I am not convinced. Because it depends on the approach that the 64bitting of RISC OS will take. If you completely change everything, who will use RISC OS 64bit? Porting existing apps will be a lot of work if you don’t at least keep the spirit of the RISC OS API. And if you keep the spirit of the API, providing a thin API-based layer that closely mimics RISC OS 32bit SWI world is not the hardest part of this endeavour. There is no longer a “SWI” CPU command, but you can abstract that as “function call which takes numbers, some of them might be pointers to some memory – hey, we could make those 64bit wide”, which is easily represented in 64bit world. Whether that makes sense is a matter of opinion, but so is “RISC OS 64bit”. Windows did the transfer from 32bit to 64bit by just duplicating APIs where necessary, so this is certainly possible. Or just look back at the BBC to RISC OS migration – OS_Byte, BBC BASIC…there can be compatibility layers of many different kinds at every layer of execution.

But in the absence of any meaningful info from the experts@ROOL, I am not sure what the plan is. Or even if one already exists. Maybe I have missed something in the past years, not sure.

IMHO, a proper port to RISC OS is a piece of code that embraces all the assumptions RISC OS has. So, in the case of Java, that means that the JVM should be equipped with a byte-code scheduler that every so often should return control to the OS and intercept all the events for the application being executed on the JVM and then pass those as swing events etc. Not just interpret java byte-code and be done with it.

It really depends on what kind of “Java” you want to port. Java the language, Java the Standard Environment, or Java the whole Ecosystem?

Personally, I would be happy to have “Java the language” and a reasonably fast JVM (i.e. at the level of interpreted BBC BASIC), and the easily portable part of the Standard Environment (i.e. no AWT, no Swing, no Java 2D – but surely the String, Collection, probably also Networking stuff). I can easily write the connectors to the OS as a minimal class library to use. This will of course lose the WORA aspect of Java, but at least all the modern IDEs and debugging stuff could be used, and we would get rid of the “oh, my binary broke because ARM changed something” problem. Although, while we are stuck in 32bit world, that might no longer be a problem because of the lack of 32bit CPU core development advances anyway.

Nice completely misleading “The Register” article you linked there. “Java” and “Oracle Java” is not the same. Saying “Java” like it is synonymous with “Oracle Java” without mentioning “OpenJDK” is just spreading FUD. Or plain old incompetence – who knows.

Oracle have already come after Google for using Java headers, and they’ll keep trying until they find a judge which agrees with them, at which point OpenJDK users will have a choice of abandoning the language of paying the same licencing as for Oracle Java.

The moto of the story is stay well away from anything Oracle has got their hands on.

Oracle have already come after Google for using Java headers, and they’ll keep trying until they find a judge which agrees with them, at which point OpenJDK users will have a choice of abandoning the language of paying the same licencing as for Oracle Java.

In this case, everyone will just stay with the last OpenJDK version and will fork from there on. Nobody in the Java universe really needs Oracle, although they did a quite good job advancing the language after the efforts by Sun more or less stalled and updates were very infrequent.

Oracle’s latest actions with respect to licensing for Java 17 and newer looks like they are now a bit more relaxed wrt this (and this might be why they have now started enforcing their “Premium Support” thing with older versions), so we should be safe for another decade. Compared to the horror stories people invented in 2009 when Oracle acquired Sun, we currently live in Java paradise. So I just hope that this holds for another 15 years when I will retire.

The moto of the story is stay well away from anything Oracle has got their hands on.

Yeah, and stay away from Red Hat and IBM and Amazon and Google and Microsoft and Apple and generally the GPL and whatnot. That somehow limits your options…

Steffan, Oracle sued Google over the use of the Java API headers in Koltin Dalvik, the same ones which OpenJDK uses too. If they can sue over the definition of an API in headers rather than actual source code, everyone is stuffed – this is why it put the shits up the entire industry.

@ Steffen

It really depends on what kind of “Java” you want to port. Java the language, Java the Standard Environment, or Java the whole Ecosystem?

I get what you mean, but the answer in this case is No. For what you want, yes even the minimal support, you do want what I have already mentioned. Otherwise, you’ll end up having exactly the same problems we have porting ANSI C99 code to RISC OS, which, as language, is well supported by both DDE and GCC. However, the code that is being “ported” has assumptions that RISC OS does NOT fulfill and so, to have the code working fine, we need to add a lot of extra work to the port to slice up algorithms etc. to avoid RISC OS Desktop to freeze when using such “ported” software or algorithms.

The reality is, like it or not, RISC OS is way too much behind to think of minimalistic approaches. Sure, people can keep hiding their head in the sand, but that won’t solve anything.

BTW, this is not a criticism, I appreciate people asking for lover specs in the hope to help, but after having ported a few compilers already for my personal use (Prolog, Forth and few others and have worked on porting WASM too), the conclusion is simple:

1) Either RISC OS adopts preemptive multitasking

OR

2) I have to add a code scheduler in my WASM port so that I do not need to write funky Rust/C#/C++/Forth/Go to handle the slicing up so it can run in the WIMP.

There is NO point in porting something like WASM, if then we also need to rewrite ALL the code we are going to compile for it. It’s plain and simple.

So yes, I started to work a way to add an instructions-scheduler that will process a number of instructions and then save the state and give back control to the OS. Full stop, non negotiable, every old fluff will be ignored. All I want is get some C#, regular, don’t touch it, just compile to WASM and then run it on my RISC OS.

The only way to do that is to add certain assumptions to the WASM VM. Now if this is not clear, I am sorry, this is the best I can do with my poor English.

Steffan, Oracle sued Google over the use of the Java API headers in Koltin, the same ones which OpenJDK uses too.

This is partly false, and partly misleading. Side note: I guess you mean Dalvik (the renamed Apache Harmony stuff). Kotlin is a JVM-based language which came a lot later, was developed/invented by JetBrains and later adopted by Google as the language-of-choice for Android. But that was way after they completely replaced Dalvik as their Bytecode VM.

Google knew that they were on shaky ground with the licensing and tried to strike a deal with Sun to properly license things (it was not OpenJDK back then, but a special Sun Shared Code license, similar to the original Castle Shared Source license for RISC OS), but didn’t like the conditions, so they just took parts of it (some would say: stole it) and hoped for the best. They had to later remove quite a bit of code which was a literal copy of Sun source code as it turned out.

The “API is copyrightable” claim by Oracle was also not completely out of this world. Developing an API is a lot of work, documenting it also. If Google would have just adopted the official OpenJDK and put it out under the same license as required, everything would have been fine and dandy, but they didn’t want to give up control.

If they can sue over the definition of an API in headers rather than actual source code, everyone is stuffed – this is why it put the shits up the entire industry.

The whole juristical discussion was about “take an API (and its documentation) and reimplement it while changing the original license”. I am not sure if I am really happy about the outcome of the whole case, because it would now be likely considered legal to create a binary-compatible Linux clone under a license-whatever-you-see-fit (hopefully nobody tells Microsoft about that…). Good or bad?

Anyway, because of the OpenJDK license, Java is now a safe bet. If you use it according to the license, there cannot possibly be a problem. The Google vs Oracle case was just because Google didn’t like the existing license.

It really depends on what kind of “Java” you want to port. Java the language, Java the Standard Environment, or Java the whole Ecosystem?

I get what you mean, but the answer in this case is No.

Either you have not understood what I meant, or I don’t understand that scarce explanations of your reasoning that you have given.

For what you want, yes even the minimal support, you do want what I have already mentioned. Otherwise, you’ll end up having exactly the same problems we have porting ANSI C99 code to RISC OS, which, as language, is well supported by both DDE and GCC.

The topic of your initial post was CFront and how it can be used to allow RISC OS devs to be more productive. My take is that, if we would have a plain and simple JVM (performing similarly to the BBC BASIC interpreter) with a subset of the SE class library, this would be at least as valuable as CFront is now. Because it would allow the use of a prettty good language, with much better tooling available like powerful IDEs on other OSes, and much more modern features than the C++-subset-that-CFront-supports. As you correctly state, it wouldn’t help in using any old Java library which needs the full capabilities of the Java SE and a great JIT and the best GC for acceptable performance and of course an OS that supports the many things that RISC OS lacks. But that is pretty much identical to the CFront situation: no, you won’t be able to just recompile Qt or whatever to work with. Or even something comparatively simple like the STL.

BTW, there are a lot of minimal JVMs available on all type of operating systems, some of which are a lot less powerful than RISC OS. The most minimal JVM (supporting only a subset of Java The Language) is probably NanoVM. I cannot see anything in Java that would prevent having a pretty complete JVM on RISC OS, and I have a proof for this: Java 1.0.2 and even a JITted prerelease 1.2 was available for RISC OS 3.7-with-nested-WIMP, and it performed OKish, even the AWT port – back in the StrongARM days with the limited memory we had back then. Obviously, it needed a green thread approach, but that even makes a comeback now with Project Loom in real-world-Java.

One of the portable JVMs that exist would be Jainja or JamVM, or Oracle’s Minimal JVM (previously called Zero VM IIRC, because it needed zero assembler glue code). But those would need much more effort to experiment with than I can currently (and probably for the next decades) spare.

The “API is copyrightable” claim by Oracle was also not completely out of this world.

No, but it should be, because it effectively neutralises any sort of interoperability. The code can be protected, sure. But not the API.

because it would now be likely considered legal to create a binary-compatible Linux clone under a license-whatever-you-see-fit (hopefully nobody tells Microsoft about that…). Good or bad?

Neither, it’s irrelevant. How many lines of code within Linux do you suppose represent the API? And, now, how many lines of code represent all of the things that Linux does? The API is not the OS, or the kernel, or any of the drivers, or anything like that. It’s just a standardised way of talking to the kernel (drivers, etc).

For example, I could create my own C library. As long as it looked and felt the same as the compiled code expected, there’s no problem (actually, this has sort of been done – ANSIlib vs SharedCLib). By matching the API (a function called printf that takes this this and this and does that), my replacement can be a drop-in equivalent, without necessarily having anything like the same code inside.

I, actually, did pretty much this exact thing for my little RArthur hack, by writing a library to fake the Borland graphics library under RISC OS. So the same code built on TurboC (DOS) and Norcroft (RISC OS).

By magically protecting APIs, you effectively destroy such things.

Besides, aren’t you being a bit pot-kettle-black given that Wine replicates parts of the Windows API on Linux?
That doesn’t mean it is Windows, it just means it looks enough like Windows that Windows stuff can be used.

Anyway, because of the OpenJDK license, Java is now a safe bet.

Nothing’s safe when it’s a combination of Oracle’s lawyers and American law. ;)

this would be at least as valuable as CFront is now.

CFront is an outdated anomaly. It can be used because it exists… but then so does ObjAsm and I think we finally understand that writing Big Things in assembler isn’t exactly future-friendly.
Other options ought to be on the table. Yes, even a JVM.

I cannot see anything in Java that would prevent having a pretty complete JVM on RISC OS, and I have a proof for this

Other proof. I had a Nokia feature phone, a 6301i if I remember correctly. Specs were low, a 240×320 QVGA 2" display, a 2mpix camera with 144p video, 2MB RAM, and given it’s age probably a processor on par with a StrongARM (Google isn’t helpful here).
It offered J2ME for running applets. I had a star chart and Opera browser installed.

If that ancient phone could run a simple JVM and apps, there’s no reason RISC OS couldn’t, given it’s a much more capable system than an old phone and with much more competent hardware.
The barrier/problem will be making a system that is compatible enough that there’s no need for special RISC OS apps, but instead the capability of using third party apps.

Other proof. I had a Nokia feature phone, a 6301i if I remember correctly. Specs were low, a 240×320 QVGA 2" display, a 2mpix camera with 144p video, 2MB RAM, and given it’s age probably a processor on par with a StrongARM (Google isn’t helpful here).
It offered J2ME for running applets. I had a star chart and Opera browser installed.

I had a 6275i which seems to have similar specs (although Wikipedia says “up to” 24 MB of RAM, whatever that means). I did have Opera on it for occasional use, but the main “app” was eBuddy, so that I could send messages for the cost of data (less than 1c per message) instead of via SMS at 20c!

For example, I could create my own C library. As long as it looked and felt the same as the compiled code expected, there’s no problem (actually, this has sort of been done – ANSIlib vs SharedCLib). By matching the API (a function called printf that takes this this and this and does that), my replacement can be a drop-in equivalent, without necessarily having anything like the same code inside.

That’s effectively what Haiku is, having reimplemented BeOS using the documented API as a reference. I’ve been learning to develop for it over the past few days :)

@ Steffen

The topic of your initial post was CFront and how it can be used to allow RISC OS devs to be more productive. My take is that, if we would have a plain and simple JVM (performing similarly to the BBC BASIC interpreter) with a subset of the SE class library, this would be at least as valuable as CFront is now. Because it would allow the use of a prettty good language, with much better tooling available like powerful IDEs on other OSes, and much more modern features than the C++-subset-that-CFront-supports.

To be clear, my comment was ONLY (for the 4 time now) to use CFront as a C with objects to rewrite the WIMP. That’s it and that’s all. Not sure why people are trying to move away from this and try to add wider scenarios (like writing a full OS or porting a JVM to write what? Modules?!?!?!).

In any case, would you really rewrite the WIMP in Java and try to run it on NanoVM which (at this point) it’s a crazy old and minimalistic JVM which does NOT even support JIT????
The WIMP is Module based, Java ported the way you are proposing (if working at all, because you’ll need an old Java 32 compiler for the version of the JVM supported by NanoVM and similar) won’t produce any Module…

From WIMP, back to general development

Steffen, I know you are not one of those just posting things as crazy as the “Da Vinci” madness we saw a few months ago, so, I am sure what you meant was: you wish to have a JVM, just to be able to write some applications in the form of 32bit JARs for RISC OS.

Now, that can be done, yes, but, If you do not add what I have mentioned twice already, then you’ll also need to write Java code specifically for RISC OS. You may be happy with that, but after seeing how this community reacts to low specs and also (in this particular case) another old-version tool that requires expertise with the Cooperative nature of the WIMP, will probably just ignore it (and eventually complain about it).

So, I am not feeling that motivated to port it, but I guess you can keep trying to ask for it.

I feel motivated to continue my work with WASM because of the advantages of having plenty of existing compilers capable of producing WASM bytecode. And, in particular, if my WASM effort would end up handling the Cooperative Scheduler instead of my application code, that would make a lot easier to port code.

With that said, the biggest problem is not porting a VM, that actually is the easiest part. The most boring part is porting the usual core/STD libraries which are the ones that need to deal with RISC OS SWIs etc., so I may get bored at that stage and never finish the work…

I cannot see anything in Java that would prevent having a pretty complete JVM on RISC OS, and I have a proof for this: Java 1.0.2 and even a JITted prerelease 1.2 was available for RISC OS 3.7-with-nested-WIMP, and it performed OKish, even the AWT port – back in the StrongARM days with the limited memory we had back then.

A JVM, like a .NET CLR, like ANY bytecode interpreter can ALL be ported to RISC OS as long as they are written in a language that can be compiled for RISC OS and have a way to port their core/STD libraries to RISC OS (normally this is done by abstracting the syscall mechanism, like Chris has done for Python for example). Some of these VMs are a lot of source code thought, so the time to spend porting it may be more than people can commit to, in which case, while it’s still technically possible to do a port, it’s just not gonna happen because noone is motivated enough to go through all the required process.

But if there are enough people wanting to code in Java on RISC OS, maybe you’ll find folks motivated enough to port it.

I have already ported a bunch of things, and, in all honesty, it’s a tedious process and, at the end of it, these ports result also slow and that is (again) because RISC OS lacks the assumptions on which many of these tools rely upon. Rick made a good point mentioning some of the proprietary and minimalistic JVM created for certain phones, but they are mostly gone now and, again, they were paid efforts, not so sure how that can be done by folks having few hours on a Sunday afternoon (like myself).

But, again, if one of those outdated JVMs would make some users happy, maybe someone may get motivated enough to do a port.

In conclusion: don’t try to rewrite the WIMP with ANY VM based language
Surelly they won’t be able to be used to help rewriting the WIMP, so on that side, CFront (at least for now) is probably the best tool available¹.

Hope it’s clear this time, if not, oh well, looking forward to see a WIMP rewritten as a module and interpreted in a ported minimalistic JVM.

[edit]
Edited to help Steffen to figure out which part is general and which part is in reference to use Java or ANY VM based language to rewrite the WIMP
[/edit]

¹ With a note of sarcasm and sadness at the same time.

Not sure why people are trying to move away from this and try to add wider scenarios (like writing a full OS or porting a JVM to write what? Modules?!?!?!).

We may be looking at an example for Maslow’s Hammer

Thank you for that. A new phrase for me, of personal relevance.

We may be looking at an example for Maslow’s Hammer

Makes a lot of sense, thanks!

The topic of your initial post was CFront and how it can be used to allow RISC OS devs to be more productive. My take is that, if we would have a plain and simple JVM (performing similarly to the BBC BASIC interpreter) with a subset of the SE class library, this would be at least as valuable as CFront is now. Because it would allow the use of a prettty good language, with much better tooling available like powerful IDEs on other OSes, and much more modern features than the C++-subset-that-CFront-supports.

To be clear, my comment was ONLY (for the 4 time now) to use CFront as a C with objects to rewrite the WIMP.

To which of your comments do you now refer? Your second posting perhaps, where you mention the rewrite-the-WIMP-in-CFront-C++-instead-of-C idea and then say “To get back on the topic”, which at least I understood that it was merely a side note?

Certainly you cannot refer to this thread’s opening, because the topic was DDT and CFront, and not rewrite-the-WIMP.

And you also cannot refer to our Java discussion, because most of your comments make zero sense if they had a rewrite-the-WIMP focus. Like mentioning all the Java libraries that take certain OS features as given to achieve good performance (like Swing) – multi-threading, fast non-blocking I/O, you name it.

And you also cannot refer to the very post that I have previously responded to, because what I have in mind and have described numerous times in this thread certainly needs no fully-preempted RISC OS – its necessity you have postulated very clearly, I quote: “One of them is preemptive multi-tasking”. And you cannot possibly had the WIMP rewrite in mind when you mentioned “you’ll end up having exactly the same problems we have porting ANSI C99 code to RISC OS”, because that would also make zero sense in that context.

So it looks to me that it was mostly your own posts that were very far from the one topic that you now want to put over and above all others that were discussed so far.

That’s it and that’s all. Not sure why people are trying to move away from this and try to add wider scenarios (like writing a full OS or porting a JVM to write what? Modules?!?!?!).

There were a lot of different topics and things mentioned in this thread. Why you now suddenly declare that rewriting the WIMP in CFront-C++ was the only topic is very surprising and makes zero sense if you look at the broader discussion and especially the Java part of it. And especially if you look at your own posts.

I quote something you wrote previously:

So, in the case of Java, that means that the JVM should be equipped with a byte-code scheduler that every so often should return control to the OS and intercept all the events for the application being executed on the JVM and then pass those as swing events etc.

So you are one of those people you accuse when you say “Not sure why people are trying to move away from this and try to add wider scenarios”?

In any case, would you really rewrite the WIMP in Java and try to run it on NanoVM which (at this point) it’s a crazy old and minimalistic JVM which does NOT even support JIT????

I wouldn’t want to rewrite the WIMP in any way with whatever-technology, and never said that Java running on a VM would be a good way to achieve that. This is all your own invention – classic straw man tactics it would seem, I just don’t understand why you would resort to such tactics. But to respond to it half-way serious: one of the AOT transpilers converting Java to C might be a better choice than CFront, but let’s not get into another side topic.

BTW, NanoVM was an example of an implementation of a JVM running on an extremely resource-restricted host (mainly in response to your insistance that the OS on which a JVM is running needs a lot of sophisticated support for all those post-90s features that RISC OS lacks), I don’t know why you now pick that one example. Although NanoVM is also an example for a bytecode interpreter that could be easily ported. And the 8 KB of memory it is specified to need might even be something that the “RISC OS needs to stay slim” die-hards would grudgingly accept. So a worthy contender for “something like BBC BASIC, but for a modern language”, even if this language is a subset of Java-as-we-know-it-now.

The WIMP is Module based, Java ported the way you are proposing (if working at all, because you’ll need an old Java 32 compiler for the version of the JVM supported by NanoVM and similar) won’t produce any Module…

We are straying quite far from my area of interest and what I originally discussed in this thread, but anyway. I don’t see any convincing reason why this approach would not work for module code like the WIMP. Performance-wise, because the WIMP itself hardly does any serious work if you count the CPU cycles used. Most of those are probably consumed (in real-world-operation) by the FontManager, and the Sprite and VDU stuff (block copy anyone?). So you would “just” need e.g. a dedicated bytecode instruction to branch out into SWIs or call ARM code directly, and the rest could be interpreted by that small 8 KB lump of code that could easily run as a module and provide the API to the rest of the OS as needed for the bytecode to interact with it during execution. And there would be a new type of module, the “bytecode module”, which is not executed directly, but under control of the VM. Problem solved.

For completeness, maybe you can explain what you mean by “old Java 32 compiler”? Java bytecode is just the same bytecode for 8bit, 32bit or 64bit machines. Or anything in between.

Steffen, I know you are not one of those just posting things as crazy as the “Da Vinci” madness we saw a few months ago, so, I am sure what you meant was: you wish to have a JVM, just to be able to write some applications in the form of 32bit JARs for RISC OS.

Not sure what you mean by “32bit JAR”, but yes: it should have been very obvious that this was my topic: writing RISC OS applications in Java. Of course one could have misunderstood me if you take “use Java for RISC OS development” out of the context of all my postings in this thread and insist that “RISC OS development” actually has the rather narrow focus of “writing RISC OS the core OS”. But you really have to try very hard to ignore most of what I have written.

Now, that can be done, yes, but, If you do not add what I have mentioned twice already, then you’ll also need to write Java code specifically for RISC OS.

I don’t know why you insist to try to explain to me what I already know and have mentioned before. Or why do you think I have stressed the difference between (I quote myself) “Java the language, Java the Standard Environment, or Java the whole Ecosystem”? And even described what subset I would be happy with?

You may be happy with that, but after seeing how this community reacts to low specs and also (in this particular case) another old-version tool that requires expertise with the Cooperative nature of the WIMP, will probably just ignore it (and eventually complain about it).

I think it should be clear that my idea is probably only appealing to me, or at least of very limited appeal to anyone else. But I like being in a minority of 1 (or, back in the mid-90s, of 4), you know my Ada-on-RISC OS background. Also totally happy with people complaining about everything. The user is always right.

So, I am not feeling that motivated to port it, but I guess you can keep trying to ask for it.

Did I ask you to port it? I don’t think so. If someone is motivated and thinks it might be fun, go for it. If not – who cares? The state of RISC OS would be much healthier if developers followed my great suggestions and plans over the decades, but that’s just my personal hubris that I like to cultivate.

I feel motivated to continue my work with WASM because of the advantages of having plenty of existing compilers capable of producing WASM bytecode.

You mean in the same way as plenty of existing Java-and-a-lot-of-other-languages compilers are capable of producing JVM bytecode?

With that said, the biggest problem is not porting a VM, that actually is the easiest part. The most boring part is porting the usual core/STD libraries which are the ones that need to deal with RISC OS SWIs etc., so I may get bored at that stage and never finish the work…

Have we now left the “I just want to talk about rewriting the WIMP” arena again, or are you still on that topic? Difficult to judge. Maybe you want to explain why WASM would be a good way to rewrite the WIMP, and which core/STD libraries you envisage to be needed for that?

But if there are enough people wanting to code in Java on RISC OS, maybe you’ll find folks motivated enough to port it.

This is seldomly the way the RISC OS “market” works. Things exist because mostly single individuals wanted to do things, and that – mostly by accident – happened to be useful for one or more users.

But, again, if one of those outdated JVMs would make some users happy, maybe someone may get motivated enough to do a port. Surelly they won’t be able to be used to help rewriting the WIMP, so on that side, CFront (at least for now) is probably the best tool available.

To which outdated JVMs are you referring to? All I mentioned are a lot less outdated than CFront.

Hope it’s clear this time, if not, oh well, looking forward to see a WIMP rewritten as a module and interpreted in a ported minimalistic JVM.

It is indeed unclear which part of your post now refers to the “rewrite the WIMP” part and which covers more general ground, but let’s leave it at that. And hopefully nobody expects a Java-written WIMP replacement anytime soon, because I have not even hinted at the vague possibility of me doing that.

One final note: you were absolutely correct when you said previously

I had enough of forum discussions, they don’t bring anything.

Ignoring what other people have said is one way to make totally sure that forum discussions end up in lengthy posts with far too many quotes, and that really does usually not help furthering the state of things.

Hi Paolo,
As proposed at the beginning of the thread, I have posted 2 examples on my website:
The first is a skeleton application written in C++ which I use as a base for all my new applications. There is also documentation made with CCdoc in html.

The second is an implementation of one of Peter Shirley’s books: Raytracing
The examples are built from DDE and CFront. The C++ approach is in this case a very good tool, the design of the program is clearer and easier to follow.
The OOP approach is another way of thinking…

This is just my opinion,my goal is to be able to build applications with Risc OS (I used tools like Builder and C++ is widely used in programming, even for a simple Arduino)
“Link”: https://jeanmichelb.riscos.fr/C++.html

Hi Jean-Michel,

As proposed at the beginning of the thread, I have posted 2 examples on my website:

Very nice! I’ll link them in the code examples on GitHub

he examples are built from DDE and CFront. The C++ approach is in this case a very good tool, the design of the program is clearer and easier to follow.

I agree

The OOP approach is another way of thinking…

Indeed, but (just as an example) let’s not forget that DDE C++ also support Templating functions (which is not OOP) and still helps to keep source clean.

Again thanks for sharing! :)

Indeed, but (just as an example) let’s not forget that DDE C++ also support Templating functions (which is not OOP) and still helps to keep source clean.

A working example .

  

//https://tutsmaster.org/c-template-class-and-function-template/
// The syntax for Function Templates
#include<iostream.h>
#include<stdio.h>

template<class T>
T min(T a, T b){
  return (a<b)?a:b;
}

int main(){
  int a=10, b=5;
  cout<<min(a,b) <<endl;
  float x=2.2, y=3.4;
  cout<<min(x,y)<<endl;
  char q='A', p='B';
  cout<<min(q,p)<<endl;;
  //getch();
  getchar();
  return 0;
}
 

Templating functions (which is not OOP)

You can do template functions without using OOP, but OOP without templates would be pretty useless – container classes (lists, expandable arrays, maps/dictionaries, etc) would have to have a variant implemented for each type of object you wanted them to hold.

I’ve seen it done with specific implementations for simple types, and a catch all for everything else which has to be derived from a common base class, but that isn’t type safe, wasteful of memory, and generally pretty horrible.

but OOP without templates would be pretty useless

Indeed.

Luckly CFront supports Template classes, works fine and they can also be debugged in DDT! (Luxury!) More details to come on next videos ;)

On a side note, I have almost completed porting all the famous Design Patterns in DDE C++, I was surprised to see that quite a few needed only minor tweaking to work on CFront (bonus). I already showed the first one in one of the previous videos.

Also, given that everyone seems to be either interested or wanting to build/port a VM, I am preparing a video where I show how to write a simple (and also fully functional) VM in DDE C++, and, if I have enough time, I’ll make it a module too.

I’ve seen it done with specific implementations for simple types, and a catch all for everything else which has to be derived from a common base class, but that isn’t type safe, wasteful of memory, and generally pretty horrible.

Indeed, seen it too, did OOP in ANSI C as well (many years ago), I know you are going to run away orrified lol, but, in my defense, it was a paid job! XD

CFront has a lot of great features that makes it better than C99, however, in the other hand, it was also a not completed port, for instance there is no STL, ROOL worries not, in one of my (way too many) project, I started to port the old STL to DDE CFront, if nothing it will make the retro coderz happy to have a fully working CFront that can also produce desktop Apps. Release date: when I’ll get a 48 hours day XD

@Paolo.
With CFront I use a version of STL, certainly very retro (1997), but which works.
https://jeanmichelb.riscos.fr/CathlLibCPP.html

Yes for desktop application!Diderot and above all!Svg2Draw which builds a lot of objects…

I added the document describing the structure of the program (CCdoc), just to have an overview.
https://jeanmichelb.riscos.fr/XML.html#SVG_to_Draw

@ Jean-Michel

With CFront I use a version of STL, certainly very retro (1997), but which works.

Thanks, saw this in the past, but there are no sources available, and (sorry for being direct), I don’t invest time learning something on RISC OS that has no sources available. This is not something that has to do with some Open Source’s cult or something, quite the opposite, it has to do with avoiding wasting time on something that may disappear (or no longer being maintained) any moment.

RISC OS has an historical community that (sadly) is shrinking, not expanding. So, IMHO, we are to a point where we can not longer afford rely on copyrighted/no source tools and apps (obviously everyone is free to decide for themselves, so this is just my opinion!). We can make exceptions for DDE because ROOL has few people there working still, but everything single-developer at this point should have sources made available (again IMHO).

The port I am making of the STL will have sources released and, if anyone is interested in helping, I can release the sources even in the next few weeks. JFYI they are the same sources that CathLibCPP started from, so they will be on pair when port is completed.

Again sorry for the directnes, I hope it makes sense and if it’s something that others don’t share, that’s fine, we are ALL entitled to our own opinions. To me life is too short to invest my time on things that are not worth it (according to how I give value to things obviously).