Comment On Configuration According to Consultants

Yay for API

Guilty!

I have devised my own functions in the past to read a file line by line.

[:$][:$][:$]

Oh... My.... God.



Ok, so you're telling me that if you have a [CONFIG] ini section, that
the settings underneath MUST be in the same order and that order can
NEVER change, ever???



Even better, you substitute lines and configuration values are read
into the wrong variables, which may or may not break your app and have
wonky results.  Brilliant.

At least it does have an error handler!

Since this IS VB6, I'm assuming that FileSystemObject or WScript.*, or
any other COM  API that already provides facilities for storing
crap like this was out of reason; even though this functionality comes
with the OS...

I like the fact that the password is stored in plain text in an ini file.  Security is for chumps anyway.

Wow.  Am I missing something here?





Public Sub WTF()


While True


   MsgBox "How do I get out of this loop???"


Wend





...


   Exit Sub ' <-- I'm just for looks


ErrorHandler:


   MsgBox "Exit Here."


End Sub





Also-- username password in the INI file? :)

Anonymous:

I like the fact that the password is stored in
plain text in an ini file.  Security is for chumps anyway.

...who knows, maybe it is stored encrypted?  But; given the code
block I just saw here, chances are likely that no such precautions like
this would have been used unless the application folder is living
inside the user's profile, which at least would preclude other
non-admins from reading the INI thanks to NTFS permissions.



Consulting code == you pay for what you get.  They don't have an
interest except to collect off that invoice they send you, and MAYBE
the chance of getting future business--so the best way to do that is to
build the software to the specs of whomever is writing the check and
make sure they're happy to the point that they will sign the check when
the bill comes.

Anonymous:

Public Sub WTF()
While True
   MsgBox "How do I get out of this loop???"
Wend

...

Easily generate error 62 and you're out [:D]

Anonymous:

Wow.  Am I missing something here?





Public Sub WTF()


While True


   MsgBox "How do I get out of this loop???"


Wend





...


   Exit Sub ' <-- I'm just for looks


ErrorHandler:


   MsgBox "Exit Here."


End Sub





Also-- username password in the INI file? :)

OMG, another WTF!  Duh... he gets out of the loop by trying to read past the end of the file.  W T F?

The real WTF = missing the "On Error Resume Next" clause...



shame, shame...

This never closes the file! The While loop will not exit until the EOF error is thrown. Everything after Wend is just ignored.

Lets see... to read a file, loop forever and break out only with an
exception -- hopefully caused by the End Of File, but not necessarily.
  Brilliant!



Loop conditions are for wimps any! He, he, he. :)



    -dZ.

It may be stupid but in my opinion its not true WTF quality... everyone at one point has loaded a config file and read through its values line by line (I know I have)... well, okay maybe they at least closed the file after... or at least checked for EOF instead of handling the error... But I can't help but feel dissapointed at its lack of true gut retching mind boggling WTF'ness.

I think I did something like this (with fewer WTF's) a long time ago but I learned about the API calls and rewrote it.

At least he isn't reading or writing data to that WTF known as the Windows Registry. Could you imagine how badly this guy would screw that up? **shudders**

A cooler WTF and I didn't catch this until later... is that this
function can only be called ONE time because it will (most likely) bomb
out near the top when you execute this again.



Okay kiddos... do you know why?

Ah, we've seen far worse. So this guy is guilty of:

1. Being exceptionally optimistic about the format of the .ini file


2. Using error-handling as a means of control flow


3. Never ever relinquishing the file handle during the life of the program

I say he gets to live.

christoofar:

A cooler WTF and I didn't catch this until later... is that this
function can only be called ONE time because it will (most likely) bomb
out near the top when you execute this again.



Okay kiddos... do you know why?

'cuz the file is opened for writing also, preventing other reads and it never gets closed?

christoofar:

A cooler WTF and I didn't catch this until later... is that this
function can only be called ONE time because it will (most likely) bomb
out near the top when you execute this again.



Okay kiddos... do you know why?

Uh, cuz #1 hasn't been freed? Hmm. Wouldn't freefile get around that little conundrum?

John Bigboote:

Ah, we've seen far worse. So this guy is guilty of:

1. Being exceptionally optimistic about the format of the .ini file


2. Using error-handling as a means of control flow


3. Never ever relinquishing the file handle during the life of the program

I say he gets to live.

I DISAGREE!



The way he wrote his loop, he's expecting that the [CONFIG] section is
towards the bottom of the file, because if there are other sections,
then they all have to be read, then the config section, then keep
pushing the file pointer along until EOF is reached.   Ugh.

christoofar:

Since this IS VB6, I'm assuming that FileSystemObject or WScript.*, or
any other COM  API that already provides facilities for storing
crap like this was out of reason; even though this functionality comes
with the OS...

If I recall correctly, GetPrivateProfileString is a Win32 API (kernel32?) not COM.

No excuse for not using it.

Wait a minute. Why does he have a loop at all? It looks like there's always a fixed number of constant settings, or, at least, the only optional settings are the ones at the end --if you omit the 24th setting, you have to omit the 25th and 26th and 27th; otherwise, the values get read into wrong settings. Why not just use the code in the If block? If the file *is* truncated, *then* let it throw a 62.

I got it! If there are *more* lines in the file than possible settings, it loops back to the beginning of the list of settings! Now that's *so* handy. If you want to try out changing one setting but don't want to forget the original value, just Ctrl-A, copy and paste to the end of the .ini file and change that one value! That's way better than copying and renaming the .ini file. Or security! Put a *dummy* password in the first block of settings, and the *real* one in the second! Fooled ya! Hackers never think of *scrolling down* in an .ini file! Genius!

--RA

Cool, I never knew about those INI-reading API calls!

/not kidding

Doesn't look that much different than code I've written.

/still not kidding.

Not recently, fortunately

Rank Amateur:

Wait a minute. Why does he have a loop at all?

He needs the loop in case there are other sections besides [Config].

Anonymous:

The real WTF = missing the "On Error Resume Next" clause...

shame, shame...

This is VB6, so the canonical WTF is that it is not JavaScript.

At least he's only reading from the file, not writing to it with a
string >255 characters in length, a source of brilliant WTF-ery, (he
said, rubbing an old scar reufully...)

Oh yeah, I think I used to work with this guy - he called it "creating
known exceptions"...as if exception handling were meant for flow
control :S

Anonymous:

Rank Amateur:

Wait a minute. Why does he have a loop at all?

He needs the loop in case there are other sections besides [Config].

Other sections which his code ignores? Then why are they there? You mean he also wrote additional subs using the same logic for each of those other sections? WTF compounded.

His way of reading an INI file is clearly more
sophisticated than the old Win32 approach using GetPrivateProfileString.
The Win32 function will only find the first occurrence of a [CONFIG]
section but what if there are several? Of course you want to use the last occurrence
and not the first one so you need to loop until the end of the file.



Everyone knows that the more you earn the smarter you are so you
guys are just jealous of all the brilliant VB6 consultants out there.

Rank Amateur:

Other sections which his code ignores? Then why are they there? You mean he also wrote additional
subs using the same logic for each of those other sections? WTF
compounded.

Hey "Rank," cut-and-paste is what makes an ordinary
WTF into a great one.

HEY, at least it works!

once.

If you have an .ini specifically formatted to work.

and you don't give a damn about security

I give it a 2/5 in my WTFmeter

You guys are missing the biggest WTF:

Your UserName has to be 8 chars, Your Password must be 9 chars .... etc

Not really any point in having a INI file if you cant modify it.

     sSysDir = Mid(sLineData, 8)
     UserName = Mid(sLineData, 8)
      Password = Mid(sLineData, 9)

Nevermind that, I'm retarded, and just woke up ;)

 

Anonymous:

You guys are missing the biggest WTF:

Your UserName has to be 8 chars, Your Password must be 9 chars .... etc

Not really any point in having a INI file if you cant modify it.

     sSysDir = Mid(sLineData, 8)
     UserName = Mid(sLineData, 8)
      Password = Mid(sLineData, 9)

A WTF (for me at least) is that people actually use Visual Basic!!



It is absolutely horrible programming language, why does anyone even use it?

other interesting goofups:

  Public Sub SetConfiguration()

it looks like he's actually "getting" the configuration

  UserName = Mid(sLineData, 8)

if this line starts like "UserName=", then he's getting the equal sign too

  WriteToLog Date & " - " & Err.Number & ", " & Err.Description & " - GetGlobals routine."

if anything else does go wrong, he would only think to look in the other brilliant routine he copied this code from



to the comment that this is not such a bad WTF, no maybe not for a
novice, but you might think differently if you had to pay this guy

pjsson:

His way of reading an INI file is clearly more
sophisticated than the old Win32 approach using GetPrivateProfileString.
The Win32 function will only find the first occurrence of a [CONFIG]
section but what if there are several? Of course you want to use the last occurrence
and not the first one so you need to loop until the end of the file.



Everyone knows that the more you earn the smarter you are so you
guys are just jealous of all the brilliant VB6 consultants out there.

You're a VB6 consultant, aren't you?

FYI

sar·casm (sär'kaz'm)
n.

1.   A cutting, often ironic remark intended to wound.
2.   A form of wit that is marked by the use of sarcastic language and is intended to make its victim the butt of contempt or ridicule.

strongarm:

At least he isn't reading or writing data to
that WTF known as the Windows Registry. Could you imagine how badly
this guy would screw that up? **shudders**

would probably be something like

Open "c:\windows\system.dat" for reading as #1

:D

Consultants do not code in VB - they use real programming languages. So
stop insulting us consultants ....    Oh yes and consultants
forced with a gun to the head to use VB, can still read help
files.  This person is not a consultant .....

WTF's
- Not using freefile(). just using #1 (what if he tries to open more than one file at the same time ?)

- Not checking for EOF

- Not creating a constant for error 62.

- Catering for error 62 in the first place. Normally (not always) if you have to cater for a specific error message, you've done something wrong.

- Having the wrong function name (GetGlobals) in his logging.

- Storing username, passwords in an INI file.
Not using the API

- His program does not detect the CONFIG section ending.

- His ini file HAS to be in a specific order.

- He's doing all this stuff INSIDE the loop, so it would look for the LAST config section !! It would make more sense to do something like:
do
Input #1, sLineData
If UCase(Mid(sLineData, 1, 8)) = "[CONFIG]" Then
exit do
End If
While True ' should be EOF check (assuming there's at least one line in the file)

Input #1, sLineData
sSysDir = Mid(sLineData, 8)
'ED: Snip
Input #1, sLineData
UserName = Mid(sLineData, 8)
Input #1, sLineData
Password = Mid(sLineData, 9)

I hope he didn't get paid.

Anonymous:

Oh yeah, I think I used to work with this guy - he called it "creating
known exceptions"...as if exception handling were meant for flow
control :S

I once worked with a guy who beleived that the following (c++) created unknown exceptions

try
{
...
}
catch (MyException &x)
{
if (x.err == 5) throw; // Unknown exception
}

He didn't know that the throw would just re-throw the last exception.

Anonymous:

Anonymous:

Oh yeah, I think I used to work with this guy - he called it "creating
known exceptions"...as if exception handling were meant for flow
control :S

I once worked with a guy who beleived that the following (c++) created unknown exceptions

try
{
...
}
catch (MyException &x)
{
if (x.err == 5) throw; // Unknown exception
}

He didn't know that the throw would just re-throw the last exception.

Forgot to mention that he was the c++ technical lead !

I vote for getting new forum software !!! Maybe we should raise some funds for Alex ?

Well, at least it's fast. If the ini file is, for some reason yet to
explain, 1.3 GB large, you will definitely notice that this solution is
much faster than the API calls. For a ini file containing n entries,
the complexity of this solution is o(n), while API calls are probably
o(n^2).

Ouch! That hurts.



Maybe he should've consulted someone experienced, at least he should've read the richt text formatted manual. My first contact with an INI-file was with Delphi 1 way back in 1997, and I just knew, that there just had to be a class or a method to read such files. Since VB was the favorite of Gates™, I never would've had the idea, that there was no class or function to easily read and modify INI-files.

If I remember this correct... He also failed to call FreeFile. Channel 1 could be busy.

christoofar:

Anonymous:

I like the fact that the password is stored in
plain text in an ini file.  Security is for chumps anyway.

...who knows, maybe it is stored encrypted?  But; given the code
block I just saw here, chances are likely that no such precautions like
this would have been used unless the application folder is living
inside the user's profile, which at least would preclude other
non-admins from reading the INI thanks to NTFS permissions.

Sometimes storing the password in plain text is the better option. You
need the plaintext password if you want to implement some sort of
challenge-handshake authentication.



regards

fg

I seem to remember, from the dim distant memory of doing my A-level
Computer Science project in VB 3 that there are API calls for dealing
with encrypted passwords too... (not that I was writing anything to
retrieve the school's screensaver passwords or anything, ooooh no)

In today's world, any programmer that wrote code like this should get
the boot. For such a simple process, one could use Xml APIs and an Xml
document for this; that way you get accuracy, certainty as well as
extensibility (for instance the password could be stored inside the
registry instead and code is used when a certain element is found...)



Anyone caught still using such outdated means as shown by Alex ought to be hung, drawn and quartered.

Gee, I used to write code like that too... when I was 6 years old and hacking on my C64 :)

Anonymous:

Consultants do not code in VB - they use real programming languages. So
stop insulting us consultants ....    Oh yes and consultants
forced with a gun to the head to use VB, can still read help
files.  This person is not a consultant .....

Yeah, right.

Consultants are whores who will code in any language the client wants.

I used to be a consultant and got out 'cuz I was sick and tired of writing shitty systems just to maximize billings.

Anonymous:

christoofar:

Anonymous:

I like the fact that the password is stored in
plain text in an ini file.  Security is for chumps anyway.

...who knows, maybe it is stored encrypted?  But; given the code
block I just saw here, chances are likely that no such precautions like
this would have been used unless the application folder is living
inside the user's profile, which at least would preclude other
non-admins from reading the INI thanks to NTFS permissions.

Sometimes storing the password in plain text is the better option. You
need the plaintext password if you want to implement some sort of
challenge-handshake authentication.



regards

fg

Are you serious?

Wouldn't you just use a hash of the password instead of the cleartext?