A couple of Error'ds



  • First one probably needs a bit of information before hand. In 1996 Diablo (R) was released, for it's game data it used a proprietary format called a Mo'PaQ (.mpq) which all other games released by Blizzard Entertainment used afterwards. WinMPQ is a third party editor for such files.








  • Hey, I always got Spybot appearing like that on my old computer. So annoying. >_>



  • The first is pretty obvious, the time got reset to 0 somehow...



  • Which is odd because isn't the UNIX epoch Jan 1st 1970, not the day before?



  • @Treeki said:

    Hey, I always got Spybot appearing like that on my old computer. So annoying. >_>


    I had that Spybot problem. Their forums had a manual fix for it (a registry hack, I think). The developers didn't seem
    to concerned about actually fixing the problem though, as its been around for several releases.



  • @Lingerance said:

    Which is odd because isn't the UNIX epoch Jan 1st 1970, not the day before?

    The epoch is 00:00 1/1/1970 GMT, so depending on where you are it could be 12 hours behind/ahead of that.



  • @Lingerance said:

    Which is odd because isn't the UNIX epoch Jan 1st 1970, not the day before?

    Correct, but it's Jan 1st 1970 UTC... So if you're in a negative time zone (UTC-1, etc.) It'll be December 31st 1969 in your local time.



  • @SuperousOxide said:

    @Treeki said:
    Hey, I always got Spybot appearing like that on my old computer. So annoying. >_>


    I had that Spybot problem. Their forums had a manual fix for it (a registry hack, I think). The developers didn't seem
    to concerned about actually fixing the problem though, as its been around for several releases.

    They have mentioned it a few times. [url=http://www.safer-networking.org/en/news/2005-06-22.html]It is a glitch in the development.[/url] The news article on it shows that WTF support is not limited to Microsoft.



  • @versatilia said:

    @Lingerance said:

    Which is odd because isn't the UNIX epoch Jan 1st 1970, not the day before?

    The epoch is 00:00 1/1/1970 GMT, so depending on where you are it could be 12 hours behind/ahead of that.

    Yes, but time() returns -1 for errors - as it happens, -1 is also a valid value, representing  Wed Dec 31 23:59:59 UTC 1969



  • The first one is pretty easy to explain: having used WinMPQ regularly over the past five years, I can only conclude that it does date from the punchcard days. Its uncanny ability to corrupt .mpqs is just one symptom, the fact that it does different things depending on whether you drag and drop one file from the .mpq archive or multiple ones is another symptom.



  • @Random832 said:

    Yes, but time() returns -1 for errors - as it happens, -1 is also a valid value, representing  Wed Dec 31 23:59:59 UTC 1969

    Rather stupidly, all negative values are technically errors, cutting the maximum representable date range in half.

    As the 32-bit version of time() (and associated functions) only really use 31 bits and so can only go up to Jan 19 2038, 3:14:07 (a date/time which is inexorably approaching), the last date/time plugin I wrote (optionally) used the 64-bit versions and chopped the result to 32-bit, doubling the date range to Jan 1 1970, 0:00:00 - Feb 07 2106, 6:28:14, without needing to change how the timestamps were stored.

    Anyone who still writes code using the 32-bit versions of time() should be slapped hard with a clock.



  • @robbak said:

    @SuperousOxide said:

    @Treeki said:
    Hey, I always got Spybot appearing like that on my old computer. So annoying. >_>


    I had that Spybot problem. Their forums had a manual fix for it (a registry hack, I think). The developers didn't seem
    to concerned about actually fixing the problem though, as its been around for several releases.

    They have mentioned it a few times. [url=http://www.safer-networking.org/en/news/2005-06-22.html]It is a glitch in the development.[/url] The news article on it shows that WTF support is not limited to Microsoft.

    It is interesting how that page on S&D's site makes so much of the fact that they have blamed this on a bug in Delphi's code that Borland know about and - despite having been aware of it for some considerable time, and having released a number of new versions of their code, Borland have not fixed it.

    On a totally unconnected subject... Have you noticed that a number of people have reported this display error to Spybot's developers and, despite having been aware of it for some considerable time, and having released
    a number of new versions of their code, they have not fixed it.



  • @GettinSadda said:

    @robbak said:

    @SuperousOxide said:

    @Treeki said:
    Hey, I always got Spybot appearing like that on my old computer. So annoying. >_>


    I had that Spybot problem. Their forums had a manual fix for it (a registry hack, I think). The developers didn't seem
    to concerned about actually fixing the problem though, as its been around for several releases.

    They have mentioned it a few times. [url=http://www.safer-networking.org/en/news/2005-06-22.html]It is a glitch in the development.[/url] The news article on it shows that WTF support is not limited to Microsoft.

    It is interesting how that page on S&D's site makes so much of the fact that they have blamed this on a bug in Delphi's code that Borland know about and - despite having been aware of it for some considerable time, and having released a number of new versions of their code, Borland have not fixed it.

    On a totally unconnected subject... Have you noticed that a number of people have reported this display error to Spybot's developers and, despite having been aware of it for some considerable time, and having released
    a number of new versions of their code, they have not fixed it.

     I find it odd that they blame it on a bug that I've never come across and have never seen a big deal made of. I'm sure the IDE would be rendered unusable if it truly did randomly rearrange UI elements every time you opened a project.
     



  • @Kemp said:

    I find it odd that they blame it on a bug that I've never come across and have never seen a big deal made of. I'm sure the IDE would be rendered unusable if it truly did randomly rearrange UI elements every time you opened a project.

     

    There are actually bugs that do exactly this (moving Controls a few pixels every time you open the form).

    But a workaround really shouldn't be difficult at all. 



  • @It is a glitch in the development said:

    But while every software has some bugs, this is one that shouldn't have been necessary.

    This is one that shouldn't have been necessary? What's a necessary bug?



  • @Thief^ said:

    @Random832 said:

    Yes, but time() returns -1 for errors - as it happens, -1 is also a valid value, representing  Wed Dec 31 23:59:59 UTC 1969

    Rather stupidly, all negative values are technically errors, cutting the maximum representable date range in half.

    False.

    @C standard said:

    7.23.2.4(3) The time function returns the implementation’s best approximation to the current calendar time. The value (time_t)(-1) is returned if the calendar time is not available. If timer is not a null pointer, the return value is also assigned to the object it points to.

    (Emphasis mine.) Now, the C standard defines precious little else about the time_t representation [notably, there's nothing stopping it from being unsigned, so (time_t)(-1) doesn't even have to be negative; it could be a large positive value. To check for an error you have to compare the value directly to the expression "(time_t)(-1)"] - the unix standards (POSIX and descendants) are a bit more explicit, specifying that it represents seconds and 0 is midnight new years 1970; but otherwise uses the same wording (I can find no requirement that it even be signed, though obviously it traditionally is)

    @Thief^ said:

    As the 32-bit version of time() (and associated functions) only really use 31 bits and so can only go up to Jan 19 2038, 3:14:07 (a date/time which is inexorably approaching), the last date/time plugin I wrote (optionally) used the 64-bit versions and chopped the result to 32-bit, doubling the date range to Jan 1 1970, 0:00:00 - Feb 07 2106, 6:28:14, without needing to change how the timestamps were stored.

    Anyone who still writes code using the 32-bit versions of time() should be slapped hard with a clock.

    Other than windows, most systems only provide one version of time(). And, regardless, the range of 32-bit time_t is from some time December 13, 1901, to some time January 19, 2038. Even 23:59:59 Dec 31 1969 can be differentiated from an error if you pay close attention to errno, using the same procedure you have to do when checking the strtoul result for an error.

    errno = 0;
    if([some function returning time_t] == (time_t)(-1) && errno) {
    // there was an error
    } else {
    // there was not an error
    }


  • @Thief^ said:

    Anyone who still writes code using the 32-bit versions of time() should be slapped hard with a clock.

    P.S. Anyone who writes code that gratuitously depends on the existence of non-standard function names like _time64() should be slapped with a copy of ISO 9899 - you did define the appropriate macro and use time(), rather than calling _time64 directly, right?



  • @GettinSadda said:

    It is interesting how that page on S&D's site makes so much of the fact that they have blamed this on a bug in Delphi's code that Borland know about and - despite having been aware of it for some considerable time, and having released a number of new versions of their code, Borland have not fixed it.

    It is really interesting. The link is dead this morning (at least from my location), so I can't see what they blamed on Borland. I can tell you, though, that there isn't a date-related bug in Delphi that I've been able to find, having used every version of Delphi since version 1 was released. I also have a series of about 60 date-related functions that (obviously) rely intensively on Delphi's TDateTime implementation, and having sold several thousand copies of the libraries have never received a bug report related to dates.

    Also, Delphi's TDateTime is based on MS's COM implementation of dates (since Delphi 2, the first 32-bit version, was released), which sets the 'zero' date to be 12/30/1899 at midnight. However, negative dates are supported back to 01/01/0001 (TDateTimeValue = -693594.00).



  • The borland bug they link to is here:  http://qc.borland.com/wc/qcmain.aspx?d=11989

    But basically it's an IDE bug where closing & opening a project results in dialog sizes being changed.  I've never used Borland Delphi before, so I have no idea how impactful that is.  I know in VS I could write a basic macro to resolve the issue and set button sizes where they should be.

    Many of those who're using our new version 1.4 have already noticed an obvious bug: on the Registry Warning dialog, the buttons are misplaced and partly hidden by the checkbox text. But while every software has some bugs, this is one that shouldn't have been necessary. It comes from a bug in our development environment - Borland Delphi - that automatically rearranges graphical items on the user interface every time one works on the project, which basically means about half an hour of work correcting everything each morning before the actual work can begin. And sometimes, like in this case, the errors created by Delphi even sneak into final releases. We will release an updated version as soon as we've fully tested some workarounds.

    The long version for people interested in software development:

    It's not that Borland would not know of this bug - we regularly report the bugs we found into their Quality Central. But even bugs I reported 18 months ago are still open in their Quality Central, and Borland has released 2 newer versions, and 3 updates for the latest version alone, without fixing most of the problems. And when I was on the phone to Borland, asking for someone who could give me a statement about these bugs, they said it was not enough that I bought the Enterprise edition of their development environment - if I wanted to talk to someone about bugs in the software, I would have to buy premium support first, totally ignoring the implied warranty. Since we wanted to provide our users with an explanation for the bugs that make a new main release necessary more or less directly after releasing 1.4, I asked them for a public statement about some of their bugs that are visible in 1.4. They did hesitantly provide some workarounds, stating that customers paying extra for support would receive corrections (keep in mind the implied warranty that law grants) sooner, but couldn't provide an explanation in the past weeks.

    All the while in the past months, I've received multiple mails from Borland asking me for success stories in ten years of using Delphi or the migration from VCL to .NET. Sadly, they never answered me when I sent them misery stories of using Borland Delphi so far. Since People ask from time to time if we actually develop in Delphi, I've decided to post this, as a counterpost to Borlands success stories (while we still believe in the power of ObjectPascal, we've lost our faith in Delphi for future projects), and as a migration story from Borland Delphi to FreePascal and Lazarus, which will probably be the base for future Spybot-S&D versions.

    From their website.



  • for spypot "errors" 

    its not a problem, its just a setting

     i think its called teatimer

     go to the advanced mdoe, tools (enable resident), resident,  and turn of teatimer



  • Which makes the point of me turning it on useless.



  • @ShadowWolf said:

    The borland bug they link to is here:  http://qc.borland.com/wc/qcmain.aspx?d=11989

    But basically it's an IDE bug where closing & opening a project results in dialog sizes being changed.  I've never used Borland Delphi before, so I have no idea how impactful that is.  I know in VS I could write a basic macro to resolve the issue and set button sizes where they should be.

    Oh. So the post points out a bug that shouldn't be a major problem, except when designing the form, and uses it as an excuse for their poor skills.

    The quote from their site you posted doesn't indicate which version of Delphi it was, but I should note that I've used every version of Delphi except 1 (I didn't upgrade to Delphi 2005 due to financial issues at the time), and I NEVER experienced this bug. Since I do lots of application development (full time as a Delphi programmer) and also ran a consulting company on the side, I spent a lot of time working with Delphi, and again NEVER ran into this issue. 

    And seriously, if this was an issue that users were reporting as a bug, it would have been really simple to:

    1. Design the form as you want it to appear.

    2. Note the Top, Left, Width, and Height of the components on the form.

    3. In the code for the form's OnCreate or OnShow event, set the properties of the components to the ones you've gotten in step 2.

    Voilá! Bug fixed, at least as far as the end user is concerned.

    However, with the free, open source Delphi IDE add-in GExperts, it would be a matter of:

    1. Shift-clicking on the components on the form to select them.

    2. Put the code editor cursor inside the implementation of OnCreate or OnShow for the form.

    3. Choose the GExperts menu item "Components to Code"

    Done.

    So I don't know who wrote the post you quoted (and don't care enough to track it down), but they're morons. And while FreePascal/Lazarus are impressive open source projects, anyone who would consider seriously doing development in those projects instead of Delphi has proven that they're not smart enough to even be considered morons. FreePascal is much too slow to use for any real work, and Lazarus slows it down even more (on a 2.4Ghz 1GB machine, creating a new application containing a blank form and then hitting the Run button takes over a minute before the form shows; in Delphi 2007, the same entire operation takes about 5 seconds). Also, the availability of components in Lazarus is extremely limited, where Delphi 2007 Pro version out of the box comes with about 400.

     ShadowWolf, thanks for providing the quote from their page. I always enjoy a little entertainment. :-)



  • Oh, and one more thing. The problem I see in their screen is not caused by a bug in Delphi, but by the user selecting something other than Windows default 96 pixels per inch (most likely 120), commonly referred to as "large fonts". If you don't take the effort to design your application to support large fonts properly, you get these same issues.

    I know this because one of the main users of my applications has severely bad vision, and uses both a setting of 120 pixels per inch, but also sets the font size to something like 12 and bolds it to make it easier for her to see. I make sure everything stays right for her by testing every visual change by configuring my machine to font size 12 bold and setting 120 px as the default. If things are right, I don't see any problems. If they're not, I see the types of problems in the screen image above.

    And yes, it's a royal PITA to have to reconfigure my monitors everytime I change something in the GUI of about 10 different apps that this particular user runs; however, it's worth it so that she's more comfortable and can work easier.
     



  • It's plainly obvious from the screenshot that it's not a large font issue.  The layout is completely garbled, not just slightly off.

    Still, I also used Delphi for years and never found this elusive layout "bug".  In fact, I tried following the exact steps to reproduce in Delphi 2006, and did not get this magical control resizing.  It doesn't happen in Delphi 6 or 7 either.  One app has about 30 forms and at least 25,000 LOC, and has been migrated through 3 versions of Delphi, and I've simply never witnessed this behaviour.

    So what's his problem?  My guess is that it's some custom or 3rd-party control he's using that wasn't written very well.  It does say Delphi 9 on the case, which I think was Delphi 2005 and was a real pile of crap - but I think I would remember a bug like that, and in any case, that's 3 versions old so it's pretty silly to complain that it hasn't been fixed when it actually has.

    I had enough problems with Delphi to move to VS, but blaming this particular problem on Borland is just absurd.



  • @Aaron said:

    It's plainly obvious from the screenshot that it's not a large font issue.  The layout is completely garbled, not just slightly off.

    Still, I also used Delphi for years and never found this elusive layout "bug".  In fact, I tried following the exact steps to reproduce in Delphi 2006, and did not get this magical control resizing.  It doesn't happen in Delphi 6 or 7 either.  One app has about 30 forms and at least 25,000 LOC, and has been migrated through 3 versions of Delphi, and I've simply never witnessed this behaviour.

    So what's his problem?  My guess is that it's some custom or 3rd-party control he's using that wasn't written very well.  It does say Delphi 9 on the case, which I think was Delphi 2005 and was a real pile of crap - but I think I would remember a bug like that, and in any case, that's 3 versions old so it's pretty silly to complain that it hasn't been fixed when it actually has.

    I had enough problems with Delphi to move to VS, but blaming this particular problem on Borland is just absurd.

    For the record, I have seen oddities similar to that before.  I used to have abysmal vision so would often increase the size of the default font to 120 as well.  This went so far as to cause some windows to be complete void of any text for some reason.

    I'm not saying Ken is right, I'm just saying I personally wouldn't discount the possibility.



  • I've had this messed-up teatimer message on every single computer where I've installed S&D. And I did install S&D on quite a lot of computers, all with different settings and displays. And the same problem has been happening for A LOT OF months.

     

    I just checked and the fix appears to be there : http://forums.spybot.info/showthread.php?t=122    which means the problem dates to at least Oct 2005 

    I don't understand how such a problem is not fixed yet... 

     



  • already can't edit... grrr

    i see the last page of the thread i just pointed out says that this problem is (at last !) fixed in spybot 1.5 



  • @KenW said:

    And yes, it's a royal PITA to have to reconfigure my monitors everytime I change something in the GUI of about 10 different apps that this particular user runs; however, it's worth it so that she's more comfortable and can work easier.

    Are these settings part of the profile? You might add a test user to your machine.

    I did that for testing stuff under XP Luna in all its play-doh glory. I'm real man so obviously I use the classic theme. :)
     



  • @dhromed said:

    Are these settings part of the profile? You might add a test user to your machine.
    The DPI settings aren't, but that's why we have VMWare & co..


Log in to reply