Ovidiu.Platon Ovidiu.​Platon

Niner since 2004

Nevermind about me. Tell me something about yourself.


  • Owen Braun and Chris Pratley - Talking about OneNote

    Speaking of OneNote, you might find an interesting set of videos on StationeryIsBad.com.
  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    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?
  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    Absolutely, Beer.
  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    Yes Beer, you're right, whatever you said. Now calm down...
  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    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.
  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    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.
  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    Beer28 wrote:
    OK, I'm done posting about this, I have work to do.

    Big Smile:D:D
    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).

    Beer28 wrote:

    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.

    Here's TWO.

    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"> Tongue Out

  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    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

    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_6.0.0.0_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_6.0.0.0_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_7.0.0.0_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_1.0.0.0_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_5.2.2.3_x-ww_468466a7
    28.01.2005  23:00    <DIR>          x86_Microsoft.Windows.Networking.RtcDll_6595b64144ccf1df_5.2.2.3_x-ww_d6bd8b95
    28.01.2005  23:00    <DIR>          x86_Microsoft.Windows.Networking.RtcRes_6595b64144ccf1df_5.2.2.3_en_16a24bc0
    29.04.2005  13:48    <DIR>          x86_mscorlib_b77a5c561934e089_2.0.0.0_x-ww_50b7dab7
    29.04.2005  13:48    <DIR>          x86_System.EnterpriseServices_b03f5f7f11d50a3a_2.0.0.0_x-ww_7d5f3790

    (I removed the contents of the subfolders for brevity). Now, for instance, I have two versions of GDI+ installed at the same time ( 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.

    Beer28 wrote:

    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".

  • Martin Taylor and Bill Hilf - Linux at Microsoft, Part II

    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 https://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.
  • Steve Millet - What is Indigo?

    There seems to be a lot of confusion surrounding Indigo. I would also recommend reading the article Introducing Indigo: An Early Look

  • Phalanger: PHP .NET compiler revealed

    Wow. I did know that ASP pages are somewhat faster than their PHP equivalent and that ASP.NET rocks, but the difference between pages compiled with Phalanger and regular PHP/PHP+Zend pages are impressive!
  • Suzanne Cook - Developing the CLR, Part II

    WinInsider wrote:
    Beer28 raises very important point. Many companies want to protect their intellectual property (resources and time) that they put into making a software product, and it is a big issue, knowing that someone can take .NET DLL or EXE and quite easily decompile. I know there are tools that "obfuscate" the MSIL, but do not come close to ASM native image.

    I am not with the latest buzz, but I would hope that next version of VS 2005 would have much better NGEN that not only could put .NET Native Image into GAC, but also produce standalone app, that could only be run on target platform that has compatible .NET libraries installed.

    I know several people that just look at assembly code (even optimized) and tell you what it does. If you play with a debugger long enough, comparing assembler with the original source, in a few weeks you'll end up reverse engineering x86 assembler as well. Trust me on this one, the assumption that x86 asm is "safer" than MSIL is wrong. You can hack your way into anything if you're really determined.

    While we're at it, the fears themselves are largely unfounded. On the one hand, a good developer can figure out how a feature works just by playing with it for a while and implement it on his own. On the other hand, I think that no company in the world would be willing to face the legal consequences, the PR losses and all other subsequent "blessings" associated with the uncovering of such practices.

    Don't count on NGEN for obscurity. In v2, NGEN saves all metadata in the output file, so you get an executable file that's really easy to "understand". And in order to run NGEN-ed executables, you still need the original IL image.
View All