Comment On The Lemming Switch

Long time reader, frist time commenter!

Can sumone be posting Java version of this code plz?

Should have just used a cron job.

I'm probably being a dumbass but apart from the fact that he made a desktop app instead of a service, where's the wtf? I'd also like to know how the code caused a page fault - I can't see a reason from the code...

Kevin continues, "my first reaction to the code was wondering how one might stop this 'service'?

This was your frist reaction, really? (Doesn't Windows provide some standard ways to terminate programs?) My frist reaction would be the ~1 WTF per line (spread between the "developer" and VB, of course) ... or whether the program does anything at all apart from getting and searching.

Does this code do anything other than search for files over and over again on an infinite loop? I'm pretty rusty on VB..

The code is not something one would be very proud of but where is the WTF?

Also the author does not seem to know what a page fault is: http://en.wikipedia.org/wiki/Page_fault.

Daverino:

Does this code do anything other than search for files over and over again on an infinite loop? I'm pretty rusty on VB..

It is not possible to determine that because we are not given the code for "SearchListForFile" method.

strIniFileLoc wasn't initialized, which may or may not cause the custom GetPathFromIni to fail.

We're also missing the implementation of SearchListForFile, which seems to be responsible for the brunt work.

Of course TRWTF is that Alex has no clue what a "page fault" is.

Keep in mind that, from the language used in the article, this wasn't the final code, just a checkpoint along the way. We don't even have the code that does the actual killing of files, just the crazy bad infinite looping structure and half assed (pseudo?)code.

Alex or Kevin?

Can VB6 even get page faults? It's a managed runtime.

I don't see anything wrong with this code, assuming the functions we don't see work properly. Is it the best solution? No, but it does the job.

Spivonious:

Can VB6 even get page faults? It's a managed runtime.

It's so cute went application devs, and the OP/editor, try to talk about OS basics they nothing about.

PG4:

Spivonious:

Can VB6 even get page faults? It's a managed runtime.

It's so cute when application devs, and the OP/editor, try to talk about OS basics they nothing about.

FTFY

John:

PG4:

Spivonious:

Can VB6 even get page faults? It's a managed runtime.

It's so cute when application devs, and the OP/editor, try to talk about OS basics they nothing about.

FTFY

I don't about that.

I think I speak for everyone when I say that anyone who codes like this shouldn't be let anywhere near the Windows API.

I worked with someone who did something like this. Platform was .NET though, but I think his implementation beats this one:

His app needed to 'watch' certain things (about 100 in total). He figured the best way to do this was to kick of a thread for each item, and each thread was running a timer.
Thing was, he used the System.Timers.Timer, executes in a thread-pool. So for all his work to make sure each thread was truly executing 'individually', they ended up just waiting for the worker thread to be free.

The whole thing was built as a Windows Forms app so it was easier for him to test, then it just landed up on the server like that. You couln't just dump it in the starup items or schedule it either because some buttons/options needed to be selected to get it going.

Is that a Goto I see before me?

huh:

I'm probably being a dumbass but apart from the fact that he made a desktop app instead of a service, where's the wtf? I'd also like to know how the code caused a page fault - I can't see a reason from the code...

A page fault happens when Windows cannot find data in memory and has to go to the disk. The choice for this term is a bit unfortunate because there is not really a fault, just no matching piece in RAM and I/O is starting. For a script that takes care of files 50 page faults should happe quite fast.

First, captcha:
transverbero
Means transfix.
I'm wondering what they meant by page fault, lol. Did they have really really slow disks, like page faults were handled by an old librarian finding the right pages in the book on some shelf in the basement?
(Maybe they meant segfault, lol)

PedanticCurmudgeon:

I think I speak for everyone when I say that anyone who codes like this shouldn't be let anywhere near the Windows API.

Why? It's a script that you write in 15 minutes with no hassle. You would of course go for an XML solution running in Framework 4.1 using more than 20 mandays for something that just has to run in the background.

Killed after 50 page faults? My dwm.exe produces two thousand each second. Killed after 50 segmentation faults? NOW that's patience.

transverbero:(1p sg. v. latin):
(transitive) To render motionless, by arousing terror, amazement or awe.
(transitive) To pierce with a sharp pointed weapon.
(transitive) To fix or impale.
[edit]

"After failing miserably to reason on other solutions, the code was deployed to production. After about the 50th page fault on the server, the 'service' was 'stopped' and promptly removed from existence."

I think he means that the service deleted itself. Notice how he put 'stopped' in quotes. The code sample is not good, but I don't see any obvious WTF.

huh:

I'm probably being a dumbass but apart from the fact that he made a desktop app instead of a service, where's the wtf? I'd also like to know how the code caused a page fault - I can't see a reason from the code...

The gut reaction of the arrogant programmer is to blame the nearest VB application for anything that goes wrong on a computer. This is clearly a hardware issue, and Kevin was wasting valuable uptime with his blame-shifting.

At least he used Option Explicit...

And the real WTF is, of course, the Option Explicit!
VB6 is such a clean language, why do we need to bother with the pesky details of strong typing all of a sudden?

Wow, so much hate for the author...there must be a lot of VB6 enthusiasts reading today.

A page fault is a fault, generated at the hardware layer, saying the memory page you requested is not available right now. The OS deals with it, not the application. It is one of the few things an OS should be doing, as opposed to integrating with one of your web browsers, for instance.

Now an Invalid Page Fault, that's an entirely different animal. Back in the days of Windows 3.x you used to get GPFs (General Protection Faults) all the time. This is where Windows got its reputation for crashing 30 seconds after you back it out of the garage. People hated GPFs. So Microsoft came out with Windows 95 and in a big ad campaign (so effective it had people camping out to buy the software when they had no hardware!) they proclaimed they had gotten rid of all the GPFs! Yaaay!

Except they just renamed them to IPFs. It was still as crashy as ever.

Hah!:

Long time reader, frist time commenter!

And another great mind.

VB6 hater:

Wow, so much hate for the author...there must be a lot of VB6 enthusiasts reading today.

OK, TRWTF is VB6! Are you happy now?

What does "WriteError" do? Is it spitting out the error to a file, then looping back to a module named "Main", or is it writing the word "Main" in the errorlog. If it is the first, then "stopping" the script by moving the ini file would be...an undocumented stability feature?

wllmsaccnt:

"After failing miserably to reason on other solutions, the code was deployed to production. After about the 50th page fault on the server, the 'service' was 'stopped' and promptly removed from existence."

I think he means that the service deleted itself. Notice how he put 'stopped' in quotes. The code sample is not good, but I don't see any obvious WTF.

I have one!

blnLoopEternal = False
Do Until blnLoopEternal = True

Note that it is never once set to true within the loop. By design, the loop is intended to end at some point, but there is never a clean termination of the loop. It relies on the raising of an exception somewhere. Seems very sloppy to me.

Here's another: Instead of making this script a scheduled task, the programmer opted to build in the timing mechanism. If the team decided that they wanted to run this script at different intervals, they would have to modify the code rather than just modifying the task.

TRWTF is no better solutions.

Would you mind enlightening us by explaining where the WTF is? No one has done that yet.

Brødreskift:

First, captcha:
transverbero
Means transfix.
I'm wondering what they meant by page fault, lol. Did they have really really slow disks, like page faults were handled by an old librarian finding the right pages in the book on some shelf in the basement?
(Maybe they meant segfault, lol)

On Windows, and even on x86 Linux/*BSD, I doubt very much they meant a true segfault. In "flat" mode(*) on x86, you normally have to work quite hard in application code to produce a true segmentation violation, aka General Protection Fault, as nobody messes with the segment registers, and all the segments are a full 4GB (except a few hacks to do W^X without an NX bit).

No, undoubtedly what was meant was Invalid Page Faults (i.e. page faults where there isn't supposed to be a page, rather than valid page faults, where the relevant page is not mapped into the process's address space *right now*). Unix-like systems match IPFs onto SIGSEGV, but it isn't normally a segmentation violation.

Funky code that writes using a CS: override will create a proper segmentation fault, of course, but it's hard to write that in VB.

(*) Strictly speaking, x86 doesn't have a flat mode. Flat mode would indicate that the segment registers aren't used at all, whereas even in what looks a lot like a 32-bit flat mode, the segment registers don't even contain the same value. They *cannot* contain the same value because CS must contain a selector for an executable or execute-read segment, and SS must contain a selector for a writeable segment. (Writeable is mutually exclusive with executable. This conundrum is the basis for the aforementioned NX hack.)

On Win32, CS = a 4GB read-execute (code) segment, DS=ES=SS = a 4GB read-write (data) segment, FS = a tiny segment containing the current thread's user-mode thread control block. It is normally used only by Structured Exception Handling. GS is not used.

On Win32s (Win32 on Win3.1), back in the day, the segments weren't even mapped to the beginning of the 32-bit linear address space, but both full-on Win32 in NT and Win32c in 9x mapped offset 0 to linear 0 (except FS:, duh), but linear 0 doesn't necessarily map to physical 0, paging being what it is, and isn't normally marked present either.

VB6 hater:

Wow, so much hate for the author...there must be a lot of VB6 enthusiasts reading today.

Would you mind enlightening us by explaining where the WTF is? No one has done that yet.

There, I can't edit so I'll just double post. Who the hell invented that "Reply to" shit anyway? Either make the "In reply to" more useful(tooltips would be fine) or just remove the "Reply" button and let people use the "quote" (they can always delete the quote anyway).

Tud:

VB6 hater:

Wow, so much hate for the author...there must be a lot of VB6 enthusiasts reading today.

Would you mind enlightening us by explaining where the WTF is? No one has done that yet.

There, I can't edit so I'll just double post. Who the hell invented that "Reply to" shit anyway? Either make the "In reply to" more useful(tooltips would be fine) or just remove the "Reply" button and let people use the "quote" (they can always delete the quote anyway).

You can't edit because you haven't registered.

I think the true WTF is using "Oops" as a exception catching label. It's a distant cousin of "UhOh" and "OhShit"

Tud:

VB6 hater:

Wow, so much hate for the author...there must be a lot of VB6 enthusiasts reading today.

Would you mind enlightening us by explaining where the WTF is? No one has done that yet.

"After failing miserably to reason on other solutions,"

What? No FreeFile()?

On Windows, and even on x86 Linux/*BSD, I doubt very much they meant a true segfault. In "flat" mode(*) on x86, you normally have to work quite hard in application code to produce a true segmentation violation, aka General Protection Fault, as nobody messes with the segment registers, and all the segments are a full 4GB (except a few hacks to do W^X without an NX bit).

Remember that 'segment fault' is a UNIX term that predates the x86, and the x86 segment registers, by quite a bit. I agree with you that having a 'x86 segment register violation' is nigh impossible, that's not what a SEGV means. The segment in this case is the processes' legally addressable memory. You could get a SEGV on a 680x0 which never had segment registers.

captcha: the three ABIGOs.

The Lemming Switch

is a great title for a book
or song or movie
or something


Why can't I just copy and paste the captcha? transcribing it is so tedious.

Weeks before D-Day:

Remember that 'segment fault' is a UNIX term that predates the x86, and the x86 segment registers, by quite a bit. I agree with you that having a 'x86 segment register violation' is nigh impossible, that's not what a SEGV means. The segment in this case is the processes' legally addressable memory. You could get a SEGV on a 680x0 which never had segment registers.

Correct, of course. But the other poster didn't say a SEGV. He said a segfault, perhaps not knowing that a segfault and a SIGSEGV aren't necessarily directly equivalent, but also when talking about a Win32 WTF.

And I, too, have worked on Unixalikes that didn't have segments as such, notably Ultrasparc III+s on Solaris, and IBM AIX machines. Those were weird, because either by hardware feature, OS design or local config, reading via NULL didn't SEGV your program. (It was a large vendor of financial information services, and had systems so large that IBM had to patch the OS to allow single executables to have more than 256MB in their .text segment.)

The page faults are caused by the OS processing of the ini file. Windows has APIs for dealing with ini files that produce locks (somewhere) that prevent another process from accessing an ini file while it is already being accessed. If you run a program like this and the look at it in detail in task manager you will see the page faults. These faults don't really cause a problem except for a very high OS overhead cost. If you do it often enough it will bring even a powerful server to it's knees. (Don't you just love windoze?)

I know this, unfortunately, because I made the same mistake when I was younger and even stupider than I am now. Fortunately, it was easy to find and fix. Used the database instead of an ini file.

WTF is the WTF?

Heywood J:

WTF is the WTF?

TRWTF is that programming snobs look down upon VB.

oldami:

...

Nice try.

[quote user=oldami]The page faults are caused by the OS processing of the ini file. Windows has APIs for dealing with ini files that produce locks (somewhere) that prevent another process from accessing an ini file while it is already being accessed.[/quote]

That's not a page fault, that's a file access violation. And as along as the other process wasn't writing to the .ini file, it's fine. And since this is a custom ini file and the application is single-threaded, the possibility of some other process having that init file open for writing at the same time is probably nil.

Perhaps there was another application whose job it was to delete the ini file (you know, like an admin app to stop this app), and instead of deleting upon command by an end-user, did it constantly in a loop.

(what was probably really happening was the files the app were attempting to delete were open by another application resulting in a file access violation)

oldami:

The page faults are caused by the OS processing of the ini file. Windows has APIs for dealing with ini files that produce locks (somewhere) that prevent another process from accessing an ini file while it is already being accessed. If you run a program like this and the look at it in detail in task manager you will see the page faults. These faults don't really cause a problem except for a very high OS overhead cost. If you do it often enough it will bring even a powerful server to it's knees. (Don't you just love windoze?)

I'm sorry, but this sounds like the biggest load of b******t I've heard in a long time :-)
I fail to see a connection between locking a file and causing page faults.

Fault is a correct term. It just does not deserve the negative connotation when used in this context. Its a fault in that the MMU is basically saying "That is not here", which is not problem, the fault it handled by paging whatever "That" was into memory from disk or other type of secondary storage.

Think of it the same way you think about raising an exception in your code. Its a "bad" thing that an exception been raised, it only becomes bad if its not caught and handled in some way that prevents causes the application/process to fail; otherwise its just a fancy kind of branching.

For those not getting what is wrong with the code:

First, the loop is crazy. Get a list of files in a folder and then for every file in the folder, check to see if it is on the list. Especially since file system object has a way to check if a file exists, it is a whole lot of extra work as opposed to looping through the contents of the .ini file iteslf and just checking the folder to see if it exists -- much more effecient.

Of course that is minor. The major problem is that it does not clean up any resources. It keeps grabbing a file and folder handle each loop. It never sets the variable to "nothing", never giving it a chance to clean up before the next loop. Not that VB6 had any great garbage collection in the first place, but still not a good idea to keep grabbing handles to everything in the loop.

And finally -- it is a VB6 app that does this! Seriously, why would anyone think this is a good idea.