Sandboxie Support

Win class performance, cause (NEW), and a test for all

2013-08-28T02:38:59-04:00

I don't have any specific examples, but it should be anything that calls SetWindowsHookEx to place a global hook (in contrast to a hook on a specific thread).

Statistics: Posted by tzuk — Wed Aug 28, 2013 2:38 am

Win class performance, cause (NEW), and a test for all

2013-08-27T08:54:42-04:00

OK, thanks for debunking my theory that it was related to drag-and-drop...

But that makes me more curious and confused! Regarding that extra stuff assisting implementing Win32 hooks, etc. (yeah, I know you said that a few times, but didn't understand), can you point out something I should see that "breaks" when that hook emulation stuff doesn't happen...?

Statistics: Posted by DR_LaRRY_PEpPeR — Tue Aug 27, 2013 8:54 am

Win class performance, cause (NEW), and a test for all

2013-08-25T04:35:01-04:00

As I said a few times, without going into detail, that extra stuff assists in implementing Win32 hooks. Drag and drop is a different thing and not related.

Statistics: Posted by tzuk — Sun Aug 25, 2013 4:35 am

Win class performance, cause (NEW), and a test for all

2013-08-23T13:45:16-04:00

Again, I'm not trying to USE it, don't worry.

All I'm hoping to do is understand (even for 3.76, whatever) and confirm about all that "extra stuff" I/we talked about that happens otherwise during window creation -- you said it can't be removed, emulates other APIs, etc. and such...

Quite simply, as I've said, I came to the logical conclusion that "extra stuff" (repeated notification messages, etc.) must be to support drag-and-drop, as that's the only functionality that obviously breaks without the "extra stuff." My thought: What else could it be for? Everything else works fine without "extra stuff."

So obviously I'm trying to "get" (or confirm) its purpose, with default settings (e.g. normal configs, NOT about OpenWinClass=#).

Statistics: Posted by DR_LaRRY_PEpPeR — Fri Aug 23, 2013 1:45 pm

Win class performance, cause (NEW), and a test for all

2013-08-22T03:51:35-04:00

I guess you can say it's a deprecated feature. Again I recommend that you don't use it because sooner or later you will run into stuff that doesn't work, and that I am not going to fix.

Statistics: Posted by tzuk — Thu Aug 22, 2013 3:51 am

Win class performance, cause (NEW), and a test for all

2013-08-21T10:00:02-04:00

I haven't tried to use it since testing (it's a setting I forget about), although I would if drag-and-drop worked (no, I don't expect it to ) since everything seems fine with nearly NO speed loss. (I don't care about class prefixing anyway.) It was just the small bug when using it where Recent Documents no longer works -- OpenWinClass=Progman or $:explorer.exe doesn't work then, though other OpenWinClass stuff is OK.

Otherwise it works as in 3.76 AFAICT, and according to the OpenWinClass page. The setting IS still used in the StrokeIt Template, and I just wanted to report it, even though it's not affecting me now. Unless of course it's going to be deprecated/removed...

No, after your comment, I was [again] just trying to understand what's happening with or without #? v4 behaves the same as 3.76, and you only mentioned the class prefixing difference (not a factor). So: IS all that "extra stuff" when windows are created JUST to support drag-and-drop?? That's all I was trying to figure out since it's the only difference I notice with any version.

Statistics: Posted by DR_LaRRY_PEpPeR — Wed Aug 21, 2013 10:00 am

Win class performance, cause (NEW), and a test for all

2013-08-21T04:04:52-04:00

I'm glad you like version 4.05.06. I see you're asking about OpenWinClass=#. In my earlier post, I said, or maybe just implied, that OpenWinClass=# has not been fixed and tested for version 4. I don't think you should use it.

Statistics: Posted by tzuk — Wed Aug 21, 2013 4:04 am

Win class performance, cause (NEW), and a test for all

2013-08-20T12:06:49-04:00

Another reply, but don't be alarmed! Everything is still going fine. Yeah OK, what you said makes sense and would explain why I wasn't seeing much change in GUI Bench. Thanks again for your patience with my "Yeah but, this," "Yeah but, that."

Just wanted to give another positive comparison/comment -- comparing with 3.76. Other than the additional launch delay with the restricted Job (of course can't be improved without eliminating any other SbieSvc/GuiProxy calls (hope no unnecessary ones still!), or some general optimization of the system, etc.), and that other MFC-related (presumably) slowdown, what I have talked about HERE/previously NOW feels like it runs as nice as 3.76! e.g. The slight additional time on IE window opening and stuff isn't something I can notice during real, practical usage. That's in the "worst" case -- after your latest changes, performance degrades LESS than 3.76, so 4.05.05+ shines more as additional stuff is open.

I didn't see that part about OpenWinClass=# last week...? Anyway, forgot to say before, I think I found a small bug when testing it -- post here or new topic?

What you said about working "well" -- performance wise, like I said, it's the best! And doesn't really degrade with many more windows. With default settings now, things initially perform as well as Open=#

You say it "should just not put the Sandbox: prefix on window class names," but it ALSO does NOT do all that "other stuff" I was asking about. Sounds much different than your basic description of the difference? (I don't expect to see any speed hit from class name prefixing, so no issue there.)

The only thing I can see OpenWinClass=# changes otherwise is drag-and-drop support doesn't work. That's why I asked: 1) Can't you "just add back" class prefixing and drag-and-drop support; or 2) All that "other stuff" is somehow related to drag-and-drop support?

As I said, with # CreateWindow itself is basically like UNsandboxed. FYI, PowerArchiver Configuration in my usual active sandbox took just over 3s before any changes; then just over 2; and now 1.5s. With OpenWinClass=# it's about a half-second, like UNsandboxed...

Statistics: Posted by DR_LaRRY_PEpPeR — Tue Aug 20, 2013 12:06 pm

Win class performance, cause (NEW), and a test for all

2013-08-14T14:53:58-04:00

Thanks for checking. I'm glad you're happy with the results and I hope we can put this subject to rest. For now if not for good.

As for what I did, it's very simple, given specfic scenarios, I looked for calls to SbieSvc and where it made sense and the change was trivial,
I got rid of those calls. As for CreateWindow, there was that lengthy part at the end that you identified. For a hierarcy of CreateWindow calls (e.g. when the parent window is creating its child windows while responding to WM_CREATE), there is no need to do the lenghty part every time, it's enough to do that at the top level. So your GUI Bench does not show a difference, while some practical scenarios do.

I don't know about OpenWinClass=#. It should just not put the Sandbox: prefix on window class names and that saves hooking a few APIs related to window class names. I've not spent much time to make sure it works well in v4.

Alright, let's conclude this one. Thank you DR_LaRRY_PEpPeR and pastuch for keeping at this thing, sorry I was impatient at times, I hope all's well that ends well.

Statistics: Posted by tzuk — Wed Aug 14, 2013 2:53 pm

Win class performance, cause (NEW), and a test for all

2013-08-14T12:00:51-04:00

Interesting to hear pastuch, but cool.

Sorry I didn't report my feedback sooner -- I was evaluating over 24 hours ago, and didn't have time to reply then...

Well tzuk, THESE changes are pretty remarkable! Another: Wow! Obviously a HUGE THANK YOU for sticking with it, finding stuff to tweak, and also your patience with me, haha.

Amazed that you were able to pull this off in, what, a couple hours the other day after I gave the Work Offline example! It's really puzzling WHAT exactly you changed: I don't see much improvement with my synthetic GUI Bench Create time (but doesn't matter if it doesn't reflect what I'm seeing/feeling ), a minor-to-moderate IE window opening slowdown (OK/expected) with more windows open, but YET, not much slowdown with IE launch times even with MANY windows open. Just reporting how each thing changed differently (strange), not a problem.

FYI: NOW, stuff starts out just about as fast as OpenWinClass=# (I can't really see a difference at all). Of course the small degradation (much less than before) doesn't keep things as fast as Open=# that I was asking about.

On main XP system, all with my "usual active" stuff open: IE launch before ANY changes (4.05.03) was ~1s, first change dropped to 0.88 (these would both degrade remember), and now it's down to 0.7. Even adding 20+ IE windows to what's already open, it only increases to 0.76-0.8. The launch improvement FEELS better than the times, it seems.

I have to add 20-24 IE windows before the "window opening" slows down to what it was in 4.05.04. Even with 30 more open (couldn't open any more!), it's only a hair slower than what it was without the 30 extra in 4.05.04.

With 20 extra open (I'd never have anything like that), there's about a 5s Work Offline delay now (instead of 16, probably 2-3 if UNsandboxed), but otherwise new windows opening, etc. feels pretty good and about what I'd expect.

Same on laptop: Have to open 10 IE windows to see IE "window opening" time like 1 window with 4.05.04. 20 windows to see time like 4.05.03.

32-bit IE 8 on 64-bit Win 7 looks like the same pattern. Hadn't checked it much lately, and the absolute times don't vary as much with nothing on the system or running, but the relative improvements look expected.

A question about the 0.2s+ difference I see between OpenWinClass of * and # (and defaults now, initially) when launching IE or Firefox, or IE window opening. Obviously the Job adds some access overhead we talked about IN sandbox (250k+ accesses for 0.2s), and more for GuiProxy when needed. Like I said after 4.05.04, I [still] see a CPU spike in both SbieSvc processes. Normal?

Did you check to make SURE there's not other operations still unnecessarily going through GuiProxy like e.g. CreateWindow calls before?? Just so we aren't accidentally losing some easy time there.

Statistics: Posted by DR_LaRRY_PEpPeR — Wed Aug 14, 2013 12:00 pm

Win class performance, cause (NEW), and a test for all

2013-08-13T16:29:49-04:00

Great! I tweaked a couple of things and I wasn't sure what effect that would have so I'm glad to see you notice a real improvement.

Statistics: Posted by tzuk — Tue Aug 13, 2013 4:29 pm

Win class performance, cause (NEW), and a test for all

2013-08-13T10:20:05-04:00

tzuk wrote:Please try version 4.05.05.

My first impressions during 5 min. test: wow! The Opera works a lot faster now
tzuk, thank you very much for the fix.

Statistics: Posted by Guest — Tue Aug 13, 2013 10:20 am

Win class performance, cause (NEW), and a test for all

2013-08-13T03:20:04-04:00

Please try version 4.05.05.

Statistics: Posted by tzuk — Tue Aug 13, 2013 3:20 am

Win class performance, cause (NEW), and a test for all

2013-08-13T02:08:36-04:00

barny: No, I don't have that, although I did just recently find the topic you're referring to from Google (and good to know ). Although I do have a FAT32 partition on 2 systems for storing my old version of Ghost's image files, but nothing else should be touching that (only a few files anyway).

pastuch: Yeah, like tzuk said, none of this CreateWindow slowdown I've identified is going to affect things that aren't calling CreateWindow, which e.g. scrolling in Opera wouldn't do. Maybe it's like the extreme lag I see in API Monitor, which is caused by something else.

tzuk: Yeah, that's what I meant. Interesting to see your changes... I had been saying toggling Work Offline makes 30 CreateWindow calls, but I now see it's actually 30 PER IE window. So of course that explains why Work Offline slows down much more than e.g. single window opening...

After my post I thought of another OpenWinClass setting I hardly ever think of -- forget about OpenWinClass=* in 4.02 that I've been referencing. Probably not a huge deal or much different (if what I'm asking about is wrong), but you know what performs the same as 4.02's Open=*? OpenWinClass=#

Using Open=# the Work Offline delay with 20 IE windows drops from 5 seconds to under 1 second. Also with 4.05.04: Default settings, IE window opening is 0.28s with 1 window (again, stuff is a lot faster on laptop) and 0.55 with 20 windows. With Open=#, it's 0.25 (exactly what I estimated) and 0.26-0.27 with 20 windows (so basically the same).

So yeah, Open=# performs and scales wonderfully! It also skips all that "other stuff." (Again, CreateWindow itself is basically like UNsandboxed.)

The page about OpenWinClass=# says it doesn't "alter" (prefix) class names and "may interfere with some drag-and-drop operations." You really can't make things operate/perform like Open=# and just add back class prefixing and drag-and-drop support??

Of course prefixing is not an issue and should be a very, very fast operation.

In other words, are you saying that all that extra stuff per sandboxed window is somehow related to drag-and-drop support?? What else doesn't happen/work with Open=#? Which emulation of Win32 hooks?

Obviously I understand if something happens with CreateWindow for the window object being created to support whatever (which shouldn't even be noticeable, so OK). But I don't get why messages to other window handles (but only "top-level" ones, not their children it seems) and repeated identical _wcsicmp/NtDeviceIoControlFile calls...

Statistics: Posted by DR_LaRRY_PEpPeR — Tue Aug 13, 2013 2:08 am

Win class performance, cause (NEW), and a test for all

2013-08-12T13:28:18-04:00

tzuk wrote:pastuch, I played a bit with Opera 12.16 x64 with probably around 150 tabs. I was loading tabs in groups of about 25 new tabs every time. I was seeing minor impact on scrolling speed while new tabs were loading, but it got fast again when the load finished. Please note that I just installed Opera and started loading tabs. Did not do any configuration, addons or anything else to Opera. Do you also have such a "clean" installation?

In the virtual machine I installed only: the system, all updates, VMware Tools, Opera with default configuration. In the Opera are only two changes - "Show Bookmarks Bar" and the default pages zoom 200%. Then I open the 100-tabs session like that https://hotfile.com/dl/239200260/b15b1b ... n.win.html . When the Opera is sandboxed in SBIE4.04 the slowdown occurs. All ok when added OpenWinClass=* or with SBIE3.76
My new observation that may be relevant: the degree of scroll-slowdown depends on how I start the scroll - if I use keyboard (arrow up/down, pgup/pgdn) or mouse scroll-whell then slowdown is high but when I use a middle mouse button+mouse move or scrollbar with mouse then the slowdown is not big.

Statistics: Posted by Guest — Mon Aug 12, 2013 1:28 pm