Browsing this Thread:
1 Anonymous Users
|
Re: plans for win32 port?
|
||||
|---|---|---|---|---|
|
Home away from home
 
|
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.
Posted on: 2004/11/2 5:15
|
|||
|
||||
|
Re: plans for win32 port?
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
Not necessarily. Another possibility is to compile a mingw cross compiler that outputs AROS ELF executables. Staf.
Posted on: 2004/11/1 23:19
|
|||
|
||||
|
Anonymous
|
Re: plans for win32 port?
|
|||
|---|---|---|---|---|
|
sdl would make it very portable...and maybe could avoid the use o X server under linux (not sure)
the only file, afaik, that need to be linked in the host file format is the aros.c (arch/all-hosted/aros.c), you need to change the low level codes...but (at least on i386-win) you can use all the other files (like linux-hosted/native), so maybe instead of add support for the pe32 file format (that could be hard, and it need good build env knowledge), you could build the aros.c (aros.exe) out of the aros build system. one thing i would like to know for a long now, is what is the minimal aros core code for build aros.c....i did try to build it under cygwin, and failed on linking, ld <-> collect-aros pe32 issue. im not sure why the .exe file need to be linked using collect-aros. (does this post makes sense?!?!? in my head yes, but im not sure if it is true) =o\ |
||||
|
||||
|
Re: plans for win32 port?
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
I've thought about SDL - and GLFW as well. Either one would work as a base since they are available for Windows, Linux, and Mac. Quote: the format PE32 should be add in collect-aros, isnt it? I think so. That's the main thing about hosted versions of AROS - you have to support the output format of the host compiler. In Linux and BSD, that's ELF. For Windows, that's PE. For Mac, it's PEF. However, since OSX is based off BSD, it can handle ELF as well.
Posted on: 2004/11/1 20:48
|
|||
|
||||
|
Anonymous
|
Re: plans for win32 port?
|
|||
|---|---|---|---|---|
|
directx, good! have you think about sdl? (would be wider than directx, otoh directx looks nativer in win, thought)
the format PE32 should be add in collect-aros, isnt it? regards, and good luck in your effort! =o) |
||||
|
||||
|
Re: plans for win32 port?
|
||||
|---|---|---|---|---|
|
Home away from home
|
I'm setting up one of my "spare" PCs (an 800 MHZ P3) with Windows. I got all the mingw files and the extras AROS needs (python, bison, etc). I'll have to do a little experimenting, but I did think of another area that needs to be addressed. AROS currently just supports ELF format (as far as I know). Windows executables are not ELF. So I have the specs for Windows executable format. Support needs to be added to AROS for that format as well as anything compiled in mingw will be Windows format.
I've already got DirectX code for video, sound, and input (from other Windows proggies I have done). I already explained how to handle the multitasking. If I can set up the build system and get Windows exe format added, we might get a Windows hosted version going.
Posted on: 2004/11/1 17:48
|
|||
|
||||
|
Anonymous
|
Re: plans for win32 port?
|
|||
|---|---|---|---|---|
|
hum, so when will we have an aros.exe!?!?!? =oP (with or without cygwin.dll or xserver.exe)
|
||||
|
||||
|
Re: plans for win32 port?
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
You're joking, right? That's the EASY part. Just create a thread with a higher priority to wait on all your windows events (dsound, timer, etc...). When the event triggers, the higher priority thread runs. Inside the event handler do this: SuspendThread(arosThread); GetThreadContext(arosThread, currContext); <aros task handling here> SetThreadContext(arosThread, currContext); ResumeThread(arosThread); Then wait on the windows events again. Simple. Standard stuff for windows proggies. You guys must not do too much threaded windows stuff. Actually, it seems to me now that I think of it, the BIG fun is getting the current build system working on a Windows compiler. Your best bet is probably xmingw - set up xmingw on a Linux system for cross-compiling. Your other choice is cygwin in windows. I don't see anyone trying to move the build tools to VS.
Posted on: 2004/10/30 0:02
|
|||
|
||||
|
Re: plans for win32 port?
|
||||
|---|---|---|---|---|
|
Home away from home
|
Quote:
Rubbish ... The ONLY needed things are access to the hosts filesystem (which is TRIVIAL), a basic graphic device (which also is relatively trivial), and to translate input events from the host. I know from "discussion" about the subject on the IRC channel the big hurdle is making the schedular, and signaling work on top of the host (win32 in this case). Hopefully georg or someone is reading and can add more information ...
Posted on: 2004/10/29 22:54
|
|||
|
||||
|
Re: plans for win32 port?
|
||||
|---|---|---|---|---|
|
Home away from home
|
What's holding up a win32 port is all the drivers needed. You need video, audio, filesystem, input, etc...
It's not really HARD work, but it's a lot of work. I could do it pretty easily, but it's making the time that is the hardest part.
Posted on: 2004/10/29 21:24
|
|||
|
||||
You can view topic.
You cannot start a new topic.
You cannot reply to posts.
You cannot edit your posts.
You cannot delete your posts.
You cannot add new polls.
You cannot vote in polls.
You cannot attach files to posts.
You cannot post without approval.
You cannot use topic type.
You cannot use HTML syntax.
You cannot use signature.
You cannot create PDF files.
You cannot get print page.
