Jump to content

  • Log In with Google      Sign In   
  • Create Account

tanzanite7

Member Since 20 Nov 2005
Offline Last Active Apr 28 2016 11:00 AM

Posts I've Made

In Topic: VS2015 without internet explorer

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:

http://www.gamedev.net/topic/675576-vs2015-without-internet-explorer/?view=findpost&p=5276280

 

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.


In Topic: VS2015 without internet explorer

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.


In Topic: VS2015 without internet explorer

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.


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

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.


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

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.

Incorrect.
 

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;
    obj.panic();
}

int filter(LPEXCEPTION_POINTERS e) {
    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.
    return EXCEPTION_EXECUTE_HANDLER;
}

void test() {
    __try {
        snafu();
    } __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
Cheers.

PARTNERS