#7 Porting To Windows

[Anonymous]

Okay so I see this is for Mac OS and Linux users which
is nice but I dont use either of them unfortunately (yeah i
got suckered into using an Interface to do everything and
i forgot and refuse to memorize command line
commands again :P )

So My questions is has this been already ported to
Windows or would that be something for an aspiring
programmer ?

(i saw a _WIN32_ line in there i am just not sure how
easily its going to compile so i figured i'll post this
question and if i get time to assemble it and mess
around with it i'll take a look at it

Aso does it assume Unicode ? or no

[Eric Seidel]

Logged In: YES
user_id=151346

Currently, I believe there has been some work done to port it to windows,
I would have to look back through my mails first....

See Feature Request # 543404
http://sourceforge.net/tracker/index.php?func=detail&aid=543404&
group_id=41631&atid=430943

It does not assume unicode for WINDOWS, since Audiogalaxy is based
off of the WindowsLatin1 text encoding.... unfortunatly. I use Unicode on
OS X to convert between strings.

On a side note... if you're lookign for a killer interface, which does not
require the memorization of commands... you might check out OS X ;-)
You also have a terminal with a full BSD command set at your disposle
there if you choose. It's UNIX... for the consumer ;-)

-eric

[Eric Seidel]

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!

[Eric Seidel]

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