Windows Port
Brought to you by:
macdome
Menu
▾
▴
Logged In: YES
user_id=464825
I spent some-time on this subject. A port to win32 is a
problematic port, espacially when using network. You are
opening files in a non-blocking mode, and select on them
together with sockets, which is O.K. on POSIX, but doesn't
work on win32. You are using glob, which doesn't exist in
win32 (although there are simillar functions, and it is
possible to work around this one)
You are setting signal handlers in a way which Borland's
C++Builder doesn't support.
There is a large amount of other subjects wich makes this
port difficult.
For a summary, a large amount of work is needed here, and it
begins with setting an abstract locking on the network
buffers, so that it will be possible to handle the files on
a seperate thread.
Logged In: YES
user_id=151346
This comes from an email from Andre' Braga:
Hi,
First of all, thanks! OpenAG rules =)
But, unfortunately, when trying to port it to Win32/Cygwin it
I ran into a
few problems:
Every call to bzero is lacking a cast to char*... this is immediately
solved
by replacing every occurence of "bzero(" to "bzero(
(char*)".
Hardcoding the directories as #define's is totally evil. They
should be
private strings inside a object, maybe instances of a class called
Prefs,
with proper get() and set() functions. Having them as #define's
who act
like globals will make it impossible for you to easily change
the
download/temp dirs, and it also makes it more difficult to port
to non-
Unix environments. Also, using ~/ instead of getenv("HOME")
makes
portability to win32 systems impossible (yeah, win32 sucks, but
sometimes this is all you have...)
I did some preliminary changes and I'm willing to commit code,
but I
don't know how to use CVS/diff and it would be quite a big change
to
your code, which would require major clean-ups and probably a
good
amount of redesign, and I don't feel I'm up to the task since
I'm not
familiar to the code and probably lack the right skills...
Anyway, I'd like to suggest a different layour for your code,
in order to
enhance its mantainability:
- class Net: communicating to the network
(dealing with sockets and other OS dependencies on networks,
providing hooks to the Protocols class)
- class Protocols: intermediating your files and the network
(encapsulating data and control messages in the format
that the protocol defines)
- class Files: manipulating files
Low-level:
+ Superclass to implement I/O
o To/from disk
o To/from the network
High-level:
+ child class to handle the preferences file
(read and set attibutes, flush to disk on destruction)
+ child class to handle the database and resume files
(same as above)
+ child class to handle MP3 files
(read to Net, write to disk)
This layout gives a pretty clean approach to the iTunes integration
you
intended, and I don't think there will be any significant overhead.
Also,
it's generic enough so you could build other protocols on top
of it, and
turning it into a server should be straightforward (or at least
somewhat
easier ;).
I could help you but it would take some time... I wouldn't like
to start it
myself because you probably have protocol enhancements and bugfixes
to commit.
Let me know what you think.
Cheers!
Logged In: YES
user_id=151346
Thank you for your suggestions.
I am still looking for someone to head up the windows port... if you think
you might be up to the challenge... ;-)
I have added your comments to the two tracker items currently open for
this issue. I might suggest you monitor both:
http://sourceforge.net/tracker/index.php?func=detail&aid=543404&
group_id=41631&atid=430943
http://sourceforge.net/tracker/index.php?func=detail&aid=561938&
group_id=41631&atid=430941
I have also created a Sub Project, and if you are willing to help plan, you
might consider adding tasks to that sub-project. I may have to give you
access to it first... in that case, you would need a sourceforge login..
which is easy enough to come by.
I am certainly planning on rolling in some of your suggested changes in
teh coming version of OpenAG... all of them may take more redesign
than I am ready for at the moment... and will require a dedicated person,
and a clear plan to execute.
Regarding your preliminary changes... Go ahead and run a cvs update (if
possible) and then a cvs diff > diff_file_for_eric.txt I would love to see
what you've changed... that would make my roll-ins much quicker.
There have been some serious changes to the code organization in the
past week.. be particularly careful, if you've made changes to
ParseMessage.cpp... since some of the code from there has been
moved out in recent attempts to eliminate dependencies on teh v520L
client protocol.
you might want to run a cvs update -d first to check what it would
change..
Thanks again.
Sincerely,
Eric Seidel
Lead Programmer, OpenAGs Project
-----------------------------------
OpenAG/OpenAG X Homepage:
http://www.openag.org/
Contributions to the OpenAG Project can also be made at:
http://www.openag.org/
OpenAGs Project Page:
http://sourceforge.net/projects/openags/
OpenAGs Lists -- Announce, Testers, Ports and Translators:
http://lists.sourceforge.net/lists/listinfo/openags-announce
http://lists.sourceforge.net/lists/listinfo/openags-testers
http://lists.sourceforge.net/lists/listinfo/openags-ports
http://lists.sourceforge.net/lists/listinfo/openags-translators
Logged In: NO
Actually I think it is very easy to port. Because the only thing
that is really crucial is the protocol. The Framework does
need to be rewriten completely as Windows is a completely
different system.
I have started with the port by identifying functions that
a) Are currently not needed
b) Provide extra functionality that can be added l8r
c) the functions that are critical.
I believe the next function I will be attacking will be the Login
Subroutine