-
March 28th, 2012, 07:18 AM
#1
Subsystem:Windows
When I'm building a Windows GUI app I usually set the exe's linker option /SUBSYSTEM:WINDOWS. If it's a console app I set /SUBSYSTEM:CONSOLE. So far, so good. BUT...
When I build a DLL (i.e. code only - no GUI) I usually just make sure it isn't set to SUBSYTEM:CONSOLE. Sometimes it can be /SUBSYSTEM:WINDOWS. Other times it can be Not set. I've never found it makes any difference - until today....
I've spent the whole morning chasing a weird problem where _close() was occasionally failing in Debug mode. The line that failed is in red:-
Code:
int __cdecl _close (
int fh
)
{
int r; /* return value */
/* validate file handle */
_CHECK_FH_CLEAR_OSSERR_RETURN( fh, EBADF, -1 );
_VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, -1);
_VALIDATE_CLEAR_OSSERR_RETURN((_osfile(fh) & FOPEN), EBADF, -1);
_lock_fh(fh); /* lock file */
__try {
if ( _osfile(fh) & FOPEN )
r = _close_nolock(fh);
else {
errno = EBADF;
r = -1;
_ASSERTE(("Invalid file descriptor. File possibly closed by a different thread",0));
}
}
__finally {
_unlock_fh(fh); /* unlock the file */
}
return r;
}
Basically, the file to be closed was deemed be not open (FOPEN flag not set). I could literally open a file and close it straight away and it would fail. I could step through _open() and validate that the flag was getting correctly set - but by the time I got to _close() it was corrupted.
Eventually I found that one of my VC solutions had about 10 projects which all built DLLs. All were set to /SUBSYSTEM:CONSOLE except for one, which was set to Not set. Setting it the same as all the others seems to have fixed the problem
I loathe bugs like this because I don't understand them. Does this make sense to anyone here?
Last edited by John E; March 28th, 2012 at 09:01 AM.
Reason: Incorrect option, pointed out by Vladimir (see below)
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
March 28th, 2012, 08:50 AM
#2
Re: Subsystem:Windows
Originally Posted by John E
...Does this make sense to anyone here?
No, not really. What is "/SUBSYSTEM:NONE" ?
I can't find this option in MSDN, and it is not listed in my VS 2010.
When I just type it in, I get an error:
LINK : fatal error LNK1117: syntax error in option 'SUBSYSTEM:NONE'
Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
Convenience and productivity tools for Microsoft Visual Studio:
FeinWindows - replacement windows manager for Visual Studio, and more...
-
March 28th, 2012, 08:57 AM
#3
Re: Subsystem:Windows
Originally Posted by VladimirF
No, not really. What is "/SUBSYSTEM:NONE" ?
I can't find this option in MSDN, and it is not listed in my VS 2010.
When I just type it in, I get an error:
Oops, I beg your pardon...
The actual selection was "Not set". I don't know where I got the idea about /SUBSYSTEM:NONE.
I'll re-edit my post because that's bound to confuse everyone else, too !
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
March 28th, 2012, 03:06 PM
#4
Re: Subsystem:Windows
That just means "Figure it out for me depending on the entry point(s) which is present". From the docs:
CONSOLE
Win32 character-mode application. Console applications are given a console by the operating system. If main or wmain is defined, CONSOLE is the default.
WINDOWS
Application does not require a console, probably because it creates its own windows for interaction with the user. If WinMain or wWinMain is defined, WINDOWS is the default.
So, the default for a DLL should be SubSystem:Windows.
If you liked my post go ahead and give me an upvote so that my epee.... ahem, reputation will grow.
Yes; I have a blog too - http://the-angry-gorilla.com/
-
March 28th, 2012, 03:34 PM
#5
Re: Subsystem:Windows
Interesting... I wonder what happens in the case of a static lib (which could be used with either a console app or a GUI app)? Maybe that's what the "Not Set" option is for.
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
March 28th, 2012, 03:50 PM
#6
Re: Subsystem:Windows
I guess that in that case it doesn't matter. Libs can be used for both targets
-
March 28th, 2012, 06:05 PM
#7
Re: Subsystem:Windows
I wonder what happens in the case of a static lib
Subsystem is a linker option. Static lib is built by librarian. No relation to lib.
Best regards,
Igor
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|