Replace Windows DLLs with ReactOS DLLs?
Moderator: Moderator Team
Replace Windows DLLs with ReactOS DLLs?
I remember something about replacing Windows DLLs with ReactOS DLLs for testing. Is there any information on this? Is there a list of feature-complete DLLs?
-
- Posts: 107
- Joined: Fri Sep 08, 2006 2:56 pm
-
- Posts: 107
- Joined: Fri Sep 08, 2006 2:56 pm
I could see the benefit of doing so in the framework of blackbox testing.
Windows is a very large, and very complex "Blackbox", on which you place a "Replacement prototype" component, then evaluate the results.
EG, One could write some DirectX-like libraries, then place them on a windows machine, and overwrite the native libraries, then perform functionality and compatibility tests, and then go over the results.
This would effectively 'eliminate' the need to fully develop all the other prerequisite services in EG, ReactOS, to be able to test the DDRAW or DirectSound libraries. I happen to know that GreatLord does this very thing. (Make libraries and test them on Windows for compliance, without having to write, EG--- a DirectSound compliant device driver, implement various kernel services, et al)
Alternative reasons, considering if one were to overlook the stage of the development cycle that ReactOS is currently in-- Would be the avoidance of costly licensing problems inherant in the use of Closed source libraries. EG, you might need the functionality of a costly to license library, and then later discover that ReactOS has implemented a suitable alternative-- and then drag in that library in place of the costly to license one.
In short, I could see several reasons why one would wish to replace standard windows libraries with alternative ones, for various reasons.
I would say to people wishing to try this to be WELL AWARE of the development stage of ReactOS when considering doing so-- but that otherwise, short of incomplete, incompatible or improper implementation-- there should be no major technical problem preventing the use of a ReactOS library under a genuine windows platform. The usability of those same said libraries being dependent upon the desired intent.
Windows is a very large, and very complex "Blackbox", on which you place a "Replacement prototype" component, then evaluate the results.
EG, One could write some DirectX-like libraries, then place them on a windows machine, and overwrite the native libraries, then perform functionality and compatibility tests, and then go over the results.
This would effectively 'eliminate' the need to fully develop all the other prerequisite services in EG, ReactOS, to be able to test the DDRAW or DirectSound libraries. I happen to know that GreatLord does this very thing. (Make libraries and test them on Windows for compliance, without having to write, EG--- a DirectSound compliant device driver, implement various kernel services, et al)
Alternative reasons, considering if one were to overlook the stage of the development cycle that ReactOS is currently in-- Would be the avoidance of costly licensing problems inherant in the use of Closed source libraries. EG, you might need the functionality of a costly to license library, and then later discover that ReactOS has implemented a suitable alternative-- and then drag in that library in place of the costly to license one.
In short, I could see several reasons why one would wish to replace standard windows libraries with alternative ones, for various reasons.
I would say to people wishing to try this to be WELL AWARE of the development stage of ReactOS when considering doing so-- but that otherwise, short of incomplete, incompatible or improper implementation-- there should be no major technical problem preventing the use of a ReactOS library under a genuine windows platform. The usability of those same said libraries being dependent upon the desired intent.
Tachikoma_Pilot wrote:I know what a dll is ..... duh im a programmer
hehe, you can't put those 2 sentences together and expect people not to giggle.a dll can be many things a device driver a system file a link to a particular software library .....
mattst88, yeah, this is quite a common thing to do. Being able to swap one library directly for another is a good way to test compatability.
Our libs are mostly written and tested in a Windows environment.
If you are testing ROS libs in Windows and if you have WFP turned on (most people do) you need to override the usage of the MS libs
There is plenty of info on the net on this.
you'll also see test cases written for libs to ensure our libs act in the same way as Windows libs.
n.b. many of our dlls are from Wine. Therefore, they do all the writing and testing of those libs, not us.
Last edited by Ged on Mon Jan 08, 2007 4:35 am, edited 1 time in total.
Also interesting it checking the apps included to see if any odd quirks or crashes in ROS are exactly the same in XP or 2K. I've just spent a few minutes with the 0.3.0 live CD in XP Home running up a few of the apps and found some app bugs that I thought were down to ROS look more likely to be due to the supplied apps. I'd advise novices to be careful what they run though if in a valuable XP enviroment!.
Although I am guessing that some apps may not work with the XP commdlg as some appear to exit spontaneously on calling say a file-save dialog.
e.g.
whois doesn't work in xp (no output)
tracert (no output)
Notepad - save options greyed out
Wordpad - toolbars still don't show
Soitaire - can't get options to work in either ROS or XP
"ftp localhost" exits with no output
"ftp known-ftp-host" exits with no o/p
ftp CRLF
open CRLF
(to) localhost CRLF
also exits with no output
ncftp.exe crashes horribly with an app error memory at 0x00330043 cannot be "read".
imagesoft.exe exits spontaneously on "File->Open"
However...
tlist works nicely though in XP
so does maze.exe, winefile, zoomin, taskmgr.exe and a few others
I guess I'll also have a play with "depends.exe" and see what the apps look like
Although I am guessing that some apps may not work with the XP commdlg as some appear to exit spontaneously on calling say a file-save dialog.
e.g.
whois doesn't work in xp (no output)
tracert (no output)
Notepad - save options greyed out
Wordpad - toolbars still don't show
Soitaire - can't get options to work in either ROS or XP
"ftp localhost" exits with no output
"ftp known-ftp-host" exits with no o/p
ftp CRLF
open CRLF
(to) localhost CRLF
also exits with no output
ncftp.exe crashes horribly with an app error memory at 0x00330043 cannot be "read".
imagesoft.exe exits spontaneously on "File->Open"
However...
tlist works nicely though in XP
so does maze.exe, winefile, zoomin, taskmgr.exe and a few others
I guess I'll also have a play with "depends.exe" and see what the apps look like
Hi to everyone!,
There is a way to do this, at least in Windows (tm) 2000 or higher. I use it to debug dlls in Windows .
You can view the Microsoft article in this page:
The End of DLL Hell - http://msdn2.microsoft.com/en-us/library/ms811694.aspx.
If you don't want to read it completely, the only thing you need to do is create a file called yourprogram.exe.local (where yourprogram is the executable filename) in your program directory. Copy the libraries you like and launch the program. You'll be using the local copies of the dll files.
Best regards,
Logan_V8
There is a way to do this, at least in Windows (tm) 2000 or higher. I use it to debug dlls in Windows .
You can view the Microsoft article in this page:
The End of DLL Hell - http://msdn2.microsoft.com/en-us/library/ms811694.aspx.
If you don't want to read it completely, the only thing you need to do is create a file called yourprogram.exe.local (where yourprogram is the executable filename) in your program directory. Copy the libraries you like and launch the program. You'll be using the local copies of the dll files.
Best regards,
Logan_V8
Maybe this link works:
http://msdn.microsoft.com/library/defau ... anger1.asp
Each application has its dlls loaded into their own address space, so you can have different applications with their own different dlls, which can provide the same functions as other dll used by another application, but in a different address space. For example you can have one application using a local, old copy of comctl32.dll and other running the latest version, at the same time.
http://msdn.microsoft.com/library/defau ... anger1.asp
Each application has its dlls loaded into their own address space, so you can have different applications with their own different dlls, which can provide the same functions as other dll used by another application, but in a different address space. For example you can have one application using a local, old copy of comctl32.dll and other running the latest version, at the same time.
Own address space? That would kinda wreck using DLLs as methods of shared interprocess data exchange. I wonder if its always the case??
At one time DLLs were used this way - maybe times have changed but, again, there may be some older apps remaining which use this method.
I'm sure I had a problem with a PHP dll a few months back which was getting locked and I'm also sure this is still the reason for the ol' post-install reboot (release dll handles and useage counts and enable replacements to be read from disk on next boot?)
Maybe I'm wrong or things have moved on?
Ahhh.. yes, just checked and the new URL and the page works now - more useful info and a section called Private DLLs
Very good stuff
At one time DLLs were used this way - maybe times have changed but, again, there may be some older apps remaining which use this method.
I'm sure I had a problem with a PHP dll a few months back which was getting locked and I'm also sure this is still the reason for the ol' post-install reboot (release dll handles and useage counts and enable replacements to be read from disk on next boot?)
Maybe I'm wrong or things have moved on?
Ahhh.. yes, just checked and the new URL and the page works now - more useful info and a section called Private DLLs
Very good stuff
How to destroy memory effectiveness 101. Basicly
Unix uses a different cure to dll hell. This spread to Unix and Linux. To be correct so Hell. Unix worked it out a long time ago.
The dynamic linker in linux is controlable. Bit like windows comparability layer. Each .so has its version added to its file name. So many version can be in the system directory and not cause any problems. And apps can be told they need X version of Y dll. Even have there imports modified if required to lock it like that.
SxS is basic the Unix system [url]http://msdn2.microsoft.com/en-us/librar ... s.80).aspx[/url]
But with a lot more mess. You have to know where the dll you want is not just say use X version.
The effectiveness in Linux. Is got because executable sections of so's and programs can be shared between processors because the default load sections are read only to all users. This is the reason why its 256 megs for the first user using KDE on Linux and only 50 more megs for a secound user. Code sharing is a large saving. Most people don't know how big. Its the reason why embedded micro processors have like 1 kb of ram 1kb of alterable flash and 128 kb of flash that programs cannot write to at run time. Less memory is need for settings than executable code in most cases.
It is one of the reasons why mono/.net is hated by linux system admins and java minorly so.(Java has a cure turning it to native code). Does not allow memory effectiveness between users.
In theory a cow a attack copy on write on applications could be very effective in keeping memory management down.
Linux and Unix use memory protection to reduce ram usage.
Unix uses a different cure to dll hell. This spread to Unix and Linux. To be correct so Hell. Unix worked it out a long time ago.
The dynamic linker in linux is controlable. Bit like windows comparability layer. Each .so has its version added to its file name. So many version can be in the system directory and not cause any problems. And apps can be told they need X version of Y dll. Even have there imports modified if required to lock it like that.
SxS is basic the Unix system [url]http://msdn2.microsoft.com/en-us/librar ... s.80).aspx[/url]
But with a lot more mess. You have to know where the dll you want is not just say use X version.
The effectiveness in Linux. Is got because executable sections of so's and programs can be shared between processors because the default load sections are read only to all users. This is the reason why its 256 megs for the first user using KDE on Linux and only 50 more megs for a secound user. Code sharing is a large saving. Most people don't know how big. Its the reason why embedded micro processors have like 1 kb of ram 1kb of alterable flash and 128 kb of flash that programs cannot write to at run time. Less memory is need for settings than executable code in most cases.
It is one of the reasons why mono/.net is hated by linux system admins and java minorly so.(Java has a cure turning it to native code). Does not allow memory effectiveness between users.
In theory a cow a attack copy on write on applications could be very effective in keeping memory management down.
Linux and Unix use memory protection to reduce ram usage.
Very interesting. I noted that the approach in the MSDN article was that memory was now cheap so why worry about code-sharing. Guess they're thinking "single user" still rather than multi (100s of) user(s) per workstation or server. Not sure that ROS would have the potential say, to act as a SAMBA or SQL server like Linux would.
My understanding of ROS was that it would be pretty well a warts-and-all reverse implementation of Win NT/2K rather than emulation over a Unix core using Wine components.
I've read around the site but can't see any directional intent for ROS to act in a server capacity as a long term aim. Personally I'd be interested in using ROS as a compact and bootable ISO webserver with say, Apache.
The idea of having a native Win32 fileserver booting from CDROM similar to BartPE is also interesting - the potential as a rescue environment in a support environment would also be good. Maybe a fun thread would be to ask everyone what they'd like to use ROS for in the long term future?
My understanding of ROS was that it would be pretty well a warts-and-all reverse implementation of Win NT/2K rather than emulation over a Unix core using Wine components.
I've read around the site but can't see any directional intent for ROS to act in a server capacity as a long term aim. Personally I'd be interested in using ROS as a compact and bootable ISO webserver with say, Apache.
The idea of having a native Win32 fileserver booting from CDROM similar to BartPE is also interesting - the potential as a rescue environment in a support environment would also be good. Maybe a fun thread would be to ask everyone what they'd like to use ROS for in the long term future?
Who is online
Users browsing this forum: No registered users and 36 guests