• Draxom (unregistered) in reply to JS

    Isn't it obvious? Chris killed Charles and absorbed all his power, experiences, and job responsibilities. There can be only one CSR!

  • LA (unregistered) in reply to JS
    JS:
    Can someone tell me who is Chris and what did he do with Charles?

    Google is your friend. Use "Chris Carmichael"

  • the lone luncher (unregistered) in reply to deckard
    Comment held for moderation.
  • Steven (unregistered)

    This is TRWTF:

    Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument.

    This should obviously be replaced by:

    Of course, this program doesn’t exist, so it will then tell the user to go screw herself.

    Microsoft, I expect this fixed in the next service pack, along with all the other things random anonymous people complain about on the internet.

  • Evan (unregistered) in reply to Ralph
    Ralph:
    This whole story just reeks of layer upon layer of WTF.

    For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

    So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

    When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

    All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

    Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

    I_know._I_hate_spaces,_which_is_why_I_never_use_them._Interesting_that_you_do,_though._Clearly_you_haven't_seen_the_light_in_its_full_glory_yet.

    OK, less sarcastically, I don't get that position. Pretty much at all. Yes, spaces makes some things less convenient, but it makes lots of other things more convenient, especially in the GUI world, where there's essentially zero problems because of spaces. Even in the command line and scripting world, it's usually only a somewhat mild inconvenience because now you have to type a few more quotes or escapes.

    But computers are here for humans to use. We use spaces, very reasonably. Why should I have to call a file "01_In_The_Flesh"? It's called "In The Flesh"! Computers should be programmed to match our thinking as best as possible, not the other way around. "You shouldn't be able to use spaces in file names" is, IMO, almost the quintessential example of the exact wrong way to think.

    Also, you have some chronology messed up. But whatever. And none of this is really intended to justify the Windows behavior of just trying different breaks between commands and arguments, though I do suspect their hand may have been forced a little because of backwards compatibility problems.

  • Zylon (cs)

    "MMPORG"? Massively Multiplayer Playing Online Role Game, Alex?

  • shadowman (cs) in reply to deckard
    deckard:
    And it will try to execute “C:\Program” as a file, passing it “Files\id Software\Doom\Doom.exe -nomusic” as argument to that executable. Of course, this program doesn’t exist, so it will then try to execute “C:\Program Files\id”, passing it “Software\Doom\Doom.exe -nomusic” as argument. If this doesn’t exist, it will try to execute “C:\Program Files\id Software\Doom\Doom.exe” passing in “-nomusic” as an argument. It would continue this way until a program existed and started, or until the path was depleted and no program was to be found.

    Was there ever really a version of Windows that worked this way? I know for a fact that XP doesn't. If you give it a path without quotes it will take everything up to the first space as the command, and everything afterwards as arguments. If that command doesn't exist, it gives up and spits an error. I find it hard to believe that any released version of Windows ever did the trial-and-error approach described by OP...

    Windows 95, 98 & ME also stored names like c:\progra~1 for backwards compatibility. The 1 at the end would change to a 2 and so forth to prevent collisions, but I guess somehow it failed here. Perhaps the badly-written program was doing something directly that triggered a filesystem bug?

  • TehWTF (unregistered)

    Sorry, it's not working for me. I'm not intent on proving that an incorrectly quoted command line will run C:\PROGRAM.EXE because that's obvious. What I'd like to see is an example where an incorrectly quoted command line will cycle through the spaces until it finds a runnable program then split the rest off as the argument list.

    CMD.EXE uses CreateProcess because that's the only way to create a process. CMD must do some processing on the command line before calling CreateProcess to ensure the wrong behavior doesn't pop up.

    In XP CMD:

    C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe
    'C:\Program' is not recognized ...

    In XP Window-R run program

    c:\program files\Malwarebytes' Anti-Malware\mbam.exe
    (program launches because the dialog knows that quotes must surround the file name)

    In XP Window-R run program

    c:\program files\Malwarebytes' Anti-Malware\mbam.exe -hello
    (error because the entire string after automatic quoting is not a file)

    In Windows XP

        STARTUPINFOA siStartupInfo;
        PROCESS_INFORMATION piProcessInfo;
        memset(&siStartupInfo, 0, sizeof(siStartupInfo));
        memset(&piProcessInfo, 0, sizeof(piProcessInfo));
        siStartupInfo.cb = sizeof(siStartupInfo);
        if (CreateProcessA(NULL,_strdup("c:\\program files\\Malwarebytes' Anti-Malware\\mbam.exe -hello"), 0, 0, FALSE,CREATE_DEFAULT_ERROR_MODE, 0, 0,&siStartupInfo, &piProcessInfo) != FALSE);
            WaitForSingleObject(piProcessInfo.hProcess, (5000));
        exit(0);

    ... ooh, that works. Now find me an example that is accessible by users.

  • shadowman (cs) in reply to Bananananarama
    Bananananarama:
    On Windows 7, I (as admin) created C:\Program.exe and entered [ C:\Program Files ] at the Start>Run dialog. It opened the "Program Files" directory. When I enter [ C:\Program Foobar ], it runs Program.exe. The search order seems to be reversed.

    This seems to be talking about pre-NT windows-32. So before XP, like win95 perhaps. At least before NTFS which has native long filename support.

  • ThatGuy (unregistered) in reply to Ben Jammin
    Ben Jammin:
    I love this site. A WTF gets posted. People doubt it. People try to prove their doubts. Other come up with proofs and historical threads and documentation all showing that the WTf is in fact real, yet still people doubt the integrity of the WTF.

    TRWTF is that, despite coming to this site for however long you have been coming, you still think, "There's no way they could be that dumb."

    Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. -Al E.

  • PRMan (unregistered) in reply to deckard

    [quote user="deckard"][quote user="Andrew"][quote user="deckard"] CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes. [/quote]

    Then why does cmd.exe empirically not work this way?[/quote]

    Because it parses the command line itself. It doesn't just hand it straight to CreateProcess.

  • PRMan (unregistered) in reply to TehWTF
    TehWTF:
    Sorry, it's not working for me. I'm not intent on proving that an incorrectly quoted command line will run C:\PROGRAM.EXE because that's obvious. What I'd like to see is an example where an incorrectly quoted command line will cycle through the spaces until it finds a runnable program then split the rest off as the argument list.

    CMD.EXE uses CreateProcess because that's the only way to create a process. CMD must do some processing on the command line before calling CreateProcess to ensure the wrong behavior doesn't pop up.

    In XP CMD:

    C:\Program Files\Malwarebytes' Anti-Malware\mbam.exe
    'C:\Program' is not recognized ...

    In XP Window-R run program

    c:\program files\Malwarebytes' Anti-Malware\mbam.exe
    (program launches because the dialog knows that quotes must surround the file name)

    In XP Window-R run program

    c:\program files\Malwarebytes' Anti-Malware\mbam.exe -hello
    (error because the entire string after automatic quoting is not a file)

    In Windows XP

        STARTUPINFOA siStartupInfo;
        PROCESS_INFORMATION piProcessInfo;
        memset(&siStartupInfo, 0, sizeof(siStartupInfo));
        memset(&piProcessInfo, 0, sizeof(piProcessInfo));
        siStartupInfo.cb = sizeof(siStartupInfo);
        if (CreateProcessA(NULL,_strdup("c:\\program files\\Malwarebytes' Anti-Malware\\mbam.exe -hello"), 0, 0, FALSE,CREATE_DEFAULT_ERROR_MODE, 0, 0,&siStartupInfo, &piProcessInfo) != FALSE);
            WaitForSingleObject(piProcessInfo.hProcess, (5000));
        exit(0);

    ... ooh, that works. Now find me an example that is accessible by users.

    I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem.

  • Jean (unregistered) in reply to Draxom
    Comment held for moderation.
  • Slicerwizard (unregistered) in reply to PRMan
    PRMan:
    I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem.
    Only if they pass a NULL application name to CreateProcess. Most programmers aren't that stupid.

    Hm, I want to run program x and pass it arguments y and z;

    Do I pass a program name and args

    createProcess("unambiguous x that doesn't need quotes", "y z")

    or do I needlessly append a bunch of strings

    createProcess(NULL, ""x that most likely needs quotes" y z") ???

    Tough choice...

  • default_ex (unregistered) in reply to Draxom
    Comment held for moderation.
  • Evan (unregistered) in reply to Slicerwizard
    Slicerwizard:
    PRMan:
    I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem.
    Only if they pass a NULL application name to CreateProcess. Most programmers aren't that stupid.

    Hm, I want to run program x and pass it arguments y and z;

    Do I pass a program name and args

    createProcess("unambiguous x that doesn't need quotes", "y z")

    or do I needlessly append a bunch of strings

    createProcess(NULL, ""x that most likely needs quotes" y z") ???

    Tough choice...

    Or they pass NULL and don't quote it.

    Considering what site I'm on I know what I'm guessing...

  • Epon (unregistered)

    Woah woah woah......

    We all know it's WINWORD.EXE, not WORD.EXE

  • LOADING (unregistered) in reply to DysgraphicProgrammer
    DysgraphicProgrammer:
    Ralph:
    This whole story just reeks of layer upon layer of WTF.

    For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

    So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

    When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

    All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

    Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

    Linux allows spaces in file names. Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems.

    Piss people off by creating booty trap files with things such as hyphen as the first character.

  • LOADED (unregistered) in reply to LOADING
    LOADING:
    DysgraphicProgrammer:
    Ralph:
    This whole story just reeks of layer upon layer of WTF.

    For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

    So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

    When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

    All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

    Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

    Linux allows spaces in file names. Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems.

    Piss people off by creating booty trap files with things such as hyphen as the first character.

    Piss off windows users by creating folders with names beginning with a space.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)
    Comment held for moderation.
  • Darth Paul (unregistered)

    I once worked somewhere which insisted on using a locally manufactured antivirus solution because it was locally manufactured, not because it worked.

    One of the interesting properties of this antivirus package was that it stripped all paths to all executables of all quote marks within the entire Windows Registry, so that all document file extensions attempted to launch "C:\Program.exe" when a file was double-clicked in Windows Explorer.

    Of course, management was angry with me for pointing this out and reminded me quite sternly that it was strict policy to use local suppliers where available.

  • floydnazi (unregistered) in reply to Evan
    Evan:
    It's called "In The Flesh"!
    actually, it's called "In The Flesh?"

    just saying....

  • Ralph (unregistered) in reply to floydnazi
    floydnazi:
    Evan:
    It's called "In The Flesh"!
    actually, it's called "In The Flesh?"

    just saying....

    My favorite album was by a band called "De\|/o". Yes including the quotes.

    I should be able to create that filename in Windows, right?

    I should be able to dump whatever random garbage I want into my computer and it will sift it all out, right?

    I should never have to learn anything or follow any rules to use the most complicated piece of machinery ever built -- the only major invention that leverages your mind not your dumb brute strength. There should be no investment at all on my part for the incredible benefits I will receive. You take a class and pass a test to operate a simple steering wheel, gas pedal and brake, but no training for computers! They're special! They're ideal for the dumbest of the dumb! We want a world where our computers are all smarter than we are!

    I wish I could ship you all to another planet.

  • Simon (unregistered) in reply to J
    J:
    Linux doesn't put programs on a path that has spaces unless the program wants them. I haven't seen an install of Linux that includes a space in the default PATH.

    More importantly, it doesn't try to guess what a space means. If a command contains a space, it's always interpreted as a separator unless quoted or escaped.

  • Rosuav (unregistered) in reply to deckard
    deckard:
    Andrew:
    CreateProcess is the function that creates processes, so what's left for you to miss? Cmd.exe imports it just like every other Win32 subsystem application that launches other processes.

    Then why does cmd.exe empirically not work this way?

    You're looking at two quite different things: a command line parser, and an API. The parser is probably what's preventing this behavior from being a problem. It's the same with path separators; Windows accepts / as a path sep, but most command-line parsers depend upon it for options, and so can't use it for paths. But quotes can sometimes override that; I can, on XP, type:

    copy con "/path/filename"

    and it creates that file in that path.

    CreateProcess has a gotcha that almost nobody will ever discover except through massive confusion like this.

  • mshater (unregistered) in reply to AlanM

    As much as I hate M$, I have to agree with you. The antivirus was to blame here and was VERY poorly designed. This could, and probably did, result in actual malware being run repeatedly. Kind if the opposite of what it was supposed to do.

    +1 Internets to you, Sir, for your use of the Captcha.

    Captcha: abigo. "That antivirus was abigo pile of WTF."

  • emurphy (cs) in reply to emurphy
    emurphy:
    More seriously, in what environment does the aforementioned guesswork actually occur? I just tried deliberately invoking it (copying notepad.exe to c:\program.exe) and wasn't able to.

    To clarify:

    1. Copy c:\windows\notepad.exe to c:\program.exe
    2. From cmd.exe, run
      c:\Program Files(etc)
      -> it runs the copy of Notepad
    3. Create a shortcut, enter command line
      c:\Program Files(etc)
      , save -> it puts double quotes around the command line

    So, while the WTF is plausible, it seems limited to systems where (a) #3 works differently (I'm on Win7, I think someone mentioned it working differently in Vista) and (b) InterferAV dumps quarantined stuff in C:\ (presumably due to failing to check for a botched environment variable or something).

  • Mad Bug (unregistered)

    Those that defend Microsoft have a valid point about backwards compatibility. My argument is that Windows took a long time to be not junk as a result of that because DOS was garbage. A hobby OS bought at the last minute that was not fit for purpose. It's up there with IE6. The problem isn't how bad it is/was, but the fact that it has to break so much stuff in the future.

    You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way.

  • emurphy (cs) in reply to emurphy
    emurphy:
    emurphy:
    More seriously, in what environment does the aforementioned guesswork actually occur? I just tried deliberately invoking it (copying notepad.exe to c:\program.exe) and wasn't able to.

    To clarify:

    1. Copy c:\windows\notepad.exe to c:\program.exe
    2. From cmd.exe, run
      c:\Program Files(etc)
      -> it runs the copy of Notepad
    3. Create a shortcut, enter command line
      c:\Program Files(etc)
      , save -> it puts double quotes around the command line

    So, while the WTF is plausible, it seems limited to systems where (a) #3 works differently (I'm on Win7, I think someone mentioned it working differently in Vista) and (b) InterferAV dumps quarantined stuff in C:\ (presumably due to failing to check for a botched environment variable or something).

    Or possibly (a') #3 is replaced by some other thing that eventually reaches CreateProcess(). I don't grok the details of that one so I'll just file it under "maybe" and let other folks continue to work it over.

  • MrEricSir (cs) in reply to TehWTF
    CMD.EXE uses CreateProcess because that's the only way to create a process.
    Let's not forget that ShellExecute/ShellExecuteEx don't work exactly the same as CreateProcess.

    And let's also not forget that you can use Nt/ZwCreateProcess directly and get yet a different set of behavior...

  • x (unregistered) in reply to Mad Bug
    Mad Bug:
    You can claim they need to do backwards compatibility, but it would be nice for them to build their foundations out of stone rather than straw. Though to be fair, we are talking history now, we just all wish history went a different way.
    It went the only way it could: where the customer wanted to go. There is no way around that -- if you won't give it to him, he will get it from somebody else. When that happens, your comparatively late, comparatively over-budget, and comparatively pristine design will end up living out its life never having been executed outside your own machine, never making its individual contribution toward improving the ecosystem, the way you had envisioned it would.

    Therefore: you make what the people want, first; second, you make it correct. If you reverse the two, you'll find yourself in a position where it is irrelevant whether you ever make anything at all.

  • Scott Wood (unregistered)

    TRWTF is updating the executable, rather than data, every time there's a new game released.

  • Spider Flyer (unregistered) in reply to Saxton
    Comment held for moderation.
  • Defenestrate (unregistered) in reply to PRMan
    PRMan:

    I would imagine that many apps use CreateProcess internally to run other processes. Any of these would trigger the problem.

    ... And that is where you would be wrong.

    It is, was, and would be very rare for a Windows app to use CreateProcess unless it was a script or an app ported from another OS.

    Not to say that it would never happen, but it's rare enough that I've be reading and writing Windows apps for 15 years and I've never seen it happen except in VB or OpenSource apps.

    All current versions of Windows have a light-weight thread API, and a clunky create-process API (I understand that in unix it's the other way around??), and it's standard to call functions from standard Dynamic Link Libraries rather than from standard executables (I understand that in unix it's the other way around??)

  • CPM (unregistered) in reply to Mad Bug
    Mad Bug:
    My argument is that Windows took a long time to be not junk ...

    It's up there with IE6.

    That might be true. Perhaps you are too young to remember that IE6 became the dominent browser because it was so much better than the market leader.

    Kind of like FF.

  • Dani (unregistered) in reply to DysgraphicProgrammer
    DysgraphicProgrammer:
    Ralph:
    This whole story just reeks of layer upon layer of WTF.

    For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

    So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

    When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

    All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

    Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

    Linux allows spaces in file names. Linux also has CaSeSeNsItIvE file names, and allows a large variety of special characters in file names. Which also cause problems.

    Mac allows all characters in file name, including / \ and even null character and the funny part is that it doesn't make problems if you use objc correctly.

  • Mad Bug (unregistered) in reply to CPM

    Unfortunately I'm not too young to remember that. Ahh the bad old days of dealing with Netscape 4.7 and the like.

    Hmm, maybe the fault of the IE6 legacy was the integrating of OS and Browser for political reasons rather than technical ones, making the upgrade path at the time more difficult.

    I must admit though, the continuation of Netscape as the Mozilla sweet was awful, until somebody decided it was time for a full re-write as Phoenix, I mean Firebird, I mean Firefox.

  • Dave (unregistered) in reply to big picture thinker
    big picture thinker:
    Nice explanation. "Interfersoft" seems like an anonymized name. I'd be interested in the actual name so, I know which to avoid.

    Norton, Symantec, McAfee, take your pick. Whenever any anti-virus software-induced s**t happens it's almost certainly one of those.

  • Shachar (unregistered) in reply to deckard

    I know for a fact that Windows 95 and Windows 98 did, in fact, behave in this way. I have a dim recollection that Windows 2000 did too, but I'm not sure enough about that.

    And yes, it's a horrid bug, and, yes, it is, primarily, Microsoft's fault.

    Shachar

  • Mad Bug (unregistered) in reply to Mad Bug

    Mmmm Mozilla sweets*.

    suite

  • Dave (unregistered) in reply to Draxom
    Comment held for moderation.
  • Dave (unregistered) in reply to Jean
    Comment held for moderation.
  • HAL9000 (unregistered) in reply to Dave

    AVG appears to have been on the system when the registry dump was generated, but the poster said he'd uninstalled McAfee. There would be no need to have McAfee on there, the process could be: (1) McAfee makes "C:\program.exe", (2) McAfee gets deleted and replaced with AVG, (3) McAfee is gone but "C:\program.exe" lingers, continuing to cause the trouble.

    It definitely sounds like something that one of the big bloatware flavoured AV programs would do!

  • L. (unregistered) in reply to Ralph
    Ralph:
    This whole story just reeks of layer upon layer of WTF.

    For starters, spaces in filenames and pathnames? Certifiably insane. Begging for trouble. Surprise! Trouble happened! A billion times over!

    So instead of correcting the error, we'll just "fix" it by trying this, that, the other, hoping eventually to guess what was intended.

    When you have a computer guessing, and trying, and failing, and trying something else... well can you be even the least bit surprised when you get random behavior from a deterministic machine?

    All you knee-jerk bootlicking Redmond-worshippers cannot justify this insanity. It is a poorly thought out design error of epic proportions. No excuses.

    Yes, I know most every copycat GUI does the same thing. Doesn't make it any less stupid.

    Sure . I didn't know to this day that you could simply C:/Program Files/whatever/exe.exe without using the double quotes - maybe I'm too holy for windows --

  • L. (unregistered) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    MrPablo:
    The real WTF is 'This program looks like a virus, let's move it to the root directory!' Renaming it so that it is frequently invoked by Windows is icing on the cake.
    And the fact that it would have done the same thing with real malware is the poison in the icing.

    And the fact that it does all that in Windows is the icing on the poison.

  • L. (unregistered) in reply to Foo Bar
    Foo Bar:
    If this trick (c:\Program.exe) was ever real, it only worked in Windows 9x variants, the ones running on top of DOS.

    Captcha: suscipere. "I am suscipere about the claims in this WTF."

    And that restricts us to ultima online and what other mmo ?

  • L. (unregistered) in reply to Draxom
    Comment held for moderation.
  • idclev (unregistered) in reply to MrDaniil

    DOOM has cheat codes. One of them allows you to change to desired level (idclev).

  • L. (unregistered) in reply to Anon
    Anon:
    When I read this story I thought it's bullshit. But not because of Windows behavior, but because of antivirus's. Could you imagine any antivirus putting a quarantined file IN ROOT FOLDER? Only a deliberately insane person does that.

    And how would you know ? If you're such an ignorant as to think Windows is NOT responsible of the major fail here, how could your point of view be worth a shit ?

    Programs are allowed to be shittier than OS's and that's the point in Linux too - it's just that here the OS is such a piece of crap that AV software doing that is just par for the course.

  • Program File This (unregistered)

    Interesting. Was not aware of this.

    But ayup, at the CMD line I'm certainly able to replicate this under Windows 7. (copied notepad.exe to the root, renamed it program.exe and then tried to execute

    Program Files\Internet Explorer\iexplore.exe

    Notepad came up and gave me a file not found error. VERY interesting.

Leave a comment on “The Core Launcher”

Log In or post as a guest

Replying to comment #:

« Return to Article