Speaking of OneNote, you might find an interesting set of videos on StationeryIsBad.com.
To be completely honest, I'm a bit pissed off at the moment, so I might say a few things that I will regret later. Should that happen... Tough luck.
There are two things that kind of drive me nuts. On the one hand, it's about some people being total "ignorants" (and I can't even tell if they do it on purpose or if their ignorance is genuine). I guess I'm beating a dead horse and everyone is already bored like hell, but for some reason I keep getting back to the side-by-side DLL story. I provided earlier a few links (unfortunately the easiest to understand but not the most relevant ones related to this subject, which is my fault); if one would have followed the links, one would have discovered quite easily a whole bunch of information about side-by-side support in Windows.
For instance, it's fairly obvious that you can do side-by-side with Win32 native assemblies (together with COM components) just by looking at the Assembly Manifests reference page. The ultimate reference for developing and deploying side-by-side native components on Win32 is located under the Isolated Applications and Side-by-side Assemblies node in MSDN Library. Spend a couple of hours reading all pages under that node, and the picture will get very clear.
As far as I know, Windows XP has approximately the same kind of side-by-side support for native components as .NET does. This is because the binding component ("Fusion") is developed by parallel teams. I learned about this from blogs.msdn.com. If you search for "Fusion Win32 CLR", you'll get plenty of information on this.
On the other hand, technical problems aside, there's another thing that pisses me right off. I can't really understand why Microsoft started Channel 9 just to abandon it. This is just how C9 feels when you take a look at what's being discussed here. I don't really expect a Microsoft employee or an MVP to hop in every time somebody makes a technically inaccurate statement. That would be totally unfeasible and unreasonable. But when you get to the point where a raving lunatic completely dismisses all reasonable evidence without even knowing what he's talking about, you end up thinking that Microsoft, as well as the members of this forum don't actually give a crap about what's being discussed here vs. the actual facts.
Hold on there, did I just say "raving lunatic"? There must be a solid reason for that, heh? Maybe it's because I wouldn't dare to comment on RPM's functionality simply because I feel I'm not experienced enough with it (although I know the basics). But when someone quotes whatever he likes from an article without any context and without actually knowing what the story is all about, we're quickly moving to fantasy world.
The bottom line is that I don't understand the purpose of these forums anymore. You have a bunch of people making statements that have virtually nothing to do with the actual facts and you host them on your own website. What's the value of being thrown with (I need to watch my language) at in your own home?
Is there any way to wipe out my Channel 9 account?
Yes Beer, you're right, whatever you said. Now calm down...
Charles wrote:That's your best retort? Hmm...
Charles, I've done evangelism for Microsoft for 3 years now. Not for professional developers, but for the most interesting kind of audience: students. They're the most honest and sharp people someone can work with, although many of them are not completely aware of the world out there. Among Linux fans, there are two kinds of people:
Reasonable ones who are starting to understand the realities of our industry and are building a pragmatic view on the world. Whenever they bash Windows or praise some open-source piece of software, proving to them that "it can be done on Windows too" or that "yes, you can do it on Linux but you can do it more neatly/cheaply/quickly on Windows" usually does the trick. You don't necessarily convince them of your views at once, but you've opened the path for communication and reasoning.
Let's-fight-for-peace kind of trolls, who are totally isolated from new ideas. You talk one-on-one with such people. During the first 10 minutes you have totally disparate views of the world. Then, you find some common points and agree on some issues. Then, you're really communicating. And at the end of the discussion they present they conclusions wich are usually the most absurd kind of distortion you could have possibly imagined related to the topics of your conversation.
The first kind of people are important to work with. They're the kind of IT professionals interested in getting the job done. If necessary, they will buy into Windows or Linux, as long as they get the best results for their problems. They are valuable professionals to look for when building a company or when making business.
The second people only care about always being right and about making the whole world agree with them. So I gave Beer what he wanted. I guess an actual demo of the features we were talking about would have been useless anyway.
Charles wrote:Let's keep it civil, boys. Best to explain the reasoning behind even a mild personal attack ("you're ignorant"), otherwise it's just a puff of hot air.
I'm honestly sorry about all the noise. RPM rocks, MSI is light years behind it. You can do proper side-by-side and versioning only on Linux. Heck, you can do decent computing only on Linux.
Beer28 wrote:OK, I'm done posting about this, I have work to do.
I wonder if you have a job. For every 10-line post around here you come back with a 3-chapter worthless reply. That takes time (or you have a nonsense generator).
Let's get this perfectly strait.
I had originally mentioned sharing libraries, you point me to an article that lets you specify a directory in the registry to have the module loader look in the program folder to load a dll first.
Essentially, letting the dll's not share between apps, but use the dll's as componentized code. Where each app has it's own private version of an otherwise shared library.
That is NOT the same as linux's side by side shared library versioning where all applications share dependant libraries that can be different versions of the same library in /usr/lib/ or /lib
That's ONE, one instance of where you are trying to mislead to prove your point about a feature windows does NOT HAVE.
Now when I called you on this and raised the point that I wrote of, side by side concurrent regular shared libraries that all applications share, NOT COM or .NET or java, you change the topic to highlight that .NET allows 2 versions of the same library because it holds the version # in it's metadata.
Guess what? I never talked about IL or Java code, you can't mix apples and oranges. That wasn't the original topic, and I don't care how much you try to change it so you don't look dumb it's still wrong.
You probably know it's wrong and you don't care because you don't want to look foolish.
Are you "ignorant" or what? Do you need a demo?
In Windows, you can create libraries or components. Let's say that we have such a library and let's call it My.dll. Assuming that we have two versions, 1.0 and 2.0, we can have both versions installed on a system at the same time (obviously not in the same folder since the files have the same name).
Now, let's assume that we have four applications, App1 to App4. If App1 and App2 were compiled with My.dll version 1.0 and App3 and App4 were compiled with My.dll version 2.0, each application will use the correct version of My.dll, provided that the library and the applications have side-by-side support. And, to make you even happier, My.dll v1.0 will be shared between App1 and App2, as will be My.dll v2.0 between App3 and App4.
You can do this for
1. Traditional applications using regular Windows DLLs (with exported symbols), as was the GDI+ example
2. Applications using COM components
3. .NET applications
If all you understood from the links I provided is that you can tweak the Windows or the CLR loader to look up for assemblies in a certain order, then excuse me, my friend, you are a total "ignorant". I'm glad we got that straight.
PS: If you really want me to, I can come up with three simple demos, one for traditional libraries, another for COM and yet another one for .NET. But I will only build them if you promise that once I publish them on C9, you'll start a thread in the coffeehouse named <Ok, I'm totally "ignorant">
Beer28 wrote:This is for COM/GUID/CLSID, not dll libraries with normal import/export interfaces.
Normal shared libraries do not need to be registered,
Let's take a look at my C:\Windows\WinSxS folder:
Directory of C:\WINDOWS\WinSxS(I removed the contents of the subfolders for brevity). Now, for instance, I have two versions of GDI+ installed at the same time (126.96.36.199 and 1.0.2600.2180). If you take a look at any of them with depends.exe (a tool in Visual Studio), you'll see 609 exports but none of them are the familiar DllGetClassObject, DllCanUnloadNow, or DllRegisterServer/DllUnregisterServer. These are not COM components. On my XP machine, I can run side by side Win32 DLLs. This might be some interesting reading for you.
29.04.2005 14:01 <DIR> .
29.04.2005 14:01 <DIR> ..
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_4a588028
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_e9b892b4
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_d336d953
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a41d4c58
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.DebugOpenMP_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_429040ef
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.MFCLOC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_0fee1eb7
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_ba9f05b9
29.04.2005 14:01 <DIR> amd64_Microsoft.VC80.OpenMP_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_eabe604e
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_47a980e8
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_e7099374
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_d087da13
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a16e4d18
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.DebugOpenMP_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_3fe141af
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.MFCLOC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_0d3f1f77
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_b7f00679
29.04.2005 14:01 <DIR> ia64_Microsoft.VC80.OpenMP_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_e80f610e
08.03.2005 16:07 <DIR> InstallTemp
29.04.2005 14:01 <DIR> Manifests
25.04.2005 15:23 <DIR> Policies
28.01.2005 23:00 <DIR> x86_Microsoft.Tools.VisualCPlusPlus.Runtime-Libraries_6595b64144ccf1df_188.8.131.52_x-ww_ff9986d7
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_184e9a48
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_b7aeacd4
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_a12cf373
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_72136678
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.DebugOpenMP_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_10865b0f
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.MFCLOC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_dde438d7
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_88951fd9
29.04.2005 14:01 <DIR> x86_Microsoft.VC80.OpenMP_1fc8b3b9a1e18e3b_8.0.50215.4652_x-ww_b8b47a6e
28.01.2005 23:00 <DIR> x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_184.108.40.206_x-ww_1382d70a
28.01.2005 23:00 <DIR> x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9
28.01.2005 23:00 <DIR> x86_Microsoft.Windows.CPlusPlusRuntime_6595b64144ccf1df_220.127.116.11_x-ww_2726e76a
28.01.2005 23:00 <DIR> x86_Microsoft.Windows.CPlusPlusRuntime_6595b64144ccf1df_7.0.2600.2180_x-ww_b2505ed9
28.01.2005 22:59 <DIR> x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_18.104.22.168_x-ww_8d353f13
28.01.2005 22:59 <DIR> x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.2600.2180_x-ww_522f9f82
28.01.2005 23:00 <DIR> x86_Microsoft.Windows.Networking.Dxmrtp_6595b64144ccf1df_22.214.171.124_x-ww_468466a7
28.01.2005 23:00 <DIR> x86_Microsoft.Windows.Networking.RtcDll_6595b64144ccf1df_126.96.36.199_x-ww_d6bd8b95
28.01.2005 23:00 <DIR> x86_Microsoft.Windows.Networking.RtcRes_6595b64144ccf1df_188.8.131.52_en_16a24bc0
29.04.2005 13:48 <DIR> x86_mscorlib_b77a5c561934e089_184.108.40.206_x-ww_50b7dab7
29.04.2005 13:48 <DIR> x86_System.EnterpriseServices_b03f5f7f11d50a3a_220.127.116.11_x-ww_7d5f3790
If you have dll's in each program's dir in Program files, that defeats the purpose of library sharing in the first place, and reduces dll's to componetizing code.
Actually, this is achieved with Registration-Free COM, something that has been introduced in Windows XP and .NET Framework to allow managed components to use unmanaged COM components without registering them. Side-by-side COM components and DLL/COM redirection do not work that way. Maybe the article I proposed to you was too difficult. Get a lighter reading here or here. You'll see that you can have multiple versions of the same COM component installed and multiple applications using them, each bound to the version of the component they're used to.
Sorry about the language I used yesterday. Next time I'll use "ignorant" instead of "idiot".
Beer28 wrote:And unlike windows dll's, multiple versions of a dependant library may co-exist to fill application dependancies, like you probably have multiple versions of libstdc++ in your /usr/lib dir
So because the versioning is in the actual name of the shared object library it eliminates some of the problems you see with dependancy upgrades on windows. Like dllhell.
EDIT: So 5 applications that all rely on different versions of a shared library(dll-.so) may co-exist on one system. On windows mfcX.dll has the version in the filename, but most of them don't.
My guess is that if you have no idea what you're talking about, you shouldn't talk about it at all.
Side-by-side coexistence of COM components (and DLLs) has been supported in Windows since Windows 98 Second Edition. Please take a look at http://msdn.microsoft.com/library/en-us/dnw2kcli/html/W2Kcli_chapter3.asp before making dumb statements like the ones above.
(Later edit: And I'm talking about native DLLs. Managed DLLs have this feature out of the box anyway)
I understand that many people may have opinions that differ from mine. I have quite a lot of friends who enjoy working on Linux more than on Windows, and I'm fine with that. But I can't stand total idiots. Sorry for being so blunt again.