Replace Windows DLLs with ReactOS DLLs?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

mattst88
Posts: 4
Joined: Sun Nov 20, 2005 9:19 pm

Replace Windows DLLs with ReactOS DLLs?

Post by mattst88 »

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?
Tachikoma_Pilot
Posts: 107
Joined: Fri Sep 08, 2006 2:56 pm

Post by Tachikoma_Pilot »

dll's as in drivers? i seem to be missing the point ..... :oops:
jason.b.c
Posts: 62
Joined: Sun Mar 26, 2006 10:50 am
Location: Marshfield, Missouri

Post by jason.b.c »

Tachikoma_Pilot wrote:dll's as in drivers? i seem to be missing the point ..... :oops:
Yes you are if you don't understand what a DLL is ..!! Dynamic.Link.Library
Tachikoma_Pilot
Posts: 107
Joined: Fri Sep 08, 2006 2:56 pm

Post by Tachikoma_Pilot »

I know what a dll is ..... duh im a programmer, :shock: i fail to c the logic in the nature of the request and also a dll can be many things a device driver a system file a link to a particular software library ..... so still im lost!
Wierd
Posts: 147
Joined: Sat Dec 18, 2004 10:12 am

Post by Wierd »

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.
Ged
Developer
Posts: 925
Joined: Thu Sep 29, 2005 3:00 pm
Location: UK

Post by Ged »

Tachikoma_Pilot wrote:I know what a dll is ..... duh im a programmer
a dll can be many things a device driver a system file a link to a particular software library .....
hehe, you can't put those 2 sentences together and expect people not to giggle.


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.
Tachikoma_Pilot
Posts: 107
Joined: Fri Sep 08, 2006 2:56 pm

Post by Tachikoma_Pilot »

its my job to entertain ........ ^^
madmax69
Posts: 51
Joined: Mon Jan 01, 2007 12:36 am

Post by madmax69 »

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 :)
logan_V8
Posts: 15
Joined: Sat Feb 04, 2006 9:54 pm

Post by logan_V8 »

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
madmax69
Posts: 51
Joined: Mon Jan 01, 2007 12:36 am

Post by madmax69 »

As always (for the MS site) the article is missing. Shame.

I'd guess that the DLL also needs not to be already loaded in memory and locked from the main system area to be able to use different ones.
logan_V8
Posts: 15
Joined: Sat Feb 04, 2006 9:54 pm

Post by 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.
madmax69
Posts: 51
Joined: Mon Jan 01, 2007 12:36 am

Post by madmax69 »

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
logan_V8
Posts: 15
Joined: Sat Feb 04, 2006 9:54 pm

Post by logan_V8 »

Own address space is a fundamental concept of modern OSs, because with it you have memory protection. An application cannot write outside its own space. There are a lot more things going on with this... :)

Best regards,
Logan_V8
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

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.
madmax69
Posts: 51
Joined: Mon Jan 01, 2007 12:36 am

Post by madmax69 »

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?
Post Reply

Who is online

Users browsing this forum: No registered users and 36 guests