JLF65 wrote:
Quote:

Kalamatee wrote:
Yes of course, and AFAIK fabio is working hard on doing just that.

Cool. Good to hear. Being able to do the AROS developing inside AROS would sure help a lot of things go faster.

Kalamatee wrote:
Yes of course, and AFAIK fabio is working hard on doing just that.

I would urge you to join the irc channel and speak to fabio - it would be great to have the kernel at least up and running to some extent.

As i said before (and youve kind of agreed with) the hidds to support the win32 host would be trivial. If aros is using a bitmap for its display then im sure basic gfx wont take much (with no acceleration perhaps to start - or minimal) likewise input events are events as you point out - so handling those is also pretty trivial.

Filesystem suppport alos doesnt need anything more than to be able to access files on the host.

Anything more than the above imo isnt needed UNTIL a hosted version is up and running - then they can be implemented (sound , etc etc..)

JLF65 wrote:

That would work. I guess we're in for a major reorganization of the cvs - nearly EVERYTHING is currently built outside AROS. If the AROS support of gcc is good enough, everything needs to start moving inside AROS. The only thing left outside should be hosted executables.

Yeah, I guess so, but I'm used to working on virtual memory systems, device drivers, exception handlers, and kernel modules, so it seems really easy to me. Given that Windows does have context functions, it should at least be easier than the Linux hosted task handling.

The event handling though IS easy to ANY experienced Windows programmer. I don't think you can write a Windows program and NOT have dealt with events. It's like writing an Amiga program and never dealing with messages. This is especially true if you've done any multi-buffered DirectSound handling.

Kalamatee wrote:
What i am saying is ONLY the main AROS exe should be in the "hosts" format - everything else should be in AROS's format.

- but soon hopefully you can compile a good portion inside aros - obviously the main system and gcc etc would still need built first, so some form of cross compiler is going to be needed.

I know a good few people who wouldnt consider it "the simple stuff"..

What i am saying is ONLY the main AROS exe should be in the "hosts" format - everything else should be in AROS's format.

JLF65 wrote:
Windows doesn't use the same ABI as everyone else as well as a different file format. Why do you think Cygwin and MinGW even exist? You can't simply change the target of gcc to pe32 and have working binaries.

When the host program is built, quite a bit of the rest of the system is also built using the same tools. I suppose you could change the build scripts for Windows hosted to ONLY build the executable, then make sure to account for the change in ABI inside the host program when running the AROS executables. That would negate the need for any changes to file support, but Windows people would no longer be able to compile their own applications or system files without setting up a cross-compiler. Remember, Cygwin and MinGW are generating Win32 ABI and PE32 format files.

Nope. That's the simple stuff. Events for signals (that's why MS made the stupid things - as signals and semaphores), and the thread context routines for changing the thread context (that's why MS made them!). I've used both before. I think the build system, ABI, and file formats are MUCH more important issues.

Kalamatee wrote:
Easier to what? all the other hosted environments and the native are supposed to share binaries on a cpu architecture (other than those required for aros to work in the first place) - thats how it currently works.

Also, i think youre greatly underestmating whats needed to get signals and theading working like linux hosted does.

JLF65 wrote:
Yes, you could make it where only AROS.exe was in Windows format, but then you'd need two different build systems - one that built PE format for the host program, then another to build everything else.

It'd be easier in the long run to just add PE support and use one build system for everything like the current Linux build system. At least that's my opinion. I welcome other opinions and suggestions.