Date: Mon, 5 Jan 1998 11:05:11 -0500 From: "Alfred Perlstein" <perlsta@sunyit.edu> To: <devel@XFree86.Org> Cc: <hackers@FreeBSD.ORG> Subject: Re: interested in working on windows port (sorry for cross post) Message-ID: <199801051209.MAA02085@fang.cs.sunyit.edu>
next in thread | raw e-mail | index | archive | help
i have no interest in making a "let windows be my window manager X" that is garbage, i've seen them and they are horrible, my main interest is getting a full screen port done with XDM logon abilities. using windows as my window manager gives me a chill and ruins the whole experiance for me :) if possible a "full screen in one window" would be a later project... i do not want to "stray" from the Xfree86 model, i would like to have this port be maintained easily, not as a one time port and forget about it deal where so much is kludged around that maintaining it is impossible. to me, DirectX+fullscreen is the way to go. i've seen "in window" X servers and the performance is horrid, why run X and make it slow? -Alfred ---------- > From: David E. Wexelblat <dwex@datafocus.com> > To: 'devel@XFree86.Org' > Cc: hackers@freebsd.org > Subject: RE: interested in working on windows port (sorry for cross post) > Date: Monday, January 05, 1998 8:49 AM > > Well, I have a great deal of experience with PC X servers (check > out the work URL...). I have to be careful with what I say, as > we are a source licensee for one of the PC X server vendors, and > I've been inside their sources. I will only give some general > comments. > > 1) From what I have been told by more than one PC X server > manufacturer, DirectX is going to be a waste of time. DirectX > only gets major performance improvements when it can take over > the entire screen. When running in a window, it's not a major > win over raw GDI code. As far as I know, none of the PC X server > vendors use DirectX. > > That said - Windows NT 4.0 Service Pack 3 provides most of > DirectX 3 for Windows NT. DirectX isn't supported at all prior to > SP3, and DirectX 5 support isn't planned to be available until > Windows NT 5.0 (which is currently in Beta1). > > 2) All the PC X servers operate in one of two modes: single-window > or multiple-window. Single-window is a traditional X server main > window, living in a single Windows window. Basically, the Windows > window becomes a single large framebuffer. This is easy to implement, > but X apps don't coexist well with Windows apps this way. > > Multi-window mode basically has no visible X root window. Each X > top-level window is a Windows top-level window. In this mode, the X > server provides some sort of local window manager, so that the X apps > are both ICCCM-compliant, and windows-friendly. The good ones even > recognize Motif window manager hints for decorations, etc. > > I have never seen anyone use anything other than multi-window mode > (well, > we do have a couple of ISVs selling turnkey boxes, who I have been told > do use single-window mode). > > 3) Palette management is a major headache. In a normal X server, the > X server controls the hardware palette, and can do what it wants. In a > PC X server, Windows controls the palette. There's a lot of code > involved > in getting X color handling to work "right" under Windows. > > In addition, most of the major PC X server vendors have implemented > 8-bit-pseudo-color visuals on top of 16/24/32-bit true-color visuals. > This > is because most PCs these days are in high/true-color mode, and most X > apps > fall down if the default visual isn't 8-bit pseudo-color. As far as I > know, > this is all done with software; I've been told that Windows provides no > way > to get to the RAMDAC to do it in hardware even if the RAMDAC supports > it. > > 4) Device management is also a pain (keyboard & mouse), because you have > to > go through windows. > > 5) Font management is interesting. All the PC X servers I have seen > have X > bitmap & scaled fonts, but not in .pcf format. They have them in > Windows > .fon format, and provide their own font compilers. I've never > completely > understood why they bother with this - if they're going to provide > X-specific > fonts, why not leave then in X-specific formats? No one has yet written > a > font server that allows use of native Windows fonts, that I have seen. > > -- > David Wexelblat Phone: (703) 803-3343 x370 > DataFocus Incorporated Fax: (703) 803-3344 > 12450 Fair Lakes Circle, Suite 400 mailto:dwex@datafocus.com > Fairfax, VA 22033-3821 http://www.datafocus.com > > > > -----Original Message----- > > From: Alfred Perlstein > > Sent: Friday, January 02, 1998 6:31 AM > > To: devel@XFree86.Org > > Cc: hackers@freebsd.org > > Subject: interested in working on windows port (sorry for cross > > post) > > > > (please excuse the cross post, i'm really looking for help and this is > > a > > strange multiplatform subject...) > > > > I'm interested in making a windows 95/NT port of Xfree86, > > i plan on using DirectX to support fast accesses to the graphical > > hardware. > > > > if anyone has the time to answer a couple of questions it would be > > greatly > > appreciated. > > > > 1) can anyone recommend a free c/cpp compiler/enviornment for this? > > i've looked at DJGPP,RSXNT, and the cygnus thingy and so far: > > DJGPP doesn't support win32. > > RSXNT hardly is docmented and doesn't seem to be useful as a > > UNIX to WIN32 > > porting tool things like sockets don't seem to be implemented. > > cygnus doesn't appeal to me because of hardcore GPL license they > > have. > > > > i do NOT mind giving credit where credit is due... but i'm not > > too keen on > > releasing my source, i DO however, plan on the product being free. > > > > 2) if i use direct-X does anyone know if it will work on NT? i think > > mircosoft doesn't support DirectX on NT, or at least not past version > > 3... > > > > 3) what books can i get on the low level details of X? anything on > > how the > > X11 source tree is set up? anyone have any pointers to good > > FAQs/tutorials? > > > > thank you, > > -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801051209.MAA02085>