Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Sat Oct 15, 2005 2:09 am

Wine d93d wapper uses OpenGL, too.
This section of wine did not start in side wine.

Strange part is that Nvidia and Ati cards provide direct OpenGL interface libs.

Ie there Opengl interface libs don't depend on DirectX. Guess what I have installed Microsoft windows without DirectX. Nvidia and Ati opengl section still works.

d93d layour is build from another project that let building for DirectX 8 applications in a way that they were only dependant on OpenGL.

Ie Opengl hardware accel is a different section.
Many manufactor does not implement full opengl api
Under OpenGl you were never ment to. The problem is part the core Opengl of windows ie version 1.2. Mesa does not have this problem but requires a version control so it does not use the complete processor.

There is always the option of making Mesa completely interface with the Direct X drivers. It has been done in the past. Just there has been no need.
Last edited by oiaohm on Sat Oct 15, 2005 1:00 pm, edited 1 time in total.

Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd » Sat Oct 15, 2005 7:44 am

Pentiumforever wrote:Cool only bad that the most games use directX :?
but all the cool games use OpenGL

* quakes use OpenGL
* doom source ports use OpenGL
* warcraft 3 has an OpenGL subsystem (use -opengl in the shortcut)
* doom3 uses OpenGL

the other games are just fluff
pax mei amici amorque et Iesus sacret omnia

Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd » Sat Oct 15, 2005 7:47 am

geertvdijk wrote:yes i see i checked, you have to validate Windows (:() before downloading. This can be bypassed, but you (and i) cannot recommend that since it's illegal... One silly question, does Microsoft (suppose so...) say you can't host the dxinstaller ? :D
the EULA states you need "genuine" windows to install it (as someone said earlier), it's not illegal to host it elsewhere though. also the "validate" windows bit is only to check if you have a hacked version of windows (but it won't work on non-activex browsers) so you have to download it to a validated windows install.

but i thought EULAs were only valid in 3 states in the US and completely ignored outside of the US
The enforceability of an EULA depends on several factors, one of them being the court that the case is heard in. Most courts that have addressed the validity of the shrinkwrap license have found them to be invalid, characterizing them as contracts of adhesion, unconscionable, and/or unacceptable pursuant to the U.C.C. Step-Saver (939 F.2d 91)—see, for instance, Vault Corp. v. Quaid Software Ltd. (at and Rich, Mass Market Software and the Shrinkwrap License (23 Colo. Law 1321.17). A minority of courts have determined that the shrinkwrap license is valid and enforceable: see ProCD, Inc. v. Zeidenberg (at, Microsoft v. Harmony Computers (846 F. Supp. 208, 212, E.D.N.Y. 1994), Novell v. Network Trade Center (at, and Arizona Cartridge Remanufacturers Association Inc. v. Lexmark International Inc. may have some bearing as well.
pax mei amici amorque et Iesus sacret omnia

Posts: 360
Joined: Sun Dec 19, 2004 12:42 am
Location: Australia

Post by Phalanx » Sat Oct 15, 2005 4:15 pm

A recent court case in Australia showd some interesting result :D If it is the user's, they can do what they want if they don't breach laws (eg. copyright etc).

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

The Ruling in Australia is interesting.

Post by oiaohm » Tue Oct 18, 2005 9:11 am

The Australia case was really simple. You can declare number of copies...

But you cannot declare anything that is a breach of fair competion. Ie X program must be ran only on X os's. Sony also leart this the hardway Mod chips are legal here for PS/2 and DVD players. Region coding breachs the law of fair competion so cannot say that moding stuff is illegal if the mod is removing something that is illegal. This is nasty.

This might apply in other countrys. A copyright sections are only vaild if they don't break other laws.

Posts: 154
Joined: Thu May 26, 2005 3:43 am
Location: Slovakia

Post by etko » Tue Oct 18, 2005 9:43 am

I would like to ask, how much the OpenGL is supported just right now ;) (only to get an image), are extensions possible with vendor specific drivers?

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Wed Oct 19, 2005 3:45 am

Mesa full opengl spec software rendered. (Heck you better have a large machine with many processors to test it out).

Mesa does not need extensions its all of it. It need drivers to speed it up.

Mesa also does Nvidia Cg in software.(this system really hurts cpu)

Ie Reactos is completely OpenGL compad just slow. Vendor specific drivers are required so that the load can be taken of the processor and placed on the video card where it should be.

Past projects of Mesa have gone as far as using directX drivers to carry out this out. These project have not been looked after from DirectX 6 so a lot of updating is required. Please not Microsoft has publish how to write a video card drivers for Windows and DirectX so its not a large jump to join Mesa to DirectX drivers. Nvidia and Ati addons can be used with Mesa.

How openGL on windows works is you have a core lib opengl32.dll and a driver (nvopengl.dll nvidia driver name) The total usable functions are made up of both dlls with nvopengl.dll being dominate since its the driver. Ie will work fine with Mesa and long as the dll handling to get opengl to work right. You might have a problem with Mesa since its current day spec and opengl32.dll is version 1.2(just a little out of date). And not all video card drivers being current day spec. Ie the Mesa dll might call a function that has extentions that the video driver does not support. Minor head acks. Note that nvidia and Ati opengl driver makes direct calls to the video card and is not dependant on the directx half.

Guess what is half the problem on linux that opengl is slow in software mode.

Posts: 1050
Joined: Mon Nov 29, 2004 1:36 pm
Location: Italy

Post by forart » Thu Oct 20, 2005 11:47 am

I think that another way could the SDL:
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."

Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. There is also code, but no official support, for Windows CE, AmigaOS, Dreamcast, Atari, NetBSD, AIX, OSF/Tru64, RISC OS, and SymbianOS.

SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, Eiffel, Java, Lua, ML, Perl, PHP, Pike, Python, and Ruby.
...and, for sound: VDMSound (latest here).

Open source alternative would be better than DirectX... :D
»Forward Agency NPO
In progress we (always) trust.

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Sdl is not a fix

Post by oiaohm » Thu Oct 20, 2005 3:26 pm
The dxglwrap is where the wine project direct X started.

With opengl working SDL will work. So having it extra is not a problem.

The problem is that we need to be able to run some direct X software out the box. Fastest way is to port the directX from wine and fixup the opengl. Most of the code exists. Is it the best most likely no. Will we have legal problems no so it is a good fix.

Posts: 39
Joined: Fri Dec 03, 2004 2:24 pm

Post by Linuxhippy » Fri Oct 21, 2005 12:05 pm

I also thinks its not that good to emulate Direct-/3D/Draw on top of OpenGL since on ReactOS a native implementation would be possible and a better solution, however there were some statements that I think are not that correct.
GreatLord wrote: 1. it is to slow it will never use windows hardware acclartion for directx
What does this funny, incomplete statement wants to tell us? OpenGL is slow??
Well, since its just an API its as fast as its implementation and since it runs on the same hw theres no reason it should be any slower.
There would be some translation overhead but its almost negligible.
GreatLord wrote: 3. Directx api are 100% support by most manufactor (nivida / ati)
OpenGL's are too by ATI and Nvidia.

GreatLord wrote: 4. wine directx api for graphice system are going down direcly to xfree and linux kernel.
Well every x-based, graphical application goes down to the kernel and xfree when running on Linux- by sending syscalls and calling xfree-functions.
However I do not see the point here - Wine uses X11 for drawing "normal" win32 controls and OpenGL to "emulate" OpenGl and DirectX. Thats it, has never been a secret.

lg Clemens

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Fri Oct 21, 2005 4:09 pm

Xfree is not a requirement of Wine a X11 server is.( and others work)

Problem is that the Direct X section of wine does not call X11 directly it call threw either the Opengl layor or the Wine X11 translation driver(the fake win32 screen output). Ie the Direct X emulation never directly interfaces with the X11 system.

Having a working Direct X layour even with Opengl spread right threw it. Is better than no Direct X. 2 projects Working Direct X and fast Direct X. Fast Direct X is the Wine Direct X first using the Direct X drivers to speed up opengl or remove Opengl from direct X.

Strange as it seams programs like Microsoft Office sometimes call Direct X. So we need it. Imperfect or not we need it.

Posts: 154
Joined: Thu May 26, 2005 3:43 am
Location: Slovakia

Post by etko » Fri Oct 21, 2005 7:52 pm

From intial post of this thread I've got impression that OpenGL vendor specifics ICDs are working and opegl32.dll is able to load them. Is that true Denzil?

I'm not insterested in porting, wrapping, DX, mesaGL or other unrelated things, I just wanted to know whether native WINNT ICDs are suported right now, be it svn or other ROS release.

Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord » Fri Oct 21, 2005 9:27 pm


Blight_ have made icd interface for opengl in reactos I think it was already in release 0.2.5 or 0.2.6.

Some fact about DirectX

1. Wine DirectX layer for ddraw / D3D will not working in windows or reactos.

2. Wine DirectX ddraw / D3D is bound to wine3d lib then
it is bound to X11 and linux opengl drv.

3. Wine DirectX using shourtcut how directx works and is base on windows 98 design

4. Hardware manufactor some are building there opengl drv on DirectX

5. Microsoft will remove the opengl icd interface in longhorn/vista and opengl must be a warper on directx if u want hardware acclartion

That is some reason why ReactOS refuse implement ddraw and d3d on opengl.

Posts: 483
Joined: Tue Nov 30, 2004 5:44 pm
Location: Canada

Post by cmoibenlepro » Sat Oct 22, 2005 5:36 pm

BTW, sorry if I'm a bit offtopic, but I can see that you are using mesa3d version 6.2.0
It was released more than one year ago.

Won't it be a good idea to upgrade to the newest version (6.3.2) ?

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Sun Oct 23, 2005 8:09 am

1. Wine DirectX layer for ddraw / D3D will not working in windows or reactos.

Please Read Porting. Wine D3D dlls do work on windows.

wined3d. Is not portable. Reason its a video card driver extention that direct X needs to work. Ie this would have to be rebuilt for reactos.
4. Hardware manufactor some are building there opengl drv on DirectX

5. Microsoft will remove the opengl icd interface in longhorn/vista and opengl must be a warper on directx if u want hardware acclartion
I will tell you a evil little thing. Hardware Manufactors some of them the opengl drv is not based on DirectX but DirectX drivers. There is a difference. As long as the DirectX driver is installed it works it does not require directX to work remove direct X and the system still works. Reason if they depend on DirectX some programs require X version direct X to work so user would install it then screem at the hardware maker hey where did my opengl go since require Direct X function is now missing. So almost all hardware makers use opengl drivers that directly call direct X drivers not Direct X. Nvidia even have extra options in their Direct X drivers for opengl use only.

Opengl icd interface is not a major issue. Opengl will not have to wrap to directX we will see mesa I bet. Video cards will still have opengl drivers. Reason DirectX places to much overhead on OpenGL calls. Ie Opengl lower overhead more speed so Opengl can do DirectX but DirectX cannot do opengl very well. Nvidia and Ati will not risk being over ran because they cannot do Opengl fast. Ie the faster the better is there monto in Opengl and Direct X.

I did not say it was work less.

Also I will be really evil here Guess what X11 does work on Ms Windows and Microsoft even provide porting instructions. Depending on the calls some emulation libs could be used until the recode is complete. And I am not talking about or Xfree86 is one of many options all it does is redirect the calls.

linux opengl drv. Really upseting is the Mesa is linux opengl drv default on almost all systems. Basicly all the parts run on Windows as linux so no real problems. Opengl and X11 Striping can be done latter. Removing the X11 emulation will add speed. Operational first speed secound.

Etko Little note MesaGL is opengl32.dll under reactos. Reason for taking about Mesa and its limits.

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests