Advantages of microsoft visual studios

[phantomotap]

Do you need to interface with a COM, COMPlus, DCOM, OLE, ActiveX, ".Net", C++ object constructed using Microsoft's tools including their compilers, linkers, assemblies, or automation tools? This includes "DirectX", some native "Windows 7" components, and a lot of driver level components created by third-parties.

If the answer is "Yes"; you will have problems. It is only a matter of time. The above objects as constructed by Microsoft's tools use extensions designed precisely to hamper interoperability. Unfortunately, if the answer is "Yes" you will have problems with any compiler that hasn't been blessed by Microsoft with compatibility support or the tremendous effort by some community. In other words, you get to use "Embarcadero" and to a lesser extent "Intel". "LLVM", "Pelles", "GCC", and "LCC", I could name others, will all have problems with one or more of the above references objects.

If the answer is "No". Enjoy pretty much any compiler you chose, but at least pick one with strong, modern support for and conformance to the standards.

Soma

[Mario F.]

So when would using the GCC compiler become an issue with windows programs? Just for simple windows interfaces, or are we talking about full blown windows apps.

Never. Using GCC will, to my knowledge at least, never become an issue when developing for windows. However there are those (me included) who think there's much better out there when there's a clear indication one is willing to spend money, as was the case on the OP. GCC cannot compete in final binary performance and size, and its debugger is no match for the MSVC solution. This conclusion I didn't reach lightly.

After around 2 years of GCC use and in a time I needed to make a serious decision on which compiler to use, I did extensive testing with both trying to draw comparisons from comparable build settings. Speedwise, the differences are not so significant (and I hear there's been improvements to GCC handling of exceptions too, one of the most notable performance issues with this compiler). But code size is very significant. Especially when you tend to statically link and would like some sort of sane binary size. But there's also MSVC debugger that is simply on a completely different level from GDB. There's people in these forums who can attest (if their memory serves them right) to my love for GDB. So this isn't your typical fanboy trash talk. But I don't tend to blindly follow anything or anyone. And just because I actually like GDB command line debugger, MSVC debugger is simply ona completely different race. Together, with the addition of a quite formidable development suit, for someone that says they are willing to spend money, I think it's completely insane to stick with Eclipse and (I have to guess) MinGW if they plan to develop for windows.

[phantomotap]

I wish I could spend more time with the debugger. ;_;

Soma

[Elysia]

No such thing as a rant. Just said you typically don't need them, which just adds up to: it's probably not worth it to buy VS for the sake of resources.

[CommonTater]

No such thing as a rant. Just said you typically don't need them, which just adds up to: it's probably not worth it to buy VS for the sake of resources.

Typically don't need resources... ok, so how do you make a dialog box? How do you set up the keyboard? How do you design a menu?

Really, Elysia... whether it's hidden from you by your silly libraries or not... believe me it's there.

Grab a copy of Resource Hacker... it's free... and use it to view the resource section of your own code... I'm thinking you're in for something of a surprise.

[Elysia]

That is not the point. Yes, libraries may use resources. Yes, they are using the Windows API. But that is irrelevant.
What is relevant is that you don't have to do it. That is all that matters. Think nothing else.

[CommonTater]

That is not the point. Yes, libraries may use resources. Yes, they are using the Windows API. But that is irrelevant.
What is relevant is that you don't have to do it. That is all that matters. Think nothing else.

No Elysia... what matters is that I WANT to do it and I don't appreciate being told not to.

I LIKE getting down and dirty with the machine. I used to do chip level service on motherboards, component level service in audio, television and radio systems. I made a career of climbing right inside the technology and knowing how it works.

[Elysia]

*shrug*
You may do what you want. That wasn't relevant to my reply.
The point was that while underlying technology may use resources and Win API, you don't have to, because it does it for you.
So if you're willing to use those tools that abstract these things for you, you don't need to get all dirty with it.
Unless you like doing if, of course.

[phantomotap]

O_o

*writes JSON parser*

*crafts dialog from JSON object*

*opens binary in "Portable Executable" exploder while dialog is shown*

Nope. There is no dialog in the resource section of the executable.

With the exception of shell related "PE" tags, like the version information visible in the version tab of the file properties window, the custom icon displayed by most file browsers, and some versions of the digital signature engine, you do not need to use or even know about "Windows" resource files to use dialogs, string tables, accelerators, menu, icon, paintbrushes, cursors, and a lot else besides. The "Windows" API isn't doing some magic executable mutation behind the scenes; the API, executable loader, and shell handler all just look at the resource table that is part of the "PE" format and translates that information into a sequence of system calls at runtime.

Soma

[CommonTater]

the API, executable loader, and shell handler all just look at the resource table that is part of the "PE" format and translates that information into a sequence of system calls at runtime.
Soma

Totally clueless... here's a simple .rc resource script... typical of those used by C and C++ when building executables...

#include <windows.h>
#include <commctrl.h>
#include <richedit.h>

LANGUAGE LANG_ENGLISH,SUBLANG_ENGLISH_US

APPICON ICON "RMRemote.ico"

SMALLBTN1 BITMAP "SmallButtons1.bmp"

SMALLBTN2 BITMAP "SmallButtons2.bmp"

BIGBTN1 BITMAP "BigButtons1.bmp"

BIGBTN2 BITMAP "BigButtons2.bmp"

1 MANIFEST "Manifest.xml"

ABOUT DIALOGEX DISCARDABLE 6, 18, 196, 102
STYLE DS_SHELLFONT|WS_POPUP|DS_MODALFRAME|DS_3DLOOK|WS_CAPTION|WS_VISIBLE
EXSTYLE WS_EX_NOPARENTNOTIFY
CAPTION "About RMRemote"
FONT 8, "MS Shell Dlg", 0, 0, 1
{
  CONTROL "OK", IDOK, "Button", WS_TABSTOP, 139, 81, 45, 15
  CONTROL 8001, 4001, "Static", SS_BITMAP|SS_REALSIZECONTROL|WS_BORDER, 79, 4, 106, 27
  CONTROL "RMRemote ver 0.7.1\r\nCopright 2008 - 2011\r\nBy LD Blake\r\nAll rights reserved\r\n", 4002, "Static", WS_GROUP, 5, 3, 73, 33
  CONTROL "RMRemote is part of the Remote Media system.  Remote Media allows you to remotely launch your favorite multimedia player and then have remote control over playback of files.\r\n ", 4003, "Static", WS_GROUP, 5, 40, 180, 37
}

8001 BITMAP "logo.bmp"

HOTKEYS ACCELERATORS
{
  80, 1000, VIRTKEY
  VK_SPACE, 1001, VIRTKEY
  83, 1002, VIRTKEY
  VK_PRIOR, 1003, VIRTKEY
  VK_NEXT, 1004, VIRTKEY
  VK_LEFT, 1005, VIRTKEY
  VK_RIGHT, 1006, VIRTKEY
  VK_UP, 1007, VIRTKEY
  VK_DOWN, 1008, VIRTKEY
  49, 1009, VIRTKEY
  50, 1010, VIRTKEY
  51, 1011, VIRTKEY
  52, 1012, VIRTKEY
  VK_RETURN, 1013, VIRTKEY
  84, 1014, VIRTKEY
  88, 1015, VIRTKEY
}

VS_VERSION_INFO VERSIONINFO
FILEVERSION 0,7,1,0
PRODUCTVERSION 1,0,0,0
FILEFLAGSMASK 0x3F
FILEFLAGS 0x0
FILEOS VOS__WINDOWS32
FILETYPE VFT_APP
FILESUBTYPE VFT2_UNKNOWN
{
  BLOCK "StringFileInfo"
  {
    BLOCK "040904B0"
    {
      VALUE "Comments", "Client for Remote Media Server\0"
      VALUE "CompanyName", "LD Blake\0"
      VALUE "FileDescription", "Remote Media Remote Control\0"
      VALUE "FileVersion", "0.7.1.0\0"
      VALUE "InternalName", "RMRemote\0"
      VALUE "LegalCopyright", "2008 - 2011, LD Blake\0"
      VALUE "OriginalFilename", "RMRemote\0"
      VALUE "ProductName", "Remote Media\0"
      VALUE "ProductVersion", "1.0.0.0\0"
    }
  }
  BLOCK "VarFileInfo"
  {
    VALUE "Translation", 0x409, 0x4B0
  }
}

STRINGTABLE
{
  10001, "RMRemote uses command line input.\n Please use RMClient instead."
  10010, "Bad Server Name"
  10011, "Host Offline"
  10012, "Can\'t Wake Host"
  10013, "RMServer Offline"
  10014, "Contacting Server"
  10015, "Menu Update"
}

STRINGTABLE
{
  10016, "Server Error"
  10017, "Queued"
  10018, "No Network"
  10019, "No Remote"
  10020, "Finished"
  10021, "Server Timeout"
}

STRINGTABLE
{
  20000, "Program class registration failed"
  20001, "Unable to create main program window"
  20002, "Could not find a working network connection"
  20003, "Unable to secure exclusive use of a network port."
  20004, "Unable to load settings."
}

STRINGTABLE
{
  20020, "Remote Media requires Windows XP with service pack 2, or newer."
}

Do you see ANYTHING in there that translates to a system call?
No.
These are data ojects stored at the end of Windows PE files that are in fact called into use from OUR CODE... Get it... data stored as part of the program...

[cyberfish]

Although why there is no simple create_process in Linux is still beyond me...

Wouldn't something like this work?

void create_process(...)
{
     int pid = fork();
     if (pid == 0)
     {
          execv(...);
     }
}

[Elysia]

It would, but again, that is kind of the point I wanted to make. Why two calls for something as simple as creating a new process?
It seems like a waste. Not only does there have to be two traps to the kernel, but also a lot of work duplicating data (and sharing) that will later just be thrown away.

[Fordy]

It would, but again, that is kind of the point I wanted to make. Why two calls for something as simple as creating a new process?
It seems like a waste. Not only does there have to be two traps to the kernel, but also a lot of work duplicating data (and sharing) that will later just be thrown away.

IIRC fork calls in linux don't automatically lead to duplication of the address space thanks the COW scheme the system uses. There will be a duplication on a call to execv, but there shouldn't be any real extra overhead over the Win32 methods. Many large scale *nix programs use fork a lot to provide multitasking so I doubt there's any serious penalty involved with this method.



<edit> Oops...thread was closing as I typed, nevermind....</edit>

[Salem]

Since this thread has long since wandered from "compare IDE's" into "OS API flamewars", it's time to end it.
Besides, the 1-post OP hasn't bothered to return, so maybe it was just a waste of time anyway.