To update your Cygwin installation all you have to do is rerun Cygwin's setup.exe. It will show you which packages have updates and it selects them automatically for updating (if you had them installed before). It is really easy.
We've been looking for someone to run some comprehensive x11perf tests for Cygwin/XFree86 and a couple of the commercial X Servers for MS Windows. We would appreciate it very much if you could send the output files from x11perf (or better yet, links to the output files) to the `cygwin-xfree at cygwin daught com' mailing list.
You may want to check out the new `-clipupdates num_boxes' parameter, which gathers together num_boxes or more regions into a GDI clipping region and then does one bit block transfer to the screen, rather than one bit block transfer per damaged region. I'm guessing that `-clipupdates 10' or `-clipupdates 50' would give a good return on the overhead that is involved in creating a GDI clipping region.
Your problem with NetMeeting is that NetMeeting and Cygwin/XFree86 are both using DirectDraw. Apparently only one application is allowed to use a certain feature of DirectDraw at a time. By default Cygwin/XFree86 is using the DirectDraw Non-Locking engine, which you could specify with `-engine 4'; non-locking means that we call malloc () ourselves for the offscreen framebuffer, rather than letting DirectDraw allocate the memory for us. You can try passing `-engine 2' for DirectDraw with DirectDraw allocated surface memory, or `-engine 1' which uses GDI DIBs with no DirectDraw at all.
I'm positive that `-engine 1' will work, but if `-engine 2' works it should have better performance than `-engine 1'.
I am the project leader for Cygwin/XFree86 and I can tell you that we have never, ever, heard of such a failure. Please mail a detailed report to the Cygwin/XFree86 mailing list (cygwin-xfree at cygwin daught com). We would really like to fix this problem if it could happen to other users.
You have to either put Windows into 8 bit color mode, or you have to run with the -depth 8 and -fullscreen parameters (the -depth parameter is only used when -fullscreen is specified). Otherwise, you aren't really running Cygwin/XFree86 in 8 bit color mode. You can verify this by running `xdpyinfo' from an xterm... at the bottom it should tell you the depth of your visual.
On a side note, we are working on adding PseudoColor support to TrueColor visuals. This may take some time, but the end result would be that your VLSI tool would run even when you are running Windows in 15, 16, 24, or 32 bit color.
Yes, you can install Cygwin/XFree86 without admin rights on Windows NT/2000/XP. All you have to do is select ``Just Me'' in the ``Install For'' option on about the third screen in setup.exe.
Cygwin/XFree86 has been working on all recent versions of Windows (95/98/Me and NT 4.0/2000/XP) since somewhere around March of 2001. The real news here is that we finally became installable via Cygwin's setup.exe program in May of 2002.
Current features we are working on include:
Native GDI Server - Translate X11 graphics calls into GDI graphics calls; currently we just draw to an offscreen framebuffer and transfer updates occasionally. This allows you to utilize the power of your $100+ graphics processor. Most respectable commercial X11 servers for MS Windows use this method.
Clipboard integration - We have been working on this for a long time. Currently we have a seperate client, called xwinclip, that provides this functionality. We recently added support for passing Japanese text through xwinclip when running on NT/2000/XP.
PseudoColor for TrueColor visuals - A lot of applications, particularly drawing or CAD programs, require a palette-based PseudoColor visual, while most people run Windows in TrueColor depths of 15, 16, 24, or 32 bit color. We would like to support PseudoColor visuals when our primary visual is a TrueColor visual. Some commercial X11 servers for MS Windows do this.
Go ahead and try Cygwin/XFree86 if you haven't already. We hope you like it. If you find some missing feature that you would like, then take a look at our source code and read our Contributor's Guide for instructions on how to download the source and build the tree, plus a general discussion of the technologies involved in Cygwin/XFree86. We bend over backwards to make it easier for developers new to the project to contribute.
> It has some funcitonality lacking (imo - the developers > seem to regard this as not being their problem): Cut and > paste between X and Windows does not work (although I once saw > rumors of an experimental daemon to fix this)
Excuse me, I am *the developers*. I would like to know how you suggest we wrap an X Server and an X Client all into a single executable with one main () function. Hey, but it isn't your problem either, because you have a job, college classes, a girlfriend, and a real life... hey wait, that's me:)
Thanks for being supportive of the project though.
> Oh, one more drawback - there seems to be a hard coded limit > to the window size that prevents me from letting the X desktop > span two windows monitors in multihead setup. This should > be easy to fix if one feels inclined, though, I expect.
Okay, we are waiting for your patch.
I just love writing free software, it is so appreciated.
I've put a lot of work into porting XFree86 to Cygwin:
Cygwin/XFree86
I personally have three motivations for porting XFree86 to Cygwin. My first reason is that I wanted to go to MIT (short story: didn't get in:). When I visited there, back in 1996, I went to the library and found out what I could about the Athena system. I found out that it used the X Window System, so I pulled a book off the shelf about UNIX and the X Window System and started reading. I was determined to learn everything that I could about UNIX and X so that I would be ready when I got to MIT. Well, since I didn't get in, I started working with the X Window System just to show them that I could handle anything they created:) So, my first reason was to spite MIT:)
My second motivation was my intro CS course at Carnegie Mellon in 1997. We were using Emacs under X and I wanted a way for people with only Windows machines in their dorm rooms to be able to get an X session on the lab computers without having to shell out big bucks for a commercial X Server. It wasn't until 3 years later that I found the Cygwin/XFree86 project and finished it up by making it work on Windows 95/98/Me/NT/2000, as opposed to just on Windows NT/2000. My second reason was derived from my shock at the rip-off prices being charged for X Servers on Windows.
My final motivation for porting XFree86 to Windows was that I wanted IS guys to be able to simply install Cygwin/XFree86 to allow Windows desktops to access new *free* applications running on remote Linux boxes (like GNUe, KOffice, etc.). I figured it was critical to the success of Linux in business to ease the transitionary path from Windows to Linux (by allowing coexistance). My third reason is thus a contribution to the free software movement that I had previously only benefitted from.
There you have it. Did I waste my time? Nope.
Now work is progessing on porting KDE, Gnome, and now Debian to Cygwin/XFree86. I couldn't be happier!
There seems to be a lot of excitement and debate regarding the performance of 64 bit code on the new Itanium in comparison to the performance of 32 bit code. In all the excitement some people seem to be forgetting that the first 32 bit 80386 was released in 1985, while the first 32 bit consumer-oriented operating system wasn't released until 1995.
In other words: don't hold your breath waiting for closed-source vendors to recompile their code.
Re:Novell ain't dead, but on the back burner
on
Is Novell Doomed?
·
· Score: 1
> Don't say a company is dead just because they're old
No one said Novell was dead because they were old; rather, Novell is dead because they don't have any vital signs. A/. poll regarding the last memorable Novell product release would probably settle on a date in the mid 1990s.
People have to be selfish; it's a response to the increasing speed of information.
People can only deal with a certain amount of death and despair, and it is right to mourn the passing of those close to you, namely, your family and friends, rather than those that "news" organizations have chosen to tell you about.
We haven't a duty, nor a right, to mourn the death of people that we have never previously interacted with.
Nonsense. Large and small retailers are allowed to exchange unsold versions of packaged software when a new version is released. This makes complete sense, as the production cost of software is essentially zero; the "value" of the software isn't added until the cash register drawer slams shut. Thus, a shelve full of $25 copies of RedHat is *worth* about 25 cents. Perhaps free software returned to the distributer will be handled differently, in that old versions can be donated to charity, instead of being destroyed. . .
Thanks for M$'s spin on things:)
I dunno, but I'm gonna guess that you don't read the Linux Kernel mailing list? It appears, from discussions on the list, that checksumming in hardware is supported on receive, but on transmit it really doesn't matter; in fact, on transmit, it appears that checksumming in hardware is actually undesireable, as this quote from Alan Cox would indicate:
Until you can lock user pages down nicely and DMA from them it is not a performance improvement to checksum in hardware [on transmit].
-Harold
I have learned a few things about drivers and open source by following the Linux-kernel mailing list:
1) Most devices require a kernel-level driver.
2) Kernel drivers may be linked with the kernel at compile time, or compiled separately and loaded at run time.
3) All kernel drivers must adhere to the driver interface required by a specific kernel.
4) The driver interface for the kernel does change; in fact, the interface has changed from 2.2.X to 2.4.0
5) When the driver interface changes, the kernel developers must modify every driver in the kernel source tree to adhere to the new interface; typically, scripts are used to simplify this task.
6) Binary only drivers would not be fixable when the interface changes; and, the kernel developers seem to be rightly against the idea of maintaining an interface translation program for every binary driver that is using a deprecated driver interface.
7) Kernel developers have the most daily exposure to kernel drivers; having the source to those drivers allows them to fix bugs that they find, and it allows them to fix bugs that they might occasionally introduce by changing other parts of the kernel.
8) Binary-only drivers would require that the kernel developers become paper pushers, forever prodding hardware companies to update their drivers to conform to new interface and to fix bugs.
I have to agree with, what I perceive to be the kernel developers reasons, for demanding open source kernel level drivers in Linux. I see no reason to unduly burden our fearless kernel developers with the administrative tasks and garbage coding required to support binary only drivers.
Now, imagine an interesting scenario: say I work for a company that refuses to release the source to their driver for reasons regarding an intellectual property issue. What will happen to me, and to the source code, if I were to slyly release the source code for the driver under the GPL license?:)
Slashdot Mirror
The KDE 3.0 icon bug for 32 bit color mode was just fixed in XFree86-xserv-4.2.0-10.
I hope you enjoy it,
Harold
We are working on a rootless version.
To update your Cygwin installation all you have to do is rerun Cygwin's setup.exe. It will show you which packages have updates and it selects them automatically for updating (if you had them installed before). It is really easy.
Harold
Yup, just send in /tmp/XWin.log.
That should do it.
Thanks in advance,
Harold
We've been looking for someone to run some comprehensive x11perf tests for Cygwin/XFree86 and a couple of the commercial X Servers for MS Windows. We would appreciate it very much if you could send the output files from x11perf (or better yet, links to the output files) to the `cygwin-xfree at cygwin daught com' mailing list.
You may want to check out the new `-clipupdates num_boxes' parameter, which gathers together num_boxes or more regions into a GDI clipping region and then does one bit block transfer to the screen, rather than one bit block transfer per damaged region. I'm guessing that `-clipupdates 10' or `-clipupdates 50' would give a good return on the overhead that is involved in creating a GDI clipping region.
Harold
Your problem with NetMeeting is that NetMeeting and Cygwin/XFree86 are both using DirectDraw. Apparently only one application is allowed to use a certain feature of DirectDraw at a time. By default Cygwin/XFree86 is using the DirectDraw Non-Locking engine, which you could specify with `-engine 4'; non-locking means that we call malloc () ourselves for the offscreen framebuffer, rather than letting DirectDraw allocate the memory for us. You can try passing `-engine 2' for DirectDraw with DirectDraw allocated surface memory, or `-engine 1' which uses GDI DIBs with no DirectDraw at all.
I'm positive that `-engine 1' will work, but if `-engine 2' works it should have better performance than `-engine 1'.
Good luck,
Harold
I am the project leader for Cygwin/XFree86 and I can tell you that we have never, ever, heard of such a failure. Please mail a detailed report to the Cygwin/XFree86 mailing list (cygwin-xfree at cygwin daught com). We would really like to fix this problem if it could happen to other users.
Thanks,
Harold
You have to either put Windows into 8 bit color mode, or you have to run with the -depth 8 and -fullscreen parameters (the -depth parameter is only used when -fullscreen is specified). Otherwise, you aren't really running Cygwin/XFree86 in 8 bit color mode. You can verify this by running `xdpyinfo' from an xterm... at the bottom it should tell you the depth of your visual.
On a side note, we are working on adding PseudoColor support to TrueColor visuals. This may take some time, but the end result would be that your VLSI tool would run even when you are running Windows in 15, 16, 24, or 32 bit color.
Harold
Yes, you can install Cygwin/XFree86 without admin rights on Windows NT/2000/XP. All you have to do is select ``Just Me'' in the ``Install For'' option on about the third screen in setup.exe.
I hope that helps,
Harold
Current features we are working on include:
- Native GDI Server - Translate X11 graphics calls into GDI graphics calls; currently we just draw to an offscreen framebuffer and transfer updates occasionally. This allows you to utilize the power of your $100+ graphics processor. Most respectable commercial X11 servers for MS Windows use this method.
- Clipboard integration - We have been working on this for a long time. Currently we have a seperate client, called xwinclip, that provides this functionality. We recently added support for passing Japanese text through xwinclip when running on NT/2000/XP.
- PseudoColor for TrueColor visuals - A lot of applications, particularly drawing or CAD programs, require a palette-based PseudoColor visual, while most people run Windows in TrueColor depths of 15, 16, 24, or 32 bit color. We would like to support PseudoColor visuals when our primary visual is a TrueColor visual. Some commercial X11 servers for MS Windows do this.
Go ahead and try Cygwin/XFree86 if you haven't already. We hope you like it. If you find some missing feature that you would like, then take a look at our source code and read our Contributor's Guide for instructions on how to download the source and build the tree, plus a general discussion of the technologies involved in Cygwin/XFree86. We bend over backwards to make it easier for developers new to the project to contribute.Harold
> It has some funcitonality lacking (imo - the developers
:)
> seem to regard this as not being their problem): Cut and
> paste between X and Windows does not work (although I once saw
> rumors of an experimental daemon to fix this)
Excuse me, I am *the developers*. I would like to know how you suggest we wrap an X Server and an X Client all into a single executable with one main () function. Hey, but it isn't your problem either, because you have a job, college classes, a girlfriend, and a real life... hey wait, that's me
Thanks for being supportive of the project though.
> Oh, one more drawback - there seems to be a hard coded limit
> to the window size that prevents me from letting the X desktop
> span two windows monitors in multihead setup. This should
> be easy to fix if one feels inclined, though, I expect.
Okay, we are waiting for your patch.
I just love writing free software, it is so appreciated.
Harold
I've put a lot of work into porting XFree86 to Cygwin:
:). When I visited there, back in 1996, I went to the library and found out what I could about the Athena system. I found out that it used the X Window System, so I pulled a book off the shelf about UNIX and the X Window System and started reading. I was determined to learn everything that I could about UNIX and X so that I would be ready when I got to MIT. Well, since I didn't get in, I started working with the X Window System just to show them that I could handle anything they created :) So, my first reason was to spite MIT :)
Cygwin/XFree86
I personally have three motivations for porting XFree86 to Cygwin. My first reason is that I wanted to go to MIT (short story: didn't get in
My second motivation was my intro CS course at Carnegie Mellon in 1997. We were using Emacs under X and I wanted a way for people with only Windows machines in their dorm rooms to be able to get an X session on the lab computers without having to shell out big bucks for a commercial X Server. It wasn't until 3 years later that I found the Cygwin/XFree86 project and finished it up by making it work on Windows 95/98/Me/NT/2000, as opposed to just on Windows NT/2000. My second reason was derived from my shock at the rip-off prices being charged for X Servers on Windows.
My final motivation for porting XFree86 to Windows was that I wanted IS guys to be able to simply install Cygwin/XFree86 to allow Windows desktops to access new *free* applications running on remote Linux boxes (like GNUe, KOffice, etc.). I figured it was critical to the success of Linux in business to ease the transitionary path from Windows to Linux (by allowing coexistance). My third reason is thus a contribution to the free software movement that I had previously only benefitted from.
There you have it. Did I waste my time? Nope.
Now work is progessing on porting KDE, Gnome, and now Debian to Cygwin/XFree86. I couldn't be happier!
Harold
Only available as binary? Better choose a better example than Quake 3 as the following page has a link to "Quake 3: Arena 1.17 Game Source":
http://www.idsoftware.com/archives/quake3arc.htm l
Here is a direct link to the source, albeit, I haven't gotten the link to work, but lots of ftp links on ID's site seems to be broken lately:
ftp://ftp.idsoftware.com/idstuff/quake3/source/q 3a gamesource_117.exe
Harold...I mean, it's just software, right? CBS doesn't deserve to profit off of this just for putting up the $2.5 million to actually develop the system. ;)
There seems to be a lot of excitement and debate regarding the performance of 64 bit code on the new Itanium in comparison to the performance of 32 bit code. In all the excitement some people seem to be forgetting that the first 32 bit 80386 was released in 1985, while the first 32 bit consumer-oriented operating system wasn't released until 1995.
In other words: don't hold your breath waiting for closed-source vendors to recompile their code.
> Don't say a company is dead just because they're old No one said Novell was dead because they were old; rather, Novell is dead because they don't have any vital signs. A /. poll regarding the last memorable Novell product release would probably settle on a date in the mid 1990s.
People have to be selfish; it's a response to the increasing speed of information. People can only deal with a certain amount of death and despair, and it is right to mourn the passing of those close to you, namely, your family and friends, rather than those that "news" organizations have chosen to tell you about. We haven't a duty, nor a right, to mourn the death of people that we have never previously interacted with.
Nonsense. Large and small retailers are allowed to exchange unsold versions of packaged software when a new version is released. This makes complete sense, as the production cost of software is essentially zero; the "value" of the software isn't added until the cash register drawer slams shut. Thus, a shelve full of $25 copies of RedHat is *worth* about 25 cents. Perhaps free software returned to the distributer will be handled differently, in that old versions can be donated to charity, instead of being destroyed. . .
Thanks for M$'s spin on things :)
I dunno, but I'm gonna guess that you don't read the Linux Kernel mailing list? It appears, from discussions on the list, that checksumming in hardware is supported on receive, but on transmit it really doesn't matter; in fact, on transmit, it appears that checksumming in hardware is actually undesireable, as this quote from Alan Cox would indicate:
Until you can lock user pages down nicely and DMA from them it is not a performance improvement to checksum in hardware [on transmit].
-Harold
1) Most devices require a kernel-level driver.
2) Kernel drivers may be linked with the kernel at compile time, or compiled separately and loaded at run time.
3) All kernel drivers must adhere to the driver interface required by a specific kernel.
4) The driver interface for the kernel does change; in fact, the interface has changed from 2.2.X to 2.4.0
5) When the driver interface changes, the kernel developers must modify every driver in the kernel source tree to adhere to the new interface; typically, scripts are used to simplify this task.
6) Binary only drivers would not be fixable when the interface changes; and, the kernel developers seem to be rightly against the idea of maintaining an interface translation program for every binary driver that is using a deprecated driver interface.
7) Kernel developers have the most daily exposure to kernel drivers; having the source to those drivers allows them to fix bugs that they find, and it allows them to fix bugs that they might occasionally introduce by changing other parts of the kernel.
8) Binary-only drivers would require that the kernel developers become paper pushers, forever prodding hardware companies to update their drivers to conform to new interface and to fix bugs.
I have to agree with, what I perceive to be the kernel developers reasons, for demanding open source kernel level drivers in Linux. I see no reason to unduly burden our fearless kernel developers with the administrative tasks and garbage coding required to support binary only drivers.
Now, imagine an interesting scenario: say I work for a company that refuses to release the source to their driver for reasons regarding an intellectual property issue. What will happen to me, and to the source code, if I were to slyly release the source code for the driver under the GPL license? :)
-Harold