- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Admin
Further twiddle on the working set debate: the Windows NT line actually has three kinds of page fault: soft, hard, and invalid. Invalid page faults are easy, you touched a place in your address space where there isn't supposed to be a page, and these are probably what the article was referring to. Hard page faults aren't so difficult to understand - the page is not in physical memory, but is a real page, so the OS goes out to bring it in as soon as you touch it.
Soft page faults are interesting. The page is in physical memory, but isn't marked as present in your address space. Why might that be? Imagine: another program has caused a page-in event, and to make room, the OS decides to page out one of your writable (and written-to) pages. Because the page is "dirty" (modified since last load) it is queued for writing to disk, while being marked as "out" in your page table. While the page is in the queue (along with dozens of others, presumably), you touch it. A page fault happens, and the OS removes the page from the page-out queue, marks it as being present in your page table, and lets you proceed. Without the page fault, the OS would not be able to remove the page from the page-out queue.
There are also cases like an executable page in a DLL loaded by another process that you load. Sure, the OS could spend time copying in/out state from the other process to yours, but it could also do lazy loading and allow you to trigger soft faults against the pages that are used in both processes. Also, for various reasons, the DLL might need to be loaded in a different place in your process, and this will cause endless hilarity due to relocations being different in the two processes, but pages affected by that are arguably not soft-faultable. Whatever...
Admin
Admin
FTFY
Admin
This is not a joke. Askimet, you racist bastard.
Admin
2 spaces!!!
Will you people stop pissing horizontal space away!
Admin
Goodness, what the youth of today waste their time on! Inventing problems and over-engineering unnecessary solutions and even wasting time arguing about GOTO statements and page faults! You couldn't make it up.
Back in the day we would solve this sort of problem in 30 seconds by tasking one of our secretaries to clear out the network drives manually each morning, thus allowing us to continue with our more important COBOL development.
If you really need to clear the files as frequently as once every 60 seconds (!) as the script suggests then I suggest you are doing something wrong. You shouldn't be writing the files in the first place if you so urgently need to delete them.
Admin
It be interesting to know what happens to objFSO after every call to GetFolder() ... Does it allocate more space?
Admin
Here are some WTFs that haven't been mentioned:
What happens if I start two instances in different locations with two different Lemming.ini(s)? Shit is gonna get fucked up. Blame the shitty requirement(s?) if you want but first rule of programming, End Users Are Stupid.
Why isn't there any logging? Even as an internal application, it should at least log starting and terminating.
Why isn't the sleep duration part of the INI file? That's what they are for, ya know, initialization, configuration, settings. The precursor to XML config files.
Admin
VB6 (well, COM in general) is reference-counted. On each call to GetFolder(), the previous folder object is dereferenced and thus deallocated. I'm not sure what you think might happen to objFSO, but there's no obvious memory leak or anything here.
Admin
I see, thanks for correcting me. Actually, when I checked half a year ago, Microsoft web said it will not work on Windows 8, good to know they changed their mind.
Admin
Not quite. VB has On Error Resume Next, meaning it simply continues onto the next line - which is where you put your error handling. eg:
On Error Resume Next Open "file"...... If Err Then "MsgBox" FileNotFound etc...
Much neater than the old GoTo handler crap.
On Error Resume Next is a favourite a poor coders as you can use it to suppress all errors. Awesome, code that never fails!
As for the WTF, meh. Could have been a VBScript that executed once, kicked off by the scheduler every so often, but yeah, meh.
Admin
Go to hell. I retarded my carburettor yesterday, and shall continue to do so in the future.
Admin
I'm rusty, but I'm pretty sure that code wasn't written to run as a service. I suspect this is why he put that word in quotes. Proper services shut down in ways prescribed by the service shutdown code - this program has no terminate condition at all.
It's possible that he confused the term page fault with segmentation fault - someone mentioned earlier that VB is a managed environment and while that's true of later versions, I think VB6 was pre dotnet. I don't remember VB being particularly segfault-prone, but then I never used VB very much beyond writing a simple media player in VB4, enthusing at how quickly one could prototype code, and then going back to C++ because I needed the better lower-level access for the kind of code I wrote. I also tended to program defensively - I've always liked code that doesn't fail - so I've typically avoided API Terra Incognito. This code isn't doing that. Terminating it involves removing a file to which it expects access. We're not seeing the whole picture here, but this corner of it isn't very pretty.
Admin
That poor puppy ... shudder
Admin
Admin
strewth dude ... it's a bit tardy to be saying that in this forum
Admin
I think you meant to say you retarded your ignition timing.
Admin
Just looked at the Windows services running on my computer. About 10k per process, which is not unexpected given what a page fault is. Something tells me that people were just being judgemental and that someone needed an excuse. Instead of doing what they should have been doing (pointing out problems in the code) they probably just wasted his time with pointless nerdy anti-VB rants. The thing about programmers that has annoyed me the most is that so many seem to be religious zealots. Some don't want to talk to you for the text editor you use; others fight tooth and nail against the (sorely needed because of type safety issues) introduction of C++ in an existing C code base because they don't want ‘the OOP that will just complicate everything’ and still others rant against VB or Java when they have no experience with those themselves.
Admin
It has been many years since I have touched VB6 but page faults sounds familiar. One thing that I am sure about is that I remember VB stability not being the greatest, but nothing was stable on win9x.
Admin
This is what we're talking about: http://www.fixerror.net/wp-content/uploads/2009/04/kernel32-error2.png
Admin
They meant invalid page fault but as that's usually the only one you care about it gets shortened to page fault.
Admin
So their server was running 9x huh? And these people were complaining about VB6?
Admin
So to stop a loop where blnLoopEternal is False and is tested on being true, you create a state of FileNotFound...
Admin
[quote user="Tud"][quote user="Steve The CynicYou can't edit because you haven't registered.[/quote] . Yes. I know. . So what?[/quote]
In order to have edit rights they would need to identify you as the original poster. If you post anonymously, you cannot be identified as such.
By the way I have registered myself as Cbuttius, I just can't be butted to log in.
Admin
VB6 runs perfectly on Windows 8 (desktopversion, not on ARM, but any .NET application that is out there now won't run either on ARM). VB6 isn't a crappy language that encourages programmers to write dangerous and/or unmaintainable code, ANY language can do that, it's just as easy to write fubar code in C#, it's all up to the developer.. And yes, the error handling is a bit harder, but if done right you can get exactly the same as with any other language, again, it's just up to the developer.. If you really think otherwise, then you really are a dumb developer.. Personally I like the original VB6 language, it's much cleaner to read compared to C# (or any language with all their brackets), BUT yes it lacks a lot of newer programming paradigms, and I still hate MS for dumping VB7 and going with VB.net (yes there is actually a VB7 which is real OOP and has try/catch, but MS never released/finished it, because they went for the .NET framework). You can do about anything you want with VB6 if you take the time to understand the underlaying workings, hell there has been people who have even created inline assembly possibilities.. Saying VB6 is slow, means you just don't know how to handle it, as I said If you know how it works/does things you can speed up a lot, but that's something that goes for ANY language..
And in regard to the posted code, I also don't see any real problems, especially since we didn't see any of the implementation of the used functions.. Would I do it like this in VB6? I don't think so.. would I use VB6 for something like this? Why not (if I know the VB6 runtimes are available on the server anyway), if it gets the job done..
Admin
I think this post was a fail at a WTF itself, as the mistakes in its description presents more lack of knowledge than the script itself.