Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Nov 2005
Offline Last Active Aug 22 2016 01:50 PM

#5276886 VS2015 without internet explorer

Posted by on 19 February 2016 - 06:56 AM

I have no need nor intention to "bite the bullet" or whatever. The original problem has been solved as noted in previous post:



However, an update to the question i raised that was not answered:


Reinstalling IE nuked some of the settings needed for Classic Explorer to work (allow third party extensions got unchecked) - so, i needed to get access to the so called "internet" options again. Previously the only way i knew to do that was though IE and had to temporarily install IE just for that. This time i had a bit more luck with searching (by the virtue of Classic Shell having a sensible help around that does not wander through unrelated programs like IE) ... so, ...


... that darn thing is accessible through Settings -> Control Panel -> Internet Options. (yep, sue me, but i did not think of looking around in control panel)


That and the settings mentioned in the linked post are all that is needed to make VS happy. No need to have IE around.

#5276280 VS2015 without internet explorer

Posted by on 18 February 2016 - 03:07 AM

Reporting back.


Installed IE11 and:

* cookies must be allowed.

* whitelisting (trusted sites) did not work (live.com, visualstudio.com, microsoft etc/etc) somewhy. Only thing i found was that at least VS2013 had a bug where the sign in process actually mistakenly checked javascript access against the "internet zone" even though all the sites were in "trusted sites" zone - maybe it has not been fixed with VS2015?

* setting internet zone to high security (basically disabling everything) and specifically allowing javascript (active scripting)

Uninstalled IE (+restart even though it did not ask for it, just to be sure) and its security settings remained intact.


Had no problems registering / signing in after that. Yay!


I'm guessing by uninstalling ie's front end you've removed the javascript engine. After all, javascript is a user side facility not a backend facility ...


The frontend does very little (UI platform etc?) ... AFAIK, anything related to rendering an actual webpage is not considered to be part of it (the whole renderer is a separate embeddable component that is made basically inseparable from rest of the OS).


Comments from more knowledgeable dudes'n'dudettes welcome.

#5276272 VS2015 without internet explorer

Posted by on 18 February 2016 - 01:11 AM


Suppose i get to register it somehow - will it keep working without internet explorer?


It does require an occasional re-checkin, so you might have issues.



:/ ... that would be a nuisance (especially if it really is as often as mentioned [1-2 months]). So, register-time temporary fix is a no-go ... whatever i do, it will have to always work.

IE has been gradually built into the OS with only the front end being made uninstallable (to get around the lawsuit while still maximizing interdependency). The constant crap avalanche IE presence caused via updates was why i got rid of it way beck when - now only the OS internal parts get updates.


Checked with Wireshark and the "sign in" makes some https traffic with distinctly MS related payloads/destinations to fly around - so, it seems to be able to use the built in part of IE just fine, but just lacks the rights to run Javascript as the message indicated.


I wonder if installing IE to add some whitelists and then immediately uninstalling IE will perma-fix the situation :/ Can i do that without installing IE? How?


Will try it out when i get the time and say how it goes.

#5255473 I'm sleepy and confused: __try, __except, /EHa, C2712 (unwinding)

Posted by on 04 October 2015 - 12:44 AM

No shit sherlock *massive-facepalm*. Why did you even write that? Was it not crystal clear that discussions (at least without a lot more details) in that direction is undesired waste of everyone's time?


As i wrote: "ATTEMPT surviving broken code /.../ something that is normally undesirable".


PS. Since you like to ASS-U-ME stuff about what is or is not sensible for me to do in my specific case: the code runs in kernel land and some in user land via callbacks - there is no way for the OS to survive or cleanup anything when the program is broken (the process cannot even be terminated because it is in essence part of the kernel at that point - so, you get kernel panic ... BSOD). However i can send a message and initiate a proper teardown and hope the corruption has not already wrecked the OS (the chances happen to be actually pretty good that the OS will remain unharmed [ie. all internal structures in valid state]). An approach that is highly desirable, in my case, while in development phase.


So, no, you could not be more wrong. Don't assume you know the necessary context and details of what i am doing to ignore my PS'note in OP. It is exceedingly unhelpful.

#5255396 I'm sleepy and confused: __try, __except, /EHa, C2712 (unwinding)

Posted by on 03 October 2015 - 01:40 PM

C++ exceptions are built on SEH. It will quite happily execute any C++ handlers along the way when unwinding.

Really, this is your misunderstanding.

I was stating a fact (it has been this way at least a decade). C++ exceptions are implemented using SEH functionality in VC++.

/EHa causes the compiler to emit code such that SEH exceptions are handled like C++ exception, meaning they'll be caught by catch(...). Plain and simple.

Superficially true. To be specific:
* SEH exception filter for catch(...) does not select only C++ exceptions anymore (which it normally would).
* Optimizer can not rely on throws anymore and needs to emit all the unwind code it normally would omit.

An SEH will not otherwise cause destructors to get invoked during unwinding, because the SEH mechanism knows nothing aout the C++ runtime model.

That is messed up. SEH does not need to know anything about the unwind payload - C++ exceptions or otherwise.

SEH are not C++ exceptions, unless you use /EHa.

This is completely backwards.

Only C++ exceptions invoke C++ destructors.


You need to use try/catch (and not __try/__except) to use C++ exceptions.

Incorrect in principle. C++ exception catching is done via SEH exception records where C++ exceptions have the exception code 0xe06d7363. You are free to handle C++ exceptions in your __except - which, granted, is quite silly.

I suspect the compiler is just trying to save you from the consequences of your misunderstanding.

Incorrect. Compiler just can not do object unwinding in a function scope that also has __try ... which overloaded my sleepy brain - i just was not aware of that limitation (have Googled around since then and it is a well known limitation, but like i said - could not pinpoint any specific reason for it).

PS. You are well advised to assume i am not totally talking out of my ass. Example code:
struct Test {
    Test() { out << L"new Test"; }
    ~Test() { out << L"del Test"; }
    void panic() {
        throw 42;

void snafu() {
    out << L"shit's gonna hit the fan ...";
    Test obj;

    out << L"exception code: " << std::hex << e->ExceptionRecord->ExceptionCode;
    // second parameter in c++ exceptions is a pointer to thrown object (plain int in this case)
    out << L"C++ exception payload object: " << std::dec << *(int*)e->ExceptionRecord->ExceptionInformation[1];
    // yeah, we will take anything - including the C++ exception.

void test() {
    __try {
    } __except(filter(GetExceptionInformation())) {
        out << L"panic averted";
Output (compiled with the default /EHsc option) as one would expect:
shit's gonna hit the fan ...
new Test
exception code: e06d7363
C++ exception payload object: 42
del Test
panic averted

#5255302 I'm sleepy and confused: __try, __except, /EHa, C2712 (unwinding)

Posted by on 03 October 2015 - 12:35 AM

Erm, you are confused or not expressing yourself clearly enough for me.


C++ exceptions are built on SEH. It will quite happily execute any C++ handlers along the way when unwinding. So, of course all the destructors etc will be called - as long as compiler did add them to the unwind stack to begin with. VC++ compiler is free to optimize out adding thous when it sees that there can not be any exceptions (default compile options). To do that it only considers explicit exceptions (throw) by default. That is where "/EHa"  comes in - it disallows such optimizations and hence the entries will be there for even non-explicit exceptions (integer division by zero, access violation, etc).


My findings, based on and sanity-confirmed in practice:




My problem was caused by using "__try" in function scope that needs to unwind objects - which it cannot compile for some unknown reason i was not able to precisely pin down (might be some limitation of the function level handler that "__try" installs - ie. it can not add/remove unwind entries on the fly as functions with "try" can or more likely, the compiler is just not programmed to do so).


Which makes the solution obvious - move "__try" to a function scope that does not have objects to unwind. Unfortunately, in my case that would wreck readability - so, have to use "try catch(...)".


Examples for the benefit of passers by:

struct Test() {
    Test() { out << L"new Test"; }
    ~Test() { out << L"del Test"; }
    void crash() { out << *(int*)(0); }
void func() {
    Test foo; // Perfectly fine to unwind this object (Needs /EHa of couse as otherwise the code needed for unwind would be optimized out as "foo.crash" has no explicit "throw")
void test() {
    // Test notOkay; // Cannot compile this. Function uses __try and needs object unwinding.
    __try {
        out << L"crashed";

#5195472 Best comment ever

Posted by on 30 November 2014 - 07:11 AM

... O_o ... are the commit comments supposed to be funny?

#5194599 real time reflections from arbitory surfaces.

Posted by on 25 November 2014 - 08:21 AM

"this video is private" and the post has no content anyway as pointed out previously.

#5191210 Thread-post never made ... almost

Posted by on 04 November 2014 - 04:22 PM

I have a rubber duck at my desk for this exact reason. If I'm stuck, I explain the problem to the duck and half the time figure out the solution in the process.

Hehe, sweet. biggrin.png ... also, pics or didn't happen tongue.png

Either do:

void skipX(char const* const& at)
void skipX(char*& at)
However, I advise you not to take a reference to a pointer because that's one extra memory read you'll be doing (i.e. it's slower). It's always faster to copy raw types than reference them.
void skipX(char* at)

Erm, ...
* the first one will cause a syntax error given the function body.
* the second: the first step in fixing const-correctness is not to just abandon it all.
* the example code was marked with: "silly-made-up-simplified-mini-example" ... it is obviously meant to expose a language quirk and not to micro optimize a nonsense algorithm.
* any compiler worth anything will inline that silly snippet -> hence there wont be any redirections and nothing to optimize.
* obviously, my real case uses pass by reference because it needs to affect the variable used in function parameter.
* no-one cares about micro optimizations without a bloody good reason.
* oh, and the third one changes what the function does - likely emitting an warning that something got fucked up.


#5191157 Thread-post never made ... almost

Posted by on 04 November 2014 - 12:12 PM

An observation of the self-reflection kind: the vast majority of problem-threads i start to write - i never actually post. It goes like this:
* problem
* need to explain the problem
* need to understand the problem to explain it
* ...
* never mind

Oh, well. Since the problem i had was a simple one (the facepalm moment arrived in the middle of writing the very first sentence for me) - i post it anyway for readers benefit as i have encountered variations of this problem fairly often.

Why cannot "Foo *" be implicitly converted to "Foo const *&"?

void skipX(char const *&at) {
    if(*at == 'X') at++;
void snafu() {
    char *buf = ...
    skipX(buf); // not OK! -> 'Conversion loses qualifiers' !
Noticed the problem? Did you think about it? Did thinking about it help? tongue.png

Oh, well - my take on the pesky WHY:

Foo const constFoo;
Foo *ptrFoo;
Foo const **snafu = &ptrFoo; // *** ie. if it WOULD allow this then the following can legally happen ***
*snafu = &constFoo; // exact type match: both sides are "Foo const *"
*ptrFoo = @#$%! // completely valid to do whatever with the Foo ... ow, crap - it just happens to be constFoo.
Aliasing issue, lovely. Compiler errs on the side of caution (validity of the code is the goal, not some version of const correctness in and of itself ... but that is a rant for another time deep in the complicated waters of language design not relevant to C++ with its constraints of history).

... and this kind of mind-wrappers are why one generally tries to avoid low level C++.

C++, the sledgehammer of const correctness.

So, what C++ thread did you not make lately?

#5184546 Multithreading issues: Unit test fails sometimes

Posted by on 02 October 2014 - 06:13 AM

It doesn't explain why the X component of Position is screwed while the Y component is always fine.

I have no experience with boost - so, not sure i understand what it is expected to do here.

Anyway, if at any time multiple threads can work at the same data then what you are experiencing is exactly what one would expect.

In other words: "It doesn't explain why the X component of Position is screwed while the Y component is always fine." - No, that (unguarded overlapping data usage) explains it perfectly.

PS. testing MT parts of code only counts for the "basic-sanity-check" case - they are fundamentally utterly useless to check the actual validity of it beyond that.

Take a paper and pencil and revalidate your MT logic (in the end, that is the only way to write MT code) - you have a race condition (assuming you are proficient in MT land - then read relevant boost documentation to find where your assumptions clash with what it says).

#5183727 Funniest line of code ever ?

Posted by on 29 September 2014 - 07:32 AM

Personal favorite of mine (from the first version of my 2D engine back in 2009) 

	runRight  = new ANIM();
	runLeft   = new ANIM();
	runBack   = new ANIM();
	runFront  = new ANIM();
	idleRight = new ANIM();
	idleLeft  = new ANIM();
	idleBack  = new ANIM();//those of you with OCD will HATE me for these lines...
	idleFront = new ANIM();//if you don't have OCD, you have no idea what I'm talking about.

Fixed for you.

#5177207 decltype(vector<Type>) doesn't compile

Posted by on 31 August 2014 - 08:22 AM


Completely OT, but what does that emote mean? Never seen it before and it is rather difficult to Google for it x_x.

copy/pasting it is not so easy because my VS is in german

Yeah noticed. My grasp of German is still fairly good, besides - the gibberish part between the fairly standard text is where the problem is actually shown.

Btw, OT again, why do you use German for VS? English is not my native language either, but i still strongly prefer all my tools to be in English - easier to Google stuff etc (ie. the knowledge pool in English is a far greater benefit than the un-noteworthy benefit of having some tools in ones native language).

edit: Oh, yeah "template<typename Type> typename Test<Type>::NewType get(void) { ... }" - forgot the second "typename" there. Oh C++, you so silly.

#5177182 decltype(vector<Type>) doesn't compile

Posted by on 31 August 2014 - 05:44 AM

decltype is very fragile with VS ... not that your problem has anything to do with it, just mentioning to be cautious in relying on it.

Anyway, what you seem to want is:
std::conditional<std::is_pod<SomeType>::value, SomeType, SomeType*>::type
also, might want to typedef it if it is needed often for readability:
typedef typename std::conditional<std::is_pod<SomeType>::value, SomeType, SomeType*>::type NewType;
edit: "typename" is of course not needed if SomeType is not template parameter - kind of wrote it on autopilot.

#5172569 Funniest line of code ever ?

Posted by on 10 August 2014 - 02:38 AM

I actually used to run into old DOS game installers that would crash on "more modern" computers (like a Pentium) because they tried to figure out your processor speed by running a while loop for X amount of time and counting how many iterations happened.

Borland Pascals runtime library used to do that - which meant that all the programs crashed on CRT initialization regardless of anyone actually using the feature the loop-timer was there for.