Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Jeff Dike <jdike@ka...> - 2001-09-21 02:58:08
> Specifically, I have to do a year long thesis as a computer science
> major at Princeton, and I've found an advisor willing to support the
> UML-Win port. The good part is that, well, I can't graduate if I don't
> accomplish something, so you don't have to worry about my giving up on
> the project.
Heh, that immediately makes you better qualified than most of the other
people that have expressed interest in this :-)
> So, I guess I have two questions:
> - Is this going to be completely duplicating somebody else's work or
> stepping on any toes?
This seems to have woken up all of a sudden, but afaik, no one's writing code.
In any case, in this world, there's no stepping on toes. If you code faster
than the next person, that's not your problem :-)
> - Is there any previous work on a Windows port, or other tips that I
> might've missed?
LINE - http://line.sf.net is a elf binary loader for Windows. That's the core
of a UML/Windows port. (except I just took a look at your page and you already
know about LINE...)
I have some work that was done by Dan Aloni. He got UML to boot to the point
of trying to create a kernel thread. I'll make it available if you want it.
It's probably not directly usable since it's extremely old at this point,
and, in order to get that far, Don took a ton of shortcuts which will have
to be undone.
As far as the design of this goes, any OS port (and especially an OS that's not
Unix-like) will require separating OS-specific stuff from everything else.
So, I'm planning on a separate hierarchy for that stuff that ultimately might
where each of the os subdirectories implements an interface that provides
whatever UML needs from the OS. And os/posix will implement the stuff
provided by POSIX, and os/posix/* will implement the strange non-POSIX stuff
needed from each of those OS-es.