GUI's gotta be doing it for some .DLL


  • Winner of the 2016 Presidential Election

    Came across some fun nonsense today. Person staunchly convinced that you can right click all dll files and "open the application" that way.

    Scarily enough, this guy found the one customer daft enough to believe him. Just got out of a two hour call of "the DLL isn't working."

    Just... kill all the people in sales. All of them.



  • What, they don't know about rundll32.exe? :laughing:


  • Winner of the 2016 Presidential Election

    what is that high tech bs? :stuck_out_tongue:

    they genuinely mistook DLLs for a standalone application. There was confusion when they clicked it and the "application splash screen" doesn't come up.



  • I had to spend like an hour convincing my boss that the C# DLL I was writing needed to raise an event or have a callback, so it didn't have any knowledge of "Console". This was during a code review. It was pissing me off. I said as an example, "say we wanted this functionality in a Windows Service..." and he was like, "we're never going to do that." And I was like, "I know, but I'm explaining WHY this is correct" and anyway.



  • Well, duh. Everyone knows there are only two types of software:

    • Software where every facet can be controlled via a nice, user-friendly GUI
    • Horrible software no reasonable person ever will use.

    </blakeyrant>



  • I'm a retard!

    </PleegWat>


  • Discourse touched me in a no-no place

    @blakeyrat said:

    I had to spend like an hour convincing my boss that the C# DLL I was writing needed to raise an event or have a callback, so it didn't have any knowledge of "Console".

    What is this black magic?


  • Winner of the 2016 Presidential Election

    What is this dialog box? It looks like Win95 infected a modern website!


  • Discourse touched me in a no-no place

    @Onyx said:

    What is this dialog box? It looks like Win95dows 10 infected a modern website!

    <ytpme eb t'nac tsoP



  • A demonstration that a program which imports Windows.Forms can draw forms? What's your fucking point?


  • Discourse touched me in a no-no place

    @blakeyrat said:

    A demonstration that a program which imports Windows.Forms can draw forms? What's your fucking point?

    My point is that a program that's compiled as a console executable, and thus, because you're apparently too stupid to read has a console, can also have windowed elements. Which would probably include having and being able to raise events but I'm not going to take the time to write that for you.


  • Winner of the 2016 Presidential Election

    I mean...

    Technically...

    You could run the whole program in a DLL and use dllmain.

    No, that's not a good idea, why are you looking at me like that?



  • You can also attach a console to a windows app. You're still missing Blakey's point. He wants to abstract the console away from his DLL. Usually a DLL shouldn't know if it's loaded by a console app or a windows app.


  • Discourse touched me in a no-no place

    @NedFodder said:

    You're still missing Blakey's point.

    Not hardly. I'm saying he was probably wrong telling his boss it can't be done, but am too lazy to actually prove it so I'm not saying he is wrong.

    @NedFodder said:

    Usually a DLL shouldn't know if it's loaded by a console app or a windows app.

    Generally true, but it's convenient for logging. Especially because console spew to when there's no console simply goes into the bit bucket.


  • mod

    @FrostCat said:

    he was probably wrong telling his boss it can't be done

    I think he was saying it shouldn't be done, not can't.



  • To add to this, if I were using a DLL for something and it suddenly started popping open windows on me, I'd kill it with fire.



  • Also, if it was converted to a windows service like he mentioned, it would stop working IIRC


  • Discourse touched me in a no-no place

    @powerlord said:

    To add to this, if I were using a DLL for something and it suddenly started popping open windows on me, I'd kill it with fire.

    IIRC it won't pop a console, but if you run it from one, you'll see the console spew.

    It might be a useful technique. Myself, since I usually don't need massive logging I tend to just use OutputDebugString and DbgView.



  • @FrostCat said:

    My point is that a program that's compiled as a console executable,

    There's no such thing in Windows. A program is just a program. If it opens a window, then it's a program with a window. Whoop-de-shit. If it doesn't, and only sends output to the console, then it's a program with only a console. Whoop-de-shit. If it doesn't do either but only outputs via, say, Event Viewer, then you probably should be running it as a Service. But that's still ok for an application, too.

    What you're referring to is a convenience offered by Visual Studio, to template-out a program that's intended to be a Console Application. But if you include Windows.Forms and pop open a window, guess what? Suddenly it's not.

    (Oh, and BTW? I'm 99.9% sure Linux works the same way. A GUI program is no different than a CLI program, except the GUI one opens windows and the CLI one does not. Given it was ages ago, but I clearly remember running Linux apps that could do either mode in a single executable.)



  • @FrostCat said:

    I'm saying he was probably wrong telling his boss it can't be done,

    I DIDN'T TELL HIM THAT YOU GIANT RETARDED DICKHOLE!

    I told him it's a BAD IDEA to do it, not that it CAN'T be done. I'd actually LOVE IT if C# enforced that, except there's a legit need for some DLLs to actually interact with the UI. Not a common thing, but there are non-WTF uses for it. (Think of, like, a Paint.NET plugin that needs a custom widget in its configuration.)

    @Yamikuronue said:

    I think he was saying it shouldn't be done, not can't.

    Thank God, literate people.

    Why do we still let FrostCat post here?



  • @fbmac said:

    Also, if it was converted to a windows service like he mentioned, it would stop working IIRC

    Stupidly, no. Microsoft's backwards compatibility handles this, believe it or not. It'll open the windows on an "anonymous" desktop running as the Service's user, then give you a little notification that says something like, "a Service opened a window, click Ok to go to the alternative desktop and view it". The alternative desktop is blank except for whatever the Service draw, and a "return to Windows" button.

    It's really quite amazing how much effort Microsoft went into making this CLEARLY BAD AND WRONG thing work. Kinda work. A bit.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    There's no such thing in Windows. A program is just a program.

    Who disagrees with you? Microsoft!

    d:\>csc /? Microsoft (R) Visual C# Compiler version 1.0.0.50618 Copyright (C) Microsoft Corporation. All rights reserved.
                              Visual C# Compiler Options
    
                        - OUTPUT FILES -
    

    /out:<file> Specify output file name (default: base name of
    file with main class or first file)
    /target:exe Build a console executable (default) (Short
    form: /t:exe)
    /target:winexe Build a Windows executable (Short form:
    /t:winexe)

    An application compiled with /target:winexe will not have a default console.

    d:\Temp>copy con cons.cs using System; public class cons { public static void Main(String[] args) { Console.WriteLine("Moosh!"); } } ^Z 1 file(s) copied.

    d:\Temp>csc /t:exe cons.cs
    Microsoft (R) Visual C# Compiler version 1.0.0.50618
    Copyright (C) Microsoft Corporation. All rights reserved.

    d:\Temp>cons
    Moosh!

    d:\Temp>csc /t:winexe cons.cs
    Microsoft (R) Visual C# Compiler version 1.0.0.50618
    Copyright (C) Microsoft Corporation. All rights reserved.

    d:\Temp>cons

    d:\Temp>



  • @blakeyrat said:

    I clearly remember running Linux apps that could do either mode in a single executable.

    Definitely. Heck, even the perl interpreter can open a GUI if your script uses the right libraries.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    What you're referring to is a convenience offered by Visual Studio, to template-out a program that's intended to be a Console Application. But if you include Windows.Forms and pop open a window, guess what? Suddenly it's not.

    Ooh, guess who's wrong again?

    using System;
    using System.Windows.Forms;

    public class cons : Form
    {
    public static void Main(String[] args)
    {
    Console.WriteLine("Moosh 1!");
    cons c = new cons();
    Application.Run(c);
    Console.WriteLine("Moosh 2!");
    }
    }

    Compile that with /t:winexe, and guess how many lines of console output you get? That's right, 0.

    Dumb shit.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Why do we still let FrostCat post here?

    For the same reason we let you post here.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    I DIDN'T TELL HIM THAT YOU GIANT RETARDED DICKHOLE!

    I told him it's a BAD IDEA to do it, not that it CAN'T be done.

    Also, way to get derailed by a minor detail.



  • Gonna have to agree with Blakey again...

    @FrostCat said:

    /target:exe Build a console executable (default) (Short form: /t:exe) /target:winexe Build a Windows executable (Short form: /t:winexe)

    That's a compiler option, not part of Windows. Those options tell the linker where the entry point of your program is, and that entry point will either attach a console or not.

    @FrostCat said:

    Compile that with /t:winexe, and guess how many lines of console output you get? That's right, 0.

    Only because you have to explicitly attach a console in your code.


  • Discourse touched me in a no-no place

    @NedFodder said:

    That's a compiler option, not part of Windows. Those options tell the linker where the entry point of your program is, and that entry point will either attach a console or not.

    FrostCat:

    pendantic dickweedery acknowledged!

    @NedFodder said:

    Only because you have to explicitly attach a console in your code.

    Yes...because it doesn't get one by default. Which I think I already said.



  • @FrostCat said:

    An application compiled with /target:winexe will not have a default console.

    Ok; what does that have to do with my claim?

    @FrostCat said:

    Compile that with /t:winexe, and guess how many lines of console output you get? That's right, 0.

    And what does that have to do with my claim?

    I'm talking about what a Windows Application Is not "what a particular compiler does with particular options set".

    @NedFodder said:

    Gonna have to agree with Blakey again...

    Yay another literate person.

    @FrostCat said:

    Yes...because it doesn't get one by default. Which I think I already said.

    It doesn't get a window/form by default either, WHAT THE FUCK IS YOUR POINT.



  • Fuck me, you're frustrating today.

    Blakey said, correctly, that from Windows's point of view there is no difference between a console app and a windows app.

    You showed the compiler options for building an app that attached a console automatically, and for building an app that did not attach a console automatically. As Blakey said, it's all conveniences provided by the compiler.

    Then you showed an example of an app that did not attach a console automatically not having a console. I have no idea what you were trying to prove with that.

    If you had done what I said and attached a console explicitly in that code, you would get console output. That proves Blakey's point, there's no difference from Windows's point of view between a console app and a windows app. Either the compiler attached the app to a console automagically, or the coder attached the app to a console manually.


  • Winner of the 2016 Presidential Election

    @FrostCat said:

    It might be a useful technique. Myself, since I usually don't need massive logging I tend to just use OutputDebugString and DbgView.

    Might? That's the first thing I do on Linux if something doesn't work: start it from a shell so I can see what it spews out. I'm annoyed 99.9% of Windows applications don't print a damned thing, and all that might be the problem is a missing DLL or something which I could fix in 2 minutes flat if only it told me instead of silently crashing.



  • @NedFodder said:

    That's a compiler option, not part of Windows. Those options tell the linker where the entry point of your program is, and that entry point will either attach a console or not.

    It's a feature of the PE header that tells Windows which subsystem the executable uses:

    WORD Subsystem
    The type of subsystem that this executable uses for its user interface. WINNT.H defines the following values:

    NATIVE
    1
    Doesn't require a subsystem (such as a device driver)
    WINDOWS_GUI
    2
    Runs in the Windows GUI subsystem
    WINDOWS_CUI
    3
    Runs in the Windows character subsystem (a console app)
    OS2_CUI
    5
    Runs in the OS/2 character subsystem (OS/2 1.x apps only)
    POSIX_CUI
    7
    Runs in the Posix character subsystem


  • rats and cats are natural enemies


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Ok; what does that have to do with my claim?

    Your claim that a DLL with events doesn't know what a console is? I dunno, Drax, it'll probably be forever a mystery to you.

    @blakeyrat said:

    I'm talking about what a Windows Application Is not "what a particular compiler does with particular options set".

    A console application can have windows, as has been demonstrated. Therefore, if someone wanted to log to console from a Windows application, they could merely target the project to be a console application, and they get windows and consoles.

    I spelled it out for you because I know you can't handle deductive reasoning.

    @blakeyrat said:

    It doesn't get a window/form by default either, WHAT THE FUCK IS YOUR POINT.

    That you shouldn't argue with someone who knows more about you than the details of a given thing. You were wrong about a windowed application not having access to a console, not that you can admit it, so instead you bluster and bloviate about triviality as always.

    You oughtta head down into the red light district in Seattle and get your pipes cleaned. It's probably improve your outlook.


  • Discourse touched me in a no-no place

    @NedFodder said:

    f you had done what I said and attached a console explicitly in that code, you would get console output.

    Except that blakey said " the C# DLL I was writing needed to raise an event or have a callback, so it didn't have any knowledge of "Console".

    Any way you parse that it's simply not true. For example, grammatically speaking, if you add "using System", then the program has access to the Console class, but Windows just throws output to the console away. For a different example, if you compile the application the DLL uses as a console application instead of a windows one, you get a free console. Further--as you acknowledge--if you manually create one, you again get one.

    Blakey was wrong wrong wrong when he said "the C# DLL [...] didn't have any knowledge of "Console"". I don't know why you have your panties in a twist about it and can't admit he was wrong, but we all know he is constitutionally unable to, and is only still even talking because he hasn't yet realized he was wrong, because he never admits he was wrong, he just disappears from the topic when he is proven wrong.


  • Discourse touched me in a no-no place

    @boomzilla said:

    It's a feature of the PE header [i.e., part of Windows, not the compiler -- fc]

    No, surely you're wrong, because Princess Cheap Shot Blakeyrat disagrees.



  • @FrostCat said:

    Except that blakey said " the C# DLL I was writing needed to raise an event or have a callback, so it didn't have any knowledge of "Console".

    I read it as him saying he didn't want his code to have any knowledge of that, which is an odd example of anthropomorphism for him, but I assumed it meant he didn't want to import the relevant modules into his code, instead calling something else that can do the needful with the output.

    @FrostCat said:

    No, surely you're wrong, because Princess Cheap Shot Blakeyrat disagrees.

    Yeah, @NedFodder was pretty worked up, too, especially for a guy who was wrong. :stuck_out_tongue:



  • @Onyx said:

    and all that might be the problem is a missing DLL or something which I could fix in 2 minutes flat if only it told me instead of silently crashing.

    That's the linker's job.



  • @FrostCat said:

    Except that blakey said " the C# DLL I was writing needed to raise an event or have a callback, so it didn't have any knowledge of "Console".

    I'm really surprised you can't parse that. @Yamikuronue, @boomzilla and I all had no problem with it. Here's what he meant:

    I have a C# DLL that needs to output some text. Reviewer wants me to write it to the console. I want to raise an event or use a callback so that my DLL does not need to use the console.

    He did not say that the DLL could not use the console. He said he didn't want his DLL to use the console.



  • @boomzilla said:

    https://msdn.microsoft.com/en-us/library/ms809762.aspxWORD SubsystemThe type of subsystem that this executable uses for its user interface. WINNT.H defines the following values:

    Ok; but since an application that draws windows can use the console, and since an application that uses the console can also draw windows, I do not see the point of that.


  • Discourse touched me in a no-no place

    @boomzilla said:

    I read it as him saying [something other than the literal words he typed]

    If I needed industrial-strength logging, or whatever @blakeywrong thought his boss wanted, that he was ignorant of how to produce, I'd probably want to use some sort of log4net type of package. Some of them, IIRC, have a neat feature where the code compiles away to nothing when compiled in Release mode, so you don't even take up space or CPU cycles on logging. But the kind of stuff I work in these days, OutputDebugString is usually sufficient, and/or I'm already writing a "what happened" report for end-user consumption.



  • @blakeyrat said:

    Ok; but since [stuff] I do not see the point of that.

    A lot of Windows is like that.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    That's the linker's job.

    Dynamically-loaded libraries just showed up and gave you a Spock eyebrow-raise.

    :trolleybus: :tropical_drink:



  • Since many of you are coming from a background in 16-bit Windows,

    Holy fuck how OLD is that article... 1994!?

    Does it even apply to NT, or is it talking about Win95 stuff?

    Appears to be a signature WORD of some sort. Always appears to be set to 0x010B.

    "appears to be"? Does this guy even work for Microsoft?


  • Discourse touched me in a no-no place

    @NedFodder said:

    parse

    Never assume @blakeyrat meant anything other than exactly the words he chose to use, or he'll engage in hysterical logorrhea.



  • @FrostCat said:

    @boomzilla said:
    I read it as him saying [something other than the literal words he typed]

    No, fuck that shit. Here's what he said:

    @blakeyrat said:

    I had to spend like an hour convincing my boss that the C# DLL I was writing needed to raise an event or have a callback, so it didn't have any knowledge of "Console".

    He doesn't want to import any modules regarding a console into his code. Probably would have been clearer if he'd said something like, "so it didn't need to have any knowledge..."



  • Is the PE header the same in a managed cli application?



  • @blakeyrat said:

    Holy fuck how OLD is that article... 1994!?

    Does it even apply to NT, or is it talking about Win95 stuff?

    Yeah, it's probably garbage, because you know MS isn't backwards compatible.

    @fbmac said:

    Is the PE header the same in a managed cli application?

    .NET assemblies are built on top of the PE (Portable Executable) file format that is used for all Windows executables and dlls, which itself is built on top of the MSDOS executable file format. The reason for this is that when .NET 1 was released, it wasn’t a built-in part of the operating system like it is nowadays. Prior to Windows XP, .NET executables had to load like any other executable, had to execute native code to start the CLR to read & execute the rest of the file.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Ok; but since an application that draws windows can use the console, and since an application that uses the console can also draw windows, I do not see the point of that.

    It mainly just controls whether or not you get a console for free[1], or have to create your own.

    [1] by way of choosing a particular entry point from the set of available ones.



  • @boomzilla said:

    I read it as him saying he didn't want his code to have any knowledge of that

    You are not the only one who did that.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.