The point of doing this is to show that developers, both commercial and non-commercial, can and should use unix based systems as their primary target. The code, in most cases, can be easily recompiled on Windows and thus, you do no eliminate that market segment for your applications. That is the point... clear and simple.
The source code was downloaded from the net. I used./configure --target=i686-pc-sysv4 --host=i686-pc-sysv4 to generate the makefiles.
The I ran make, make check, and make install. That is how I got all the code to compile.
The unix api calls go to the posix.dll, which then uses standard win32 api calls to provide the functionality.
gnome requires an X11 server, which we did not have. We purchased a commercial server so that we could test out our implementation. We use their X server, but the xlibs and headers from www.x.org.
The reason it took 1.5 weeks was that I had no prior experience in building gnome or the applications like gnucash, glimmer, gmanedit, and others.
It took a fair amount of effort to find all the source code we needed, download the code, and run the configure script. Then make, make check, and make install.
when I would port a specific app, I then had to go fetch and build a supporting tool, such as swig. I never even heard of swig before this:)
The whole point of doing this was not to show off Gnome, but to stress to the industry that you can, and should, develop applications on unix based systems and then port to windows where appropriate. Commercial app developers too frequently go the other way. They start by developing for Windows, and then say... ohh.. the cost of porting to unix based systems is too prohibitive. Then get a clue... develop for unix based sysems first! That was the whole point of doing this.
If we had more time and money, I would have ported KDE so as not to favor one abstraction over the other.
This first release should be viewed as a beta release. To run, simply start a kornshell console window, and then type in:
$ gnome-session
You will need the X11 server running. For test purposes, we linked the commercial X11 server to:
/usr/X11/bin/X
So we first run
$ X &
and then start gnome-session.
The U/WIN code is a win32 application providing the console screen. From the kornshell prompt, you can type in any of the supported commands, or, start win32 applications.
One thing that was pretty cool was being able to type in the pathname for the netscape.exe from the gmc run applet.
U/WIN does not include an X11 server. There are multiple choices here, though for open source servers, and commercial servers. If somebody can provide an open source version, we will gladly point to it, or even host the project from our site.
The whole point of doing this is to show that you can select aix/bsd/linux/solaris/unix systems as the primary development platform and still target the windows market. While a kernel develop may not necessarily care, an application developer should.
There is no doubt that linux is great! We have about 12 different releases here, and we use them.
We also use BSD.
But I am really tired of the notion that commercial shops, needing to maintain a high ROI, must select windows as the development platform of choice, at the expense of the Unix base market.
Porting code from Win32 to Unix is a nightmare. Yes, there are tools available, but they are expensive and they let you maintain your Win32 API.
I want to write unix based applications, and not have to rewrite them for Windows. It is just too expensive to maintain multiple code branches. The cost of duplicating design, development, maintenance, and support is high enough that many companies will develop exclusive for only one OS market segment.
Why did we select GNOME? Mostly because it was there. We could have ported KDE just as easily (I hope:)
We also ported many of the other applications, such as gnucash, which does not need gnome to run.
In fact, most of the applications included can run without the GNOME desktop even being started.
It was more the point of software portability.
I have posted more info about the X11 off of our download page. Hopefully, the Cygwin X11 server will be available soon, and it can be used instead.
As for U/WIN itself being a commercial application, the answer is, yes it is. And yes, we do sell it. However, you can download it from the AT&T Research site under the research or educational license, and there is no fee.
The effort to compile the GNOME code did take 1.5 weeks. A fair portion of that was just trying to find the right source code. The supporting environment (i.e., glade, gtk, swig, and others) were easy to port as well. It was also nice to see gnu-cash port so easily.
Tools such as gnumeric did not port because we could not get the header files straight. Specifically this relates to the font headers.
The package I really wanted to port was screem. We had problems with the callbacks and signals. Hopefully we can get that straightend out.
--charlie northrup
PS. We are a very small company and have been working with u/win for about 2 years now. Early adaptors had mixed success. For quite awhile, we were going through the release of the day. This was troublesom. When u/win 2.2 baseline came about, we forked the code from the AT&T release so that we could work on the terminal line drivers, while David and his team worked on other areas. We are now working to integrate all those changes.
Slashdot Mirror
The point of doing this is to show that developers, both commercial and non-commercial, can and should use unix based systems as their primary target. The code, in most cases, can be easily recompiled on Windows and thus, you do no eliminate that market segment for your applications. That is the point... clear and simple.
The source code was downloaded from the net. I used ./configure --target=i686-pc-sysv4 --host=i686-pc-sysv4 to generate the makefiles.
The I ran make, make check, and make install. That is how I got all the code to compile.
The unix api calls go to the posix.dll, which then uses standard win32 api calls to provide the functionality.
gnome requires an X11 server, which we did not have. We purchased a commercial server so that we could test out our implementation. We use their X server, but the xlibs and headers from www.x.org.
--charlie
The reason it took 1.5 weeks was that I had no prior experience in building gnome or the applications like gnucash, glimmer, gmanedit, and others.
It took a fair amount of effort to find all the source code we needed, download the code, and run the configure script. Then make, make check, and make install.
when I would port a specific app, I then had to go fetch and build a supporting tool, such as swig. I never even heard of swig before this:)
The whole point of doing this was not to show off Gnome, but to stress to the industry that you can, and should, develop applications on unix based systems and then port to windows where appropriate. Commercial app developers too frequently go the other way. They start by developing for Windows, and then say... ohh.. the cost of porting to unix based systems is too prohibitive. Then get a clue... develop for unix based sysems first! That was the whole point of doing this.
If we had more time and money, I would have ported KDE so as not to favor one abstraction over the other.
--charlie northrup
This first release should be viewed as a beta release. To run, simply start a kornshell console window, and then type in:
$ gnome-session
You will need the X11 server running. For test purposes, we linked the commercial X11 server to:
/usr/X11/bin/X
So we first run
$ X &
and then start gnome-session.
The U/WIN code is a win32 application providing the console screen. From the kornshell prompt, you can type in any of the supported commands, or, start win32 applications.
One thing that was pretty cool was being able to type in the pathname for the netscape.exe from the gmc run applet.
--charlie northrup
U/WIN does not include an X11 server. There are multiple choices here, though for open source servers, and commercial servers. If somebody can provide an open source version, we will gladly point to it, or even host the project from our site.
--charlie northrup
The whole point of doing this is to show that you can select aix/bsd/linux/solaris/unix systems as the primary development platform and still target the windows market. While a kernel develop may not necessarily care, an application developer should.
There is no doubt that linux is great! We have about 12 different releases here, and we use them.
We also use BSD.
But I am really tired of the notion that commercial shops, needing to maintain a high ROI, must select windows as the development platform of choice, at the expense of the Unix base market.
Porting code from Win32 to Unix is a nightmare. Yes, there are tools available, but they are expensive and they let you maintain your Win32 API.
I want to write unix based applications, and not have to rewrite them for Windows. It is just too expensive to maintain multiple code branches. The cost of duplicating design, development, maintenance, and support is high enough that many companies will develop exclusive for only one OS market segment.
Why did we select GNOME? Mostly because it was there. We could have ported KDE just as easily (I hope:)
We also ported many of the other applications, such as gnucash, which does not need gnome to run.
In fact, most of the applications included can run without the GNOME desktop even being started.
It was more the point of software portability.
I have posted more info about the X11 off of our download page. Hopefully, the Cygwin X11 server will be available soon, and it can be used instead.
As for U/WIN itself being a commercial application, the answer is, yes it is. And yes, we do sell it. However, you can download it from the AT&T Research site under the research or educational license, and there is no fee.
The effort to compile the GNOME code did take 1.5 weeks. A fair portion of that was just trying to find the right source code. The supporting environment (i.e., glade, gtk, swig, and others) were easy to port as well. It was also nice to see gnu-cash port so easily.
Tools such as gnumeric did not port because we could not get the header files straight. Specifically this relates to the font headers.
The package I really wanted to port was screem. We had problems with the callbacks and signals. Hopefully we can get that straightend out.
--charlie northrup
PS. We are a very small company and have been working with u/win for about 2 years now. Early adaptors had mixed success. For quite awhile, we were going through the release of the day. This was troublesom. When u/win 2.2 baseline came about, we forked the code from the AT&T release so that we could work on the terminal line drivers, while David and his team worked on other areas. We are now working to integrate all those changes.