Re: [wx-dev] Reviving the AmigaOS port
45 views
Skip to first unread message
Vadim Zeitlin
Nov 12, 2012, 12:57:17 PM11/12/12
to wx-...@googlegroups.com
On Mon, 12 Nov 2012 05:44:14 -0800 (PST) Andreas Stenmark wrote:
AS> I'm new to this list and this is my first post.
Hello and welcome!
AS> I've been able to build wxBase from 2.9.4 without too much trouble. I
AS> didn't actually need to add any code for this, just minor changes to
AS> headers, [mb]akefile stuff and config. So far it probably doesn't do
AS> anything useful, I've just verified that it builds. At some point I'd like
AS> to merge the modifications with trunk and submit a basic port for
AS> consideration. My first question is at what point this would make sense?
If the modifications are relatively small, this could be done soon and
before 3.0. For anything more involved I'd like to wait until this port
becomes at least somewhat useful if possible.
AS> My second question would be regarding the basic approach to the port.
AS> AmigaOS isn't really POSIX, but providing a basic POSIX glue layer is
AS> simple enough. A bsd socket layer is also straightforward. GUI/graphics
AS> stuff would mostly need to be native, though going via wxUniv might make
AS> the path easier.
Unfortunately wxUniv is not in a great shape on its own, but, still, using
it at least initially should be indeed easier. And if you can fix some of
the problems in wxUniv while working on this port, it would certainly be
very welcome.
AS> The build system is gcc/newlib/stdlibc++ on Linux or Cygwin which gives
AS> easy access to other build tools as needed. Does all this make sense
AS> from a wxWidgets perspective?
Yes. A possibility to cross-compile from Linux is very nice in practice
because it would allow others to at least check that this port compiles.
AS> Are there any particular known stumbling blocks for ports to non-Unix
AS> systems?
I think that having POSIX glue qualifies it as Unix (we really should have
used "posix" instead of "unix" everywhere). You may need to do something
different for wxEventLoop but as I have no idea about Amiga OS API I really
can't say anything useful about it.
AS> I know things like process and memory management sometimes provides
AS> challenges -- meaning fork()/sbrk() concepts don't map too well to
AS> AmigaOS, though the similar vfork()/mmap() would work better.
This is not used by wx, so you can implement wxExecute() in some other
way if it's simpler. Also, in the grand scheme of things, wxExecute() is a
tiny piece of the library and is nothing compared to the GUI work.
AS> Thread locking, IPC and dynamic modules would be some other potential
AS> challenges that I can think of.
You could start building with wxUSE_THREADS=0 and wxUSE_DYNLIB_CLASS=0 and
leave threads and dynamic modules for later. System V IPC is not used by wx
so it's not a problem.
BTW, generally speaking you should use --disable-all-features initially to
build as small version of the library as possible. Then you can start
enabling the features you implement one by one.
AS> But similar challenges should have been solved for Win32, right?
Yes, it has its own implementation of all these classes in src/msw.
AS> Anything in this basic plan I should reconsider? What else do I need to
AS> think about before starting?
Looking at the existing ports would be a good idea, but it's true that
there are no other non-Unix ports than wxMSW. wxDFB is the simplest one of
wxUniv-based ports. Of course, you will have plenty of questions about wx
and you shouldn't hesitate asking them here.
Good luck!
VZ
AS> I'm new to this list and this is my first post.
Hello and welcome!
AS> I've been able to build wxBase from 2.9.4 without too much trouble. I
AS> didn't actually need to add any code for this, just minor changes to
AS> headers, [mb]akefile stuff and config. So far it probably doesn't do
AS> anything useful, I've just verified that it builds. At some point I'd like
AS> to merge the modifications with trunk and submit a basic port for
AS> consideration. My first question is at what point this would make sense?
If the modifications are relatively small, this could be done soon and
before 3.0. For anything more involved I'd like to wait until this port
becomes at least somewhat useful if possible.
AS> My second question would be regarding the basic approach to the port.
AS> AmigaOS isn't really POSIX, but providing a basic POSIX glue layer is
AS> simple enough. A bsd socket layer is also straightforward. GUI/graphics
AS> stuff would mostly need to be native, though going via wxUniv might make
AS> the path easier.
Unfortunately wxUniv is not in a great shape on its own, but, still, using
it at least initially should be indeed easier. And if you can fix some of
the problems in wxUniv while working on this port, it would certainly be
very welcome.
AS> The build system is gcc/newlib/stdlibc++ on Linux or Cygwin which gives
AS> easy access to other build tools as needed. Does all this make sense
AS> from a wxWidgets perspective?
Yes. A possibility to cross-compile from Linux is very nice in practice
because it would allow others to at least check that this port compiles.
AS> Are there any particular known stumbling blocks for ports to non-Unix
AS> systems?
I think that having POSIX glue qualifies it as Unix (we really should have
used "posix" instead of "unix" everywhere). You may need to do something
different for wxEventLoop but as I have no idea about Amiga OS API I really
can't say anything useful about it.
AS> I know things like process and memory management sometimes provides
AS> challenges -- meaning fork()/sbrk() concepts don't map too well to
AS> AmigaOS, though the similar vfork()/mmap() would work better.
This is not used by wx, so you can implement wxExecute() in some other
way if it's simpler. Also, in the grand scheme of things, wxExecute() is a
tiny piece of the library and is nothing compared to the GUI work.
AS> Thread locking, IPC and dynamic modules would be some other potential
AS> challenges that I can think of.
You could start building with wxUSE_THREADS=0 and wxUSE_DYNLIB_CLASS=0 and
leave threads and dynamic modules for later. System V IPC is not used by wx
so it's not a problem.
BTW, generally speaking you should use --disable-all-features initially to
build as small version of the library as possible. Then you can start
enabling the features you implement one by one.
AS> But similar challenges should have been solved for Win32, right?
Yes, it has its own implementation of all these classes in src/msw.
AS> Anything in this basic plan I should reconsider? What else do I need to
AS> think about before starting?
Looking at the existing ports would be a good idea, but it's true that
there are no other non-Unix ports than wxMSW. wxDFB is the simplest one of
wxUniv-based ports. Of course, you will have plenty of questions about wx
and you shouldn't hesitate asking them here.
Good luck!
VZ
Andreas Stenmark
Nov 12, 2012, 3:36:49 PM11/12/12
to wx-...@googlegroups.com
Hey,
On Monday, November 12, 2012 6:57:28 PM UTC+1, VZ wrote:
On Monday, November 12, 2012 6:57:28 PM UTC+1, VZ wrote:
On Mon, 12 Nov 2012 05:44:14 -0800 (PST) Andreas Stenmark wrote:
AS> anything useful, I've just verified that it builds. At some point I'd like
AS> to merge the modifications with trunk and submit a basic port for
AS> consideration. My first question is at what point this would make sense?
If the modifications are relatively small, this could be done soon and
before 3.0. For anything more involved I'd like to wait until this port
becomes at least somewhat useful if possible.
So far they are trivial, essentially adding another platform symbol and checking for it mostly in spots where there is already conditional compilation for other platforms. Adding new platform directories under include and src with some content is also clearly necessary but doesn't seem intrusive. Whether or not it will stop at that -- I can't say at the moment. From my perspective, the main utility of having the port integrated is when others can review the changes and give meaningful feedback -- I'm certainly not at that point yet. I'll start working on the port privately for now, and see where it leads.
What would you consider somewhat useful? Can a port embryo be somewhat useful before it has a GUI?
AS> My second question would be regarding the basic approach to the port.
AS> AmigaOS isn't really POSIX, but providing a basic POSIX glue layer is
AS> simple enough. A bsd socket layer is also straightforward. GUI/graphics
AS> stuff would mostly need to be native, though going via wxUniv might make
AS> the path easier.
Unfortunately wxUniv is not in a great shape on its own, but, still, using
it at least initially should be indeed easier. And if you can fix some of
the problems in wxUniv while working on this port, it would certainly be
very welcome.
This is certainly possible. My main concern at the moment is finding a reasonable starting direction, and drawing on the experience of others. If going via wxUniv is likely to be more useful than not, then that's what I'll do. If it's in such bad shape that I'm just creating trouble for myself, then I'd prefer to know now. I did a test build of wxUniv for... MSW or GTK, I can't actually remember which (which is actually pretty cool, and proves to me that wx works!). But from what I recall it was... mostly working. Either way, if I go that route I'll be happy to supply patches for any issues I find and fix.
AS> Are there any particular known stumbling blocks for ports to non-Unix
AS> systems?
I think that having POSIX glue qualifies it as Unix (we really should have
used "posix" instead of "unix" everywhere). You may need to do something
different for wxEventLoop but as I have no idea about Amiga OS API I really
can't say anything useful about it.
The wxEventLoop certainly needs "something different" (I don't know what yet). AmigaOS uses well known concepts of signals, messages and things, and window/widget events are sort of similar to Win32, so it may not be all that different in principle. (though a fair bit different in implementation) The POSIX API is not rich enough to cover AmigaOS specifics, but it's a decent starting point and implementing native specifics can be done later.
AS> I know things like process and memory management sometimes provides
AS> challenges -- meaning fork()/sbrk() concepts don't map too well to
AS> AmigaOS, though the similar vfork()/mmap() would work better.
This is not used by wx, so you can implement wxExecute() in some other
way if it's simpler. Also, in the grand scheme of things, wxExecute() is a
tiny piece of the library and is nothing compared to the GUI work.
Ok good, this clearly won't be an issue.
AS> Anything in this basic plan I should reconsider? What else do I need to
AS> think about before starting?
Looking at the existing ports would be a good idea, but it's true that
there are no other non-Unix ports than wxMSW. wxDFB is the simplest one of
wxUniv-based ports. Of course, you will have plenty of questions about wx
and you shouldn't hesitate asking them here.
Lol. Cross-platform development would suddenly get a whole lot easier if Windows would also move to a Unix base, right? ;-)
I will probably take inspiration from most of the other main ports. I don't know if any single one is a good starting template, but all of them seem to have some portions that are relevant. But hey, aren't there DOS and OS/2 ports in the distribution? I didn't look too closely but I thought wxDFB was for DOS. Maybe I need to look again?
Thanks for your response. Guidance will be useful, especially in the beginning. Hopefully it won't be too long before I can provide something useful back, whether or not it's related to this particular port.
//Andreas
Vadim Zeitlin
Nov 13, 2012, 9:50:55 AM11/13/12
to wx-...@googlegroups.com
On Mon, 12 Nov 2012 12:36:49 -0800 (PST) Andreas Stenmark wrote:
AS> So far they are trivial, essentially adding another platform symbol and
AS> checking for it mostly in spots where there is already conditional
AS> compilation for other platforms. Adding new platform directories under
AS> include and src with some content is also clearly necessary but doesn't
AS> seem intrusive. Whether or not it will stop at that -- I can't say at the
AS> moment. From my perspective, the main utility of having the port
AS> integrated is when others can review the changes and give meaningful
AS> feedback -- I'm certainly not at that point yet. I'll start working on the
AS> port privately for now, and see where it leads.
FWIW if you're familiar with git I'd recommend putting it on Github, it
would make it easier to merge later as our git mirror is hosted there too
(of course, you should start by forking it).
AS> What would you consider somewhat useful? Can a port embryo be somewhat
AS> useful before it has a GUI?
In principle yes, although in practice I don't know if it's going to be
very useful in this case.
AS> This is certainly possible. My main concern at the moment is finding a
AS> reasonable starting direction, and drawing on the experience of others. If
AS> going via wxUniv is likely to be more useful than not, then that's what
AS> I'll do. If it's in such bad shape that I'm just creating trouble for
AS> myself, then I'd prefer to know now.
It's not in a shape good enough for anything but very simple programs
taking care to avoid all the problematic areas. But it should still allow
you to at least check that wxWindow, wxEventLoop, wxDC &c implementations
that you will have to write anyhow, whether you use wxUniv or not at the
end, do work. So yes, I'd still start with it, even knowing that you'd need
to switch to native widgets sooner or later. The important thing is that
you wouldn't lose any time doing this because the classes needed by wxUniv
are needed by the native port too anyhow.
AS> I will probably take inspiration from most of the other main ports. I
AS> don't know if any single one is a good starting template,
wxMSW is, for good or bad, probably the one you should take as template.
It still has a few parts that were never updated but mostly it's in a
decent shape (if you see that the file hasn't been changed much since 1997
or so, it's usually a good indication that you shouldn't copy it blindly).
AS> But hey, aren't there DOS and OS/2 ports in the distribution?
wxMGL used DOS but it was recently removed because it was completely dead
since many years. wxPM (OS/2) is still in the svn but I honestly have no
idea how alive is it.
AS> I didn't look too closely but I thought wxDFB was for DOS. Maybe I
AS> need to look again?
No, wxDFB is based on DirectFB which works under Unix only to the best of
my knowledge.
AS> Thanks for your response. Guidance will be useful, especially in the
AS> beginning. Hopefully it won't be too long before I can provide something
AS> useful back, whether or not it's related to this particular port.
Re-good luck!
VZ
AS> So far they are trivial, essentially adding another platform symbol and
AS> checking for it mostly in spots where there is already conditional
AS> compilation for other platforms. Adding new platform directories under
AS> include and src with some content is also clearly necessary but doesn't
AS> seem intrusive. Whether or not it will stop at that -- I can't say at the
AS> moment. From my perspective, the main utility of having the port
AS> integrated is when others can review the changes and give meaningful
AS> feedback -- I'm certainly not at that point yet. I'll start working on the
AS> port privately for now, and see where it leads.
FWIW if you're familiar with git I'd recommend putting it on Github, it
would make it easier to merge later as our git mirror is hosted there too
(of course, you should start by forking it).
AS> What would you consider somewhat useful? Can a port embryo be somewhat
AS> useful before it has a GUI?
In principle yes, although in practice I don't know if it's going to be
very useful in this case.
AS> This is certainly possible. My main concern at the moment is finding a
AS> reasonable starting direction, and drawing on the experience of others. If
AS> going via wxUniv is likely to be more useful than not, then that's what
AS> I'll do. If it's in such bad shape that I'm just creating trouble for
AS> myself, then I'd prefer to know now.
It's not in a shape good enough for anything but very simple programs
taking care to avoid all the problematic areas. But it should still allow
you to at least check that wxWindow, wxEventLoop, wxDC &c implementations
that you will have to write anyhow, whether you use wxUniv or not at the
end, do work. So yes, I'd still start with it, even knowing that you'd need
to switch to native widgets sooner or later. The important thing is that
you wouldn't lose any time doing this because the classes needed by wxUniv
are needed by the native port too anyhow.
AS> I will probably take inspiration from most of the other main ports. I
AS> don't know if any single one is a good starting template,
wxMSW is, for good or bad, probably the one you should take as template.
It still has a few parts that were never updated but mostly it's in a
decent shape (if you see that the file hasn't been changed much since 1997
or so, it's usually a good indication that you shouldn't copy it blindly).
AS> But hey, aren't there DOS and OS/2 ports in the distribution?
wxMGL used DOS but it was recently removed because it was completely dead
since many years. wxPM (OS/2) is still in the svn but I honestly have no
idea how alive is it.
AS> I didn't look too closely but I thought wxDFB was for DOS. Maybe I
AS> need to look again?
No, wxDFB is based on DirectFB which works under Unix only to the best of
my knowledge.
AS> Thanks for your response. Guidance will be useful, especially in the
AS> beginning. Hopefully it won't be too long before I can provide something
AS> useful back, whether or not it's related to this particular port.
Re-good luck!
VZ
Andreas Stenmark
Nov 14, 2012, 8:27:55 AM11/14/12
to wx-...@googlegroups.com
On Tuesday, November 13, 2012 3:50:56 PM UTC+1, VZ wrote:
FWIW if you're familiar with git I'd recommend putting it on Github, it
would make it easier to merge later as our git mirror is hosted there too
(of course, you should start by forking it).
So far I'm using a local svn repository. At the moment I'm not too worried about any merging challenges, even just a unified diff against trunk should be small and apply without difficulty. It will be a little while before I have anything significant to share though. I haven't actually used git before, but if it ends up adding some value to use it I'll be happy to adapt.
wxMSW is, for good or bad, probably the one you should take as template.
It still has a few parts that were never updated but mostly it's in a
decent shape (if you see that the file hasn't been changed much since 1997
or so, it's usually a good indication that you shouldn't copy it blindly).
Ok thanks, that's useful advice.
Would there be any value in trying to capture some of the things I discover along the way? In the hope of making porting wx slightly easier for someone else who might come along? I've just been through porting newlib, and it turned out to be very easy in comparison. It has a smaller scope obviously so some of the difference is natural. But there are also pretty good tutorials available and skeleton libs that more or less let you kickstart a port with almost no effort at all. Some of that is available for wx too, but with whatever docs I've been able to find the starting threshold is higher for wx. Or maybe AmigaOS is the last non-Unix platform that wx would need significant porting effort for, and documenting the process would serve little purpose?
What would be your guidance?
I think I may put up a log page somewhere anyway to write a little about progress, but that would probably be more for casual entertainment rather than actually technically helpful. Though it could be amusing even for experienced wx'ers to follow along as I stumble through beginner errors (like getting the command line switches in the wrong order which gave me some trouble yesterday) ;-)
//A.
Vadim Zeitlin
Nov 14, 2012, 8:39:12 AM11/14/12
to wx-...@googlegroups.com
On Wed, 14 Nov 2012 05:27:55 -0800 (PST) Andreas Stenmark wrote:
AS> I haven't actually used git before, but if it ends up adding some value
AS> to use it I'll be happy to adapt.
Let's say that nobody of all people I know who used to use svn and tried
git can contemplate going back to svn for a single moment.
AS> Would there be any value in trying to capture some of the things I discover
AS> along the way?
Yes, sure.
AS> Or maybe AmigaOS is the last non-Unix platform that wx would need
AS> significant porting effort for, and documenting the process would serve
AS> little purpose?
Last non-Unix maybe (there are just few non-Unix systems left, the only
one I can think about is Haiku), but definitely not last. So anything you
can do to make creating new GUI ports easier would be very welcome.
AS> I think I may put up a log page somewhere anyway to write a little about
AS> progress, but that would probably be more for casual entertainment rather
AS> than actually technically helpful.
If you do start, please post your [b]log page URL here, I'd follow it with
interest for one. You could also post to wxBlog about this if you'd like.
Regards,
VZ
AS> I haven't actually used git before, but if it ends up adding some value
AS> to use it I'll be happy to adapt.
Let's say that nobody of all people I know who used to use svn and tried
git can contemplate going back to svn for a single moment.
AS> Would there be any value in trying to capture some of the things I discover
AS> along the way?
Yes, sure.
AS> Or maybe AmigaOS is the last non-Unix platform that wx would need
AS> significant porting effort for, and documenting the process would serve
AS> little purpose?
Last non-Unix maybe (there are just few non-Unix systems left, the only
one I can think about is Haiku), but definitely not last. So anything you
can do to make creating new GUI ports easier would be very welcome.
AS> I think I may put up a log page somewhere anyway to write a little about
AS> progress, but that would probably be more for casual entertainment rather
AS> than actually technically helpful.
If you do start, please post your [b]log page URL here, I'd follow it with
interest for one. You could also post to wxBlog about this if you'd like.
Regards,
VZ
Andreas Stenmark
Nov 14, 2012, 8:49:17 AM11/14/12
to wx-...@googlegroups.com
Ok, will do.
//A.
wsu
Nov 20, 2012, 9:50:08 PM11/20/12
to wx-...@googlegroups.com
On Wednesday, November 14, 2012 8:39:17 AM UTC-5, VZ wrote:
On Wed, 14 Nov 2012 05:27:55 -0800 (PST) Andreas Stenmark wrote:
AS> I haven't actually used git before, but if it ends up adding some value
AS> to use it I'll be happy to adapt.
Let's say that nobody of all people I know who used to use svn and tried
git can contemplate going back to svn for a single moment.
For what it's worth, I like SVN a lot, but I find Git completely opaque.
Vadim Zeitlin
Nov 21, 2012, 6:26:26 AM11/21/12
to wx-...@googlegroups.com
On Tue, 20 Nov 2012 18:50:08 -0800 (PST) wsu wrote:
w> For what it's worth, I like SVN a lot, but I find Git completely opaque.
Yes, this is understandable. One thing nobody can argue with is that Git
has a steep learning curve. But, again, once you're over the hump and start
being able to use Git comfortably, going back to svn is unthinkable[*]. So
it's a question of whether you're prepared to struggle with it a bit for a
couple of weeks for the benefits in the future. Personally I think it's
well, well worth it.
Regards,
VZ
[*] At least voluntarily.
w> For what it's worth, I like SVN a lot, but I find Git completely opaque.
Yes, this is understandable. One thing nobody can argue with is that Git
has a steep learning curve. But, again, once you're over the hump and start
being able to use Git comfortably, going back to svn is unthinkable[*]. So
it's a question of whether you're prepared to struggle with it a bit for a
couple of weeks for the benefits in the future. Personally I think it's
well, well worth it.
Regards,
VZ
[*] At least voluntarily.
Reply all
Reply to author
Forward
0 new messages