billroper: (Default)
I figured out the source of yesterday's problem.

I had put in a forward definition for a class in a header file so that I could declare a pointer to an object of that type inside the class that was defined in the header file. Like this:

class AnotherClass;

class ThisClass
{
...
  AnotherClass*   anotherClassInstance;
};


When I destroy ThisClass, I want to destroy the instance of AnotherClass that it contains. No problem. I'll just call delete on the pointer like this:

delete anotherClassInstance;


That should work just fine.

Except it didn't. Because I hadn't actually included the header file for AnotherClass in the .cpp file for ThisClass. What I would have expected was that this should have produced a compile error telling me that I was operating on a class that hadn't been completely defined.

But there was no compile error. Instead, the Visual Studio compiler just called delete on anotherClassInstance like it was a pointer to a random chunk of memory with no destructor.

Hilarity ensued.

Well, at least I should remember what caused me to waste so much time the next time I run into this problem...

*grumble*
billroper: (Default)
Foolishly, I trusted Microsoft's assurances that the girls' computer and apps were Windows 10 compatible. Foolishly, I believed that things could be rolled back the same day that I'd run the Windows 10 upgrade.

Lies. All lies.

I tried doing a partial restore from the Acer hidden partition. That reinstalled Windows 7 partially, but the install couldn't finish for some unspecified reason. I finally gave up and wiped the old installation out completely, losing all of the Minecraft Worlds on that machine, but I did manage to get Windows 7 to boot again before going to bed some time after 3 AM. I set the machine to download updates, of course.

A shame I didn't think to turn off the sleep function. A shame that the sleep function will shut the machine down in the middle of downloading updates too. Who designed this mess?

Oh, right. Microsoft.

I turned off the sleep function in the morning and managed (finally!) to get the updates downloaded and installed. And then I had to reinstall the critical software which was -- happily! -- not much.

Well, it's a clean machine.

Should have renamed it "Penny Lane"...
billroper: (Default)
So since Microsoft claimed that Windows 10 was compatible with the newer of the bedroom computers and the apps installed there, I figured I'd go ahead and run the upgrade from Windows 7. It looked like everything ran fine.

Right up until Katie tried to run Minecraft. Minecraft won't run, because the default driver that Microsoft installs for this old Intel chipset doesn't support OpenGL. There is no Intel driver for Windows 10 and the older drivers won't install.

So I figured I'd uninstall Windows 10 and revert back to Windows 7.

Except that option is missing.

I've tried telling it to go back to an older version via a different restore path, but the computer has been sitting there for hours now saying "Restarting".

Thanks, Microsoft, for making my little girl cry.

"Compatible". I do not think that word means what you think it does.

Rat bastards.
billroper: (Default)
A bit less than eight years ago when I was building George Washington's Computer (so named, because I have replaced everything on it except the motherboard, CPU, and RAM), I made a mistake. I decided that I would install 32-bit Windows Vista Ultimate instead of the 64-bit version. Despite the fact that I've upgraded from Vista to Windows 7 and now to Windows 10, this decision leaves me mired on the 32-bit version which is seeming like a worse and worse idea. Now, it's possible to upgrade to the 64-bit version using the license that I have, but that would mean wiping the machine and reloading all of the software and data. This is most of the work that's required to actually build a new computer.

Of course, it's also cheaper than building a new computer. And since George's box has a quad-core Intel CPU running at 2.4 GHz, it's pretty fast all things considered. A new computer would be faster, but not enough faster to justify paying to build a new box. And reloading all of the software isn't really worth it to get to 64-bit. So here I am.

I had thought that I might need to upgrade to 64-bit just to get a stable set of video drivers, but NVIDIA finally released 32-bit Windows 10 drivers for my card that don't crash continuously. This makes me happy.

But then there was this afternoon's adventure. I needed to resize an image in Photoshop, so I started up the application, which promptly hung with a hidden window complaining about a bad monitor profile. I thought that I'd fixed this problem, but apparently not. A bit of Googling pointed me in the right direction and I went to delete the profile, but I couldn't because the profile was in use.

OK. I'll reboot. Except first, the system wants to install updates. Fine.

And once it rebooted, I still can't delete the profile, because it's in use.

OK. I'll reboot to Safe Mode. How the heck do you do that in Windows 10? Back to Google...

Once I rebooted in Safe Mode, I was able to delete the offending monitor profile. In fact, I deleted all of the monitor profiles. Then I deleted a few trillion scanner profiles from a MicroTek scanner that we no longer have, because eight years is a long time and drivers are something that companies don't maintain.

And after rebooting one more time, I was able to run Photoshop and resize the image so that I could finish up the project I was working on.

*sheesh*
billroper: (Default)
So after my enforced Windows 10 update from last night, I attempted to log in this morning.

In round 1, my Start Menu had been reset to the default, my wallpaper was missing, and none of my files were accessible.

Then the machine crashed out when I tried to log out.

Round 2: I log in and am given the "Hi. Your computer has been updated. All of your files are where they used to be." message. Miraculously, the files are there when this nonsense abates and I am allowed to log in. My wallpaper was still missing. I am run through the procedure to establish a Microsoft One Drive which I don't intend to use, but which I figure I will let it do to get it to shut up. And when I tried to go to the Start Menu, it crashed and I got a message telling me to log out to reload it.

Round 3: So I log back in. Now I have my correct Start menu back and can access my files. I pull up my email and try to display one of the mails in my default browser, Google Chrome.

The email displays in Microsoft Edge.

I fire up Google Chrome. It says that it is still my default browser.

Apparently, "default browser" does not mean what you think it does, grasshopper...
billroper: (Default)
Ever since I installed Windows 10 Professional on George Washington's Computer, it has become decidedly less stable. The video drivers are crap and reset themselves frequently with no real pattern. Sometimes, the machine just crashes and reboots itself, probably due to the same crappy video driverz.

Right now, the system has decided to install updates without asking. Maybe this will be an improvement.

But I doubt it.
billroper: (Default)
George Washington's computer is not reacting well to the upgrade to Windows 10. It has developed an annoying habit of restarting the display driver and/or rebooting the system. Apparently, the NVidia drivers for 32-bit Windows 10 are buggy as all get out.

I could try upgrading to 64-bit, but that would require a wipe and reinstall of everything. At that point, building a new computer looks like a better and better idea.

But who knows? Maybe NVidia will ship some video drivers that actually don't crash.

Maybe.
billroper: (Default)
The good news about having worked with various versions of Windows for a long time is that I can usually manage to figure out how to fix things that go wrong after an OS upgrade. (Because things go wrong after an OS upgrade.) And Google is my friend.

Tonight's entertainment was that my Adobe Photoshop CS 5.1 wouldn't start. It turned out that there was a dialog about a bad Samsung monitor calibration that I had been able to click through in earlier versions and ignore that was now both present and completely inaccessible. The only thing to do was to kill Photoshop in Task Manager which did nothing for getting my work done.

But I applied my Google-fu and eventually:

  • Edited the registry
  • Ran the Windows Color Management software to try to delete the bad profile
  • Ran the Windows color calibration software

    By the time I'd done the last of these things, Photoshop would run again.

    *sheesh*
  • billroper: (Default)
    I let Microsoft upgrade my main computer to Windows 10 a couple of days ago. It's only being moderately annoying, save for the fact that the "Microsoft Solitaire Collection" stubbornly refuses to run.

    What good is a computer with no solitaire game? :)
    billroper: (Default)
    I found and fixed the COM problem from yesterday. It may have been an uninitialized IStorage pointer -- I'm not sure. But I fixed that and converted all of the property set handling to use smart COM pointers and the problem went away, so that's a good thing.

    Then I fixed a couple of different serialization problems. One was a newer version of the C++ serialization that hadn't been copied to Java. The other was a problem with some old software that had allowed a bad combination of methods on a dialog; I patched it by correcting the values on the inbound fly, so I had to fix that both in C++ and Java.

    But they're better now!
    billroper: (Default)
    We still use OLE compound document files to store our entities on a desktop. This normally works pretty well until someone does something odd in our code. In this case, what someone did was some fancy footwork with opening and closing the storage underneath a document in order to get it to be smaller than it would otherwise be by saving it as a new storage.

    The only problem is that it doesn't work. It looks like something else has grabbed a reference to the underlying IStorage and the associated IPropertySetStorage.

    Figuring out what did this is just a wee bit challenging since there's no way to directly observe the reference counts in the debugger. The only way to get a reference count on a COM object is to AddRef and Release it, each of which will return the current reference count. And that trick doesn't work if you used a smart COM pointer, because you aren't allowed to AddRef and Release those directly, so you have to create a new reference to the IStorage and AddRef/Release it to get the overall reference count.

    At the moment, I am extremely annoyed and getting ready to add a lot of instrumentation to this mess so I can sort it out.

    *grumble*

    In other news, Katie asked me to send you a message: :)
    billroper: (Default)
    I have now run into the same bug in Visual Studio 2010 that one of my coworkers did.

    Visual Studio 2010 randomly -- and frequently! -- shuts down and restarts.

    Will it crash when solution loads?

    Yes, it will crash when solution loads.

    Will it crash when I compile?

    Yes, it will crash when you compile.

    Will it crash when I debug?

    Yes, it will crash when you debug.

    It will not load, debug, compile.

    It is a steaming, stinking pile.

    Can Microsoft Support help you?

    My friend tried, but they couldn't do

    A single thing to fix this mess,

    They spent a week, no more, no less

    And threw their hands up in despair.

    They cannot fix this anywhere.

    No, it will crash, this stinking toad.

    Perhaps if Windows you reload

    The problem just might go away.

    Who knows? Who knows? And who can say?
    billroper: (Default)
    There are still some bugs to work out with my Open XML implementation, to be sure. However, it was taking about 80 to 90 seconds to open the entity with the 10,000 line report in the old code base. It's now taking 43 seconds. Of that 43 seconds, about 15 seconds is retrieving the big chunk of XML that describes the data values that need to be updated on the 10,000 line report. The actual update with Open XML takes 4 seconds.

    This is looking promising if we can shake the bugs out. :)

    Bug Fest

    May. 14th, 2015 07:26 pm
    billroper: (Default)
    After a lot of messing around and reading of documentation, my Open XML code seems to be working, based on what I see when I open up the resulting XLSX file and export the individual XML chunks.

    Visual Studio 2010 is randomly shutting down for no apparent reason and other bits of our software appear not to be working correctly, but the Open XML code seems to be working.

    I hope it is more than "seems".
    billroper: (Default)
    Back from Marcon and back to work.

    So before I left, I was having a deep and abiding problem getting Microsoft's Open XML toolkit to work with a MemoryStream, because the MemoryStream couldn't be resized, nor could I find a way to get the resulting changes to the document written out to a disk file. This was after reading every bit of documentation I could find.

    Today, it seems that my Google-fu turned back on, because I found the sample code that:

  • Explained how you could get a resizeable MemoryStream by creating an empty one and then copying the byte array of data into it.
  • Showed how you could call MemoryStream.WriteTo to send the resulting document to a FileStream.

    *thud* *thud* *thud*

    This should not have been this hard to find.
  • billroper: (Default)
    Ok, what kind of person devises an SDK where you cannot read the data in from one source and write it out to a different location?

    Well, Microsoft, apparently.

    *sheesh*
    billroper: (Default)
    So it's bad when the 32-bit C++ calculations work and the 64-bit C++ version of the calculations doesn't. Today was the latest day when I dug back into the problem to find out what the heck had gone wrong, because there's really no reason why a simple difference in the bitness of the compile should be causing the calculations to go awry.

    I fairly quickly found a problem with the account filtering function that was causing it to exclude accounts with subaccounts on the C++ side and to exclude the subaccounts on the Java side of the universe. That problem was definitely a suspect, so I cleaned it up. This is what happens when you keep rearranging exactly how the subaccounts are going to work in the revised architecture.

    Sadly, this did not fix the problem. On the other hand, it was probably just as well that it didn't, because that code failed in both the 32-bit and 64-bit C++ versions before the fix, so it couldn't explain why one worked and the other didn't.

    Back into the debugger. I finally discovered that one of my functions that was looking up a data array in the 64-bit version was returning NULL. What the heck?

    See, I had a base class in C++ that provided the definition of an implementation and a derived class that actually implements all of the functions. In the base class, I defined:

    virtual MyArray* GetArray( INT_PTR i ) { return NULL; } // probably should have just been an pure virtual function definition, I suppose

    In the derived class, I defined:

    virtual MyArray* GetArray( int i ); // one of these things is not like the other in 64-bit land

    In the 32-bit compile, INT_PTR is substituted by int and everything works correctly.

    In the 64-bit compile, INT_PTR is a distinct type from int. Everything compiles happily, but you will never get to the function in the derived class when you call through a base class pointer, because the "overriding" function implementation has a different signature and never overrides the base class implementation.

    *thud* *thud* *thud*

    I'm sure this was correct at one time or another, but with all of the merges that have been done on this particular code line and the various hands that were trying to clean up 32/64-bit compile problems, this one got missed.

    Ah, well. Fixed now. :)
    billroper: (Default)
    This would be easier, I understand, if the version of our software that I was trying to compile was being compiled with Visual Studio 2010 instead of Visual Studio 2005. But it isn't and so here I am.

    Microsoft goofed in a big way when they issued revisions to the MDAC (Microsoft Data Access Classes) with Windows 7 SP1 and Windows 2008 R2 SP1 that made applications that were compiled on those systems incompatible with earlier versions of Windows. *oops* And it took them a long time to figure out how to fix it. But a fix has been issued.

    And if you're compiling your application on the newer versions of the OS, you need to include a line that says "#import "MSADO28.tlb" to be able to work on all supported versions of Windows.

    Unfortunately, if you're compiling your application on an older version of the OS, you need to include a line that says "#import "MSADO15.dll".

    These are notably different lines.

    And we have a mix of machines where we do development and builds that have different versions of the OS installed.

    I have figured out a way to work around this in Visual Studio 2005, but it's distinctly less than pretty.

    *sigh*

    Enough

    Jul. 27th, 2013 12:02 am
    billroper: (Default)
    I'm trying to debug our ADO connectivity to an Oracle database using the Oracle OLE DB drivers.

    It turns out that there's something ugly that Microsoft did to the MDAC that messed things up pretty thoroughly. I grabbed the newer versions of the MDAC drivers (version 2.8, so that we're backward compatible to Windows Server 2003) and that fixed up the connectivity problems.

    Unfortunately, it just looks like the SQL statements that we've written to pass to the Oracle DB are wrong. And I don't speak SQL of any flavor.

    So I have called for help.

    And that is quite enough for a Friday night.

    Clear!

    Jul. 24th, 2013 11:08 pm
    billroper: (Default)
    I have knocked off the bugs that were assigned to me for our upcoming patch release and can now work on something that's more fun. :)

    (Ok, I walked through a 17,000 line file today where the least problem that I fixed was unnecessary extra copying of assorted BSTRs of possibly great length; others of the BSTRs were being leaked, because no one ever freed them. Almost anything is more fun...)

    Profile

    billroper: (Default)
    billroper

    July 2017

    S M T W T F S
           1
    2 3 4 5 6 7 8
    9 10 11 12 13 14 15
    16 17 18 19 20 21 22
    23242526272829
    3031     

    Syndicate

    RSS Atom

    Most Popular Tags

    Style Credit

    Expand Cut Tags

    No cut tags
    Page generated Jul. 24th, 2017 12:50 pm
    Powered by Dreamwidth Studios