Slashdot Mirror
Linux Kernel to Fork?
Ninjy writes "Techworld has a story up about the possibility of the 2.7 kernel forking to accomodate large patch sets. Will this actually happen, and will the community back such a decision? "
← Back to Stories (view on slashdot.org)
No details, no important names.. no nothing.
There are plenty of forked kernel trees out there. Most continually merge in changes from Linus' tree, though.
A fork doesn't matter. What matters is what it represents. If there is enough popularity that the Linux community ends up using incompatable forks, then yes, we have a problem.. but forking in no way necessarily leads to this.
As always, the available kernels in wide use will reflect what people actually want to use.
You're right: Each version of the kernel doesn't requires applications to be compiled specifically for it.
Yet, where I work, the applications have to be specifically recompiled for each of the three versions of the Linux distribution currently in use.
While it may be mainly the in-house distribution designers fault, it is a real mess, and a major reason for many of the engineers staying away from Linux.
WoodstockJeff - "Not so under Windows, and windows will only load the first version of a named DLL it finds, and hang onto it until you reboot"
.DLL extensions also), that have .OCX extensions too. These are "marshalled" (loaded) not by name, as is done with older .DLL file types using the LoadLibrary call, but via a thing called a "GUID" (Globally Unique Identifier).
.ocx or .dll file being called for its internal version information (using the functions this program uses on Version checking no doubt, std. Win32 API call method).
.DLL it is calling, first
.exe files for finding DLLs to load -
.exe location folder
.DLL extension, then search order becomes:
.exe file folder.
.exe file directory.
Untrue - there are SEVERAL rulesets that allow side-by-side loading of DLL's in Windows ever since Windows 2000 in fact.
Ruleset for library loading underneath Windows2000/XP/2003 (assuming developer/oem of the software didn't "hardcode" his library path define or LoadLibrary API call with a path to a file), is as follows:
"DLL HELL" may occur on Win32 OS when 2 of SAME named "Dynamic Link Libraries" (.dll extension, executable with no loader header that cant self initialize) exist on a system and are accessible to a program. Since same name it can cause a program to "grab hold" of wrong version build to init for call functions it uses from it!
Can be problem that causes crash in programs because program expects function it calls to return integer return from a function but latest build of DLL of same name sends back pointer data instead!
Microsoft overcame a great deal of "DLL Hell" using ActiveX controls (OLE Servers, which have
This is a 128-bit UNIQUE generated number in the registry that summons the CORRECT build the calling program requires by internally checking the
Microsoft has also put in "Side-by-Side" loading in their newer Operating Systems (2000/XP/2003) which can load the older type DLLs technically by name but into RAM separately, where they can be accessed separately by programs (the program that calls and finds the one it loads) so no "collisions" occur.
This is a GOOD move, but still can be problematic if the program finds the wrong version build of the
Order of seeks used by Win32 Portable
NT based Os by default, use different approaches for 32-bit vs. 16-bit apps:
1.) For 32-bit apps, NT/2000/XP/2003 search for implicitly loaded DLLs at:
a.
b. Current folder
c. %SystemRoot%\SYSTEM32 folder
d. %SystemRoot% folder
e. %Path% environment variable
* BUT if a DLL is listed as a KnownDLLs here in registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Cont ro l\Session Manager
As REG_SZ entry type & Value of DLL name w/out the extension + data value of DLLname w/
aa. %SystemRoot%\SYSTEM32.
bb.
cc. Current folder.
dd. %SystemRoot% folder.
ee. %Path%.
KnownDLLs are mapped at boot time. Rernaming or moving during a session has no effect.
You can alter this behavior by including the 8.3 DLL name in the ExcludeFromKnownDlls entry, a REG_MULTI_SZ value, & one per line in that comma delimited listing.
(This makes NT believe that the DLL is not listed in KnownDLLs.)
2.) For 16-bit apps, Windows NT uses KnownDLLs for both implicitly and explicitly load DLLs. The value is at:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Cont ro l\WOW.
Here in that key, KnownDLLs is a REG_SZ value that lists 8.3 DOS formatted DLL names, & is separated by spaces. Without a KnownDLLs entry, WOW searches:
a. The current directory.
b. The %SystemRoot% directory.
c. The %SystemRoot%\SYSTEM directory.
d. The %SystemRoot%\SYSTEM32 directory.
e. The
f. The directories in your Path.
With