I was having extraordinary difficulty copying a 4GB file from my host to a virtual machine.
VirtualBox shared folders weren't working (client add-ons unable to be installed).
Windows file sharing, which usually did the trick, had frozen due to my host getting its nappy in a knot, and rebooting wasn't a suitable option.
I had IIS (a web and FTP server) on my host, and tried sharing the file through that, only to discover that just over 2GB into the transfer, the transfer froze - obviously a bug with something somewhere using a 32-bit signed integer and dying at the moment the transfer reached the highest number that can be represented in 31 unsigned bits.
I tried copying the file onto USB external hard disk, then mapping the external hard disk to the virtual machine via VirtualBox's USB mapping, but that too caused much grief and many hangs (not complete system hangs, but VirtualBox hangs).
I did finally, FINALLY, manage to get it to work.
I created a virtual hard disk using the VirtualBox media manager. I happened to use an auto-expand disk so that it would only use as much of my host's storage as required.
I then tried a trial version of the commercial WinMount program. It happily mounted my auto-expanding VDI virtual hard disk, mapped it to a drive letter, and I was able to copy my huge file onto the virtual hard disk.
Then I exited WinMount, mapped the virtual hard disk as a secondary disk to the virtual machine I was trying to transfer the file to, rebooted the virtual machine, and voila, I was able to copy the file from the temporary second virtual hard disk onto the virtual hard disk I wanted it to be on.
VERY convoluted, but we got there.
One weird thing : Norton "security advisor" (or whatever it's called) warned me that the WinMount website is a known source of viruses and/or trojan horses. So, I dunno, my computer might be laced with baddies now. But even though Norton warned about the website, it didn't complain about the WinMount program itself.
In short, if you're wanting to mount a virtual hard disk for read/write access in Windows - especially if it's an auto-expand virtual hard disk - WinMount commercial edition seems to do a very nice job. And it was the only tool I found that even claims to support writing to auto-expand virtual hard disks. So it seems the authors of this tool have managed to accomplish something pretty special.
But of course, don't use it in read+write mode on a virtual hard disk you can't afford to lose, just in case it busts it! i.e. if the virtual hard disk is dear to you, then make a backup before trying ANY 3rd-party tool that purports to provide read+write access! Or so I advise. :o)
Thanks WinMount - I'm puzzled by the virus/trojan warnings, and your on-screen instructions are slightly Chinglishy, but aside from that, your product seems to be very good indeed.
Wednesday, December 1, 2010
Wednesday, June 9, 2010
Telstra NextG USB modem not so good as a backup device
I thought a Telstra NextG wireless broadband (internet) USB modem would be perfect for those occasional trips out to the country.
Keep it in yer bag, recharge at the point of need.
So it sat around waiting to be needed.
I needed it just recently.
But it didn't work.
I phone Telstra.
"The USIM has been deactivated. I'll transfer you to the activations and reactivations department so they can reactivate it for you."
But the lady in the activations + reactivations department gave me the following bad news :
A Telstra NextG data SIM expires permanently after just ONE MONTH without a current data allowance.
I don't recall reading THAT in the promotional material.
I expected to be able to go a month here, a few months there, without using it.
Maybe a permanent expiry after six months of no use would make sense.
But just ONE MONTH?
This means that if you want to use the Telstra NextG USB modem, you have to be buying a new data pack every other month at the very least, even if you're not using the service.
I thought the point of "prepaid" was that you could control exactly what you spent and when!
Apparently I was wrong.
Now, it's not all bad, but it kinda gets worse in one sense...
The lady helpfully informed me that I can just go to a retail outlet and buy another SIM for only $2, then recharge it with whatever denomination I want.
Well, that's nice in terms of getting up & running again now, but that's a lot of hassle if I'm intending to recharge just at the point of need.
I mean, let's keep this in focus : I am willing to pay $20 for a recharge (the minimum recharge amount) for that odd occasion I'm out in the country and suddenly need internet access to provide tech support.
I won't use anywhere near the data allowance on the $20 recharge, I'll typically only use it for tens of minutes, and then it will sit unused for the remainder of its 30 day expiry period and expire mostly unused.
In other words, Telstra's profit margin on my occasional $20 recharge would be STUPENDOUS, and I would still feel like I'm getting value, for the sake of being able to provide tech support on a moment's notice at those critical moments.
But now I'm being told that actually, I need to keep on feedin' the card with recharges, whether I need them or not.
The value proposition of the Telstra NextG device is now plummeting, because its minimum cost has suddenly gone from $99 (the purchase price), to $99 + $120 per year. Not a huge amount, but that's assuming I accept the major hassle of timing my recharges perfectly, and never muck up and have to go through the hassle of getting yet another new SIM. If I take the low-brain-power option (automatic monthly $20 recharges), then we're suddenly talking about $240 per year. Minimum.
As a backup device that would only cost money when needed, and the point of need would justify the cost, it was a valuable proposition.
But a minimum of $240 per year, whether I use it or not?
Sorry, I think I'm going to explore alternatives.
AND I don't think this was adequately disclosed at the point of sale.
The device is not fit for the purpose for which I purchased it, yet I purchased it in good faith based on the representations of and impressions made by the sales and marketing material.
---
On another note, I was ASTOUNDED by the Telstra phone service! I'm used to SHOCKING service. But I received commendable service.
For starters, I rang, and the phone was answered by a HUMAN! This has never happened before!
The human directed my call skillfully.
I waited only a few minutes at most.
An operator apologised for the inconvenience of my NextG device expiring (I didn't make a big deal about it to them, even though it is a big deal, so the fact that they apologised without prompting is nice), and one even said "thanks for your patience with Telstra".
"Thanks for your patience with Telstra"!!! What is the world coming to! A big Telco that understands that we, its customers, are humans, and that they have required us to exercise patience! It's like a great big warm heart has been mystically transplanted into what once was the worst of customer service offenders in the country (or at least, the most notable).
So, I don't know what's happening at Telstra, but something good is happening.
I'm getting answers when I call.
I'm speaking with people I don't have too much trouble understanding.
The list goes on.
It'll take a while, but if they keep up like this, people might even begin to think highly of Telstra.
Like I said, it'll take a while...
Keep it in yer bag, recharge at the point of need.
So it sat around waiting to be needed.
I needed it just recently.
But it didn't work.
I phone Telstra.
"The USIM has been deactivated. I'll transfer you to the activations and reactivations department so they can reactivate it for you."
But the lady in the activations + reactivations department gave me the following bad news :
A Telstra NextG data SIM expires permanently after just ONE MONTH without a current data allowance.
I don't recall reading THAT in the promotional material.
I expected to be able to go a month here, a few months there, without using it.
Maybe a permanent expiry after six months of no use would make sense.
But just ONE MONTH?
This means that if you want to use the Telstra NextG USB modem, you have to be buying a new data pack every other month at the very least, even if you're not using the service.
I thought the point of "prepaid" was that you could control exactly what you spent and when!
Apparently I was wrong.
Now, it's not all bad, but it kinda gets worse in one sense...
The lady helpfully informed me that I can just go to a retail outlet and buy another SIM for only $2, then recharge it with whatever denomination I want.
Well, that's nice in terms of getting up & running again now, but that's a lot of hassle if I'm intending to recharge just at the point of need.
I mean, let's keep this in focus : I am willing to pay $20 for a recharge (the minimum recharge amount) for that odd occasion I'm out in the country and suddenly need internet access to provide tech support.
I won't use anywhere near the data allowance on the $20 recharge, I'll typically only use it for tens of minutes, and then it will sit unused for the remainder of its 30 day expiry period and expire mostly unused.
In other words, Telstra's profit margin on my occasional $20 recharge would be STUPENDOUS, and I would still feel like I'm getting value, for the sake of being able to provide tech support on a moment's notice at those critical moments.
But now I'm being told that actually, I need to keep on feedin' the card with recharges, whether I need them or not.
The value proposition of the Telstra NextG device is now plummeting, because its minimum cost has suddenly gone from $99 (the purchase price), to $99 + $120 per year. Not a huge amount, but that's assuming I accept the major hassle of timing my recharges perfectly, and never muck up and have to go through the hassle of getting yet another new SIM. If I take the low-brain-power option (automatic monthly $20 recharges), then we're suddenly talking about $240 per year. Minimum.
As a backup device that would only cost money when needed, and the point of need would justify the cost, it was a valuable proposition.
But a minimum of $240 per year, whether I use it or not?
Sorry, I think I'm going to explore alternatives.
AND I don't think this was adequately disclosed at the point of sale.
The device is not fit for the purpose for which I purchased it, yet I purchased it in good faith based on the representations of and impressions made by the sales and marketing material.
---
On another note, I was ASTOUNDED by the Telstra phone service! I'm used to SHOCKING service. But I received commendable service.
For starters, I rang, and the phone was answered by a HUMAN! This has never happened before!
The human directed my call skillfully.
I waited only a few minutes at most.
An operator apologised for the inconvenience of my NextG device expiring (I didn't make a big deal about it to them, even though it is a big deal, so the fact that they apologised without prompting is nice), and one even said "thanks for your patience with Telstra".
"Thanks for your patience with Telstra"!!! What is the world coming to! A big Telco that understands that we, its customers, are humans, and that they have required us to exercise patience! It's like a great big warm heart has been mystically transplanted into what once was the worst of customer service offenders in the country (or at least, the most notable).
So, I don't know what's happening at Telstra, but something good is happening.
I'm getting answers when I call.
I'm speaking with people I don't have too much trouble understanding.
The list goes on.
It'll take a while, but if they keep up like this, people might even begin to think highly of Telstra.
Like I said, it'll take a while...
Monday, April 12, 2010
SQL Server refusing to start
Here's a weird one that boggled my brain for a long ol' time.
SQL Server on my development laptop was refusing to start.
I hadn't used it for months, but didn't think I'd changed anything that could affect it.
The error message was plain ol' weird :
"Windows could not start the SQL Server (SQLEXPRESS) on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 3417."
Well, that wasn't weird, but the associated Event Log entry sure was :
"The SQL Server (SQLEXPRESS) service terminated with service-specific error WARNING: You have until SQL Server (SQLEXPRESS) to logoff. If you have not logged off at this time, your session will be disconnected, and any open files or devices you have open may lose data."
Ah - aha? What's all this log off bizzo?
No makey sensey.
Searching the web found only one other website mentioning the problem. One, in the entire world. And their solution was basically to uninstall SQL Server, delete the remnants of the installation folder, and reinstall.
Well, thanks be to God, the answer dawned on me :
To save space on my SSD (where speed was brilliant but size was cramped), I had compressed all my program files.
That works a treat - program files are almost entirely read-only, so both with hard disks and with SSDs of all varieties, compressing program files usually brings a speed improvement, and certainly frees up a lot of disk space.
BUT, I suddenly recalled that SQL Server stores its "master databases" deep inside the Program Files. By itself, that's not a problem. But I also recalled from years ago that SQL Server uses a special type of low-level file system access that is incompatible with NTFS compression. The disk access used by SQL Server is designed to optimise database page caching for uncompressed data files. But it simply cannot work with NTFS-compressed data files. Full stop. (And there are ways to trick it into working, but believe you me, there are substantial write performance implications if you try.)
So I dug into the SQL Server installation folder, and uncompressed the *.mdf and *.ldf files in the Data folder, and all was merriment once more.
For the odd sailor out there cutting close to the wind like me, this might prove helpful. Enjoy! :o)
SQL Server on my development laptop was refusing to start.
I hadn't used it for months, but didn't think I'd changed anything that could affect it.
The error message was plain ol' weird :
"Windows could not start the SQL Server (SQLEXPRESS) on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 3417."
Well, that wasn't weird, but the associated Event Log entry sure was :
"The SQL Server (SQLEXPRESS) service terminated with service-specific error WARNING: You have until SQL Server (SQLEXPRESS) to logoff. If you have not logged off at this time, your session will be disconnected, and any open files or devices you have open may lose data."
Ah - aha? What's all this log off bizzo?
No makey sensey.
Searching the web found only one other website mentioning the problem. One, in the entire world. And their solution was basically to uninstall SQL Server, delete the remnants of the installation folder, and reinstall.
Well, thanks be to God, the answer dawned on me :
To save space on my SSD (where speed was brilliant but size was cramped), I had compressed all my program files.
That works a treat - program files are almost entirely read-only, so both with hard disks and with SSDs of all varieties, compressing program files usually brings a speed improvement, and certainly frees up a lot of disk space.
BUT, I suddenly recalled that SQL Server stores its "master databases" deep inside the Program Files. By itself, that's not a problem. But I also recalled from years ago that SQL Server uses a special type of low-level file system access that is incompatible with NTFS compression. The disk access used by SQL Server is designed to optimise database page caching for uncompressed data files. But it simply cannot work with NTFS-compressed data files. Full stop. (And there are ways to trick it into working, but believe you me, there are substantial write performance implications if you try.)
So I dug into the SQL Server installation folder, and uncompressed the *.mdf and *.ldf files in the Data folder, and all was merriment once more.
For the odd sailor out there cutting close to the wind like me, this might prove helpful. Enjoy! :o)
Sunday, April 11, 2010
The case of the waking laptop
My Sony Vaio Z - ah... bliss! This is a BRILLIANT laptop.
But it often wakes around 2am.
When on battery, it runs its battery down and starts hibernating.
But when its in my bag, the extra drain of running the fan at full speed in the bag (due to the heat in a closed bag) whilst it runs needlessly, means that the hibernation battery threshhold is not sufficient for a full hibernation to occur. (8GB of RAM takes a while to hibernate.)
Ergo, the battery drains, and I lose my software state and any unsaved work.
VERY frustrating, especially when it's supposedly the 21st century and all.
Windows 7 Ultimate 64-bit.
I thought it must be the fault of a Sony driver or something.
But previous attempts to resolve the problem have failed.
I've had the laptop nearly four months now, and this has been my major issue with it.
(Lots of people are mentioning very similar problems, and other websites do give answers that work for others, but didn't solve the problem in my case.)
I think I've found the solution at last :
Open : Task Scheduler
Expand : Task Scheduler Library
Expand : Microsoft
Expand : Windows
Select in the LHS tree : Media Center
Select in the RHS list : mcupdate_scheduled
Note that it defaults to 2am daily. 2am daily!
Right-click "mcupdate_scheduled" and select "Properties".
Go to the fourth tab, and find the checkbox named "Wake the computer to run this task".
It is checked.
Yes, can you believe it, checked.
This particular scheduled task just checks for software updates.
That's not very critical.
Some numbskull at Microsoft decided that Media Center software updates are so critical that your computer should be woken from sleep at 2am, EVERY DAY!!!
This explains another problem. Whilst I have the laptop docked, I get woken in the middle of the night with my screen turning on, as a result of the laptop turning on. That'll be why.
So hopefully I'll have fewer interrupted sleeps.
Anyhows, this particular scheduled task is set to only start when the computer is plugged into power - which is the case when it's docked and I get the laptop turning on and the screen turning on and waking me in the middle of the night - but it doesn't explain why it wakes at around 2am on battery.
... or does it?
Someone else commenting on a similar problem said they noticed that the Windows 7 final release had a bug related specifically to the "Balanced" power profile. Somehow or other, the bug didn't seem to affect the "Performance" power profile. And I happen to use the "Balanced" power profile nearly all the time.
So here's my suspicion : the stupid Media Center scheduled task was causing the laptop to wake at 2am daily, and even though the settings said it should only happen when plugged into power, I suspect a bug somewhere in the Balanced power profile resulted in this scheduled task waking the computer even when it was on battery.
But of course "the proof is in the pudding". I definitely have solved at least one problem, but whether it will prove to have solved the main problem, we're yet to see...
But it often wakes around 2am.
When on battery, it runs its battery down and starts hibernating.
But when its in my bag, the extra drain of running the fan at full speed in the bag (due to the heat in a closed bag) whilst it runs needlessly, means that the hibernation battery threshhold is not sufficient for a full hibernation to occur. (8GB of RAM takes a while to hibernate.)
Ergo, the battery drains, and I lose my software state and any unsaved work.
VERY frustrating, especially when it's supposedly the 21st century and all.
Windows 7 Ultimate 64-bit.
I thought it must be the fault of a Sony driver or something.
But previous attempts to resolve the problem have failed.
I've had the laptop nearly four months now, and this has been my major issue with it.
(Lots of people are mentioning very similar problems, and other websites do give answers that work for others, but didn't solve the problem in my case.)
I think I've found the solution at last :
Open : Task Scheduler
Expand : Task Scheduler Library
Expand : Microsoft
Expand : Windows
Select in the LHS tree : Media Center
Select in the RHS list : mcupdate_scheduled
Note that it defaults to 2am daily. 2am daily!
Right-click "mcupdate_scheduled" and select "Properties".
Go to the fourth tab, and find the checkbox named "Wake the computer to run this task".
It is checked.
Yes, can you believe it, checked.
This particular scheduled task just checks for software updates.
That's not very critical.
Some numbskull at Microsoft decided that Media Center software updates are so critical that your computer should be woken from sleep at 2am, EVERY DAY!!!
This explains another problem. Whilst I have the laptop docked, I get woken in the middle of the night with my screen turning on, as a result of the laptop turning on. That'll be why.
So hopefully I'll have fewer interrupted sleeps.
Anyhows, this particular scheduled task is set to only start when the computer is plugged into power - which is the case when it's docked and I get the laptop turning on and the screen turning on and waking me in the middle of the night - but it doesn't explain why it wakes at around 2am on battery.
... or does it?
Someone else commenting on a similar problem said they noticed that the Windows 7 final release had a bug related specifically to the "Balanced" power profile. Somehow or other, the bug didn't seem to affect the "Performance" power profile. And I happen to use the "Balanced" power profile nearly all the time.
So here's my suspicion : the stupid Media Center scheduled task was causing the laptop to wake at 2am daily, and even though the settings said it should only happen when plugged into power, I suspect a bug somewhere in the Balanced power profile resulted in this scheduled task waking the computer even when it was on battery.
But of course "the proof is in the pudding". I definitely have solved at least one problem, but whether it will prove to have solved the main problem, we're yet to see...
Wednesday, April 7, 2010
ebay iPhone buy-it-now issue
Are we the only ones in the world affected?
My wife was on her iPhone using the ebay app, scrolling through a listing, and all of a sudden she was told she had won the item via buy-it-now.
She did not see any buy-it-now confirmation request either.
It just happened.
The iPhone's design inherently means that scrolling requires touching parts of the page you are scrolling through, and from time to time this must inevitably mean the iPhone mistakes an attempted scroll for a click.
So designing an iPhone app in such manner that an attempted scroll can instantly become a multi-hundred-dollar buying commitment, is ridiculous.
I also suggest it is illegal - that any attempt to enforce the purchase at law would be void, due to the absence of a contract. (There was clearly no intention to enter into a contract, nor to represent an intention to enter into a contract - it was a case of poor app design.)
Now, I don't know ('coz I always use ebay in a browser on a larger computer), but it might be that ebay will turn around and claim that they always present a confirmation request for buy-it-now on the iPhone. For sure I cannot find any option to enable or disable such confirmations in the app's settings (nor even in my account settings when I log in using a browser - but the account settings are not very intuitive to me, so there is a chance I missed the relevant setting).
But if the ebay app DID present a confirmation request, it was deemed accepted and dismissed so quickly - probably in the same swipe that triggered the "buy it now" button in the first place - that my wife saw nothing.
One moment scrolling.
The next moment on the hook for hundreds of dollars for a product she was just investigating.
If ebay does not ask for confirmations for "buy it now" on the iPhone, then they are negligent.
If ebay DOES ask for confirmations for "buy it now" on the iPhone, then they are negligent once again by implementing the confirmation step in such manner as it can be so easily dismissed without even being seen. They should e.g. have it appear for at least a second with buttons disabled before enabling the buttons.
But in my attempts to find others with the same problem, and how they resolved it, my Google searching turned up nada, zip, zero. Are we the only people on the planet who have hit this snag?
I Googled for things like "ebay iPhone buy-it-now accident", "ebay buy-it-now mistake", and other combinations of words, but no, I'm not finding anyone reporting this particular problem. And of course the ebay help was useless on the topic.
Come to think of it, ebay and PayPal are bedfellows, and we had a run in with PayPal's incompetence a few years ago - still partially unresolved despite PayPal's repeated claims that they have completely remedied the problem.
So I guess it shouldn't surprise me at all if ebay too proves worse than useless in resolving the issue.
There is an ebay help article on canceling a sale for sellers who find themselves unable to complete the transaction, but nothing it seems for buyers.
And no mention of the possibility of unintentional buy-it-now activation, anywhere in the help (yet surely that must frequently occur).
And the "dispute resolution center" gives no useful options at least for the time being - it says we must wait 10 days before even contacting the dispute resolution center!
We've contacted the seller, explained the situation, and I even offered to cover his lost listing fees.
So now we're in a situation where, depending on the good graces of the seller, we might :
a) end up with merely a truckload of wasted time. Yeah, thanks ebay for facilitating that.
or
b) end up with even a bit more wasted time trying to pay whatever few dollars it turns out to be in compensation (when we were not at fault in the first place) to the seller who is as much a victim in the circumstances as we are - but we don't want ebay's negligence to spiral on and affect others, so we're willing to cover the lost listing fees, even though it is ebay's fault.
or
c) end up with a strong negative feedback with no good opportunity to defend ourselves (so much for due process) when we do very few ebay transactions, have fabulous feedback so far, and thus one strong negative would be a substantial (and unwarranted) mar on our ebay reputation.
So, we'll see how it turns out, but based on my interactions with PayPal, I'm doubting ebay will have any conscience in this regard.
My wife was on her iPhone using the ebay app, scrolling through a listing, and all of a sudden she was told she had won the item via buy-it-now.
She did not see any buy-it-now confirmation request either.
It just happened.
The iPhone's design inherently means that scrolling requires touching parts of the page you are scrolling through, and from time to time this must inevitably mean the iPhone mistakes an attempted scroll for a click.
So designing an iPhone app in such manner that an attempted scroll can instantly become a multi-hundred-dollar buying commitment, is ridiculous.
I also suggest it is illegal - that any attempt to enforce the purchase at law would be void, due to the absence of a contract. (There was clearly no intention to enter into a contract, nor to represent an intention to enter into a contract - it was a case of poor app design.)
Now, I don't know ('coz I always use ebay in a browser on a larger computer), but it might be that ebay will turn around and claim that they always present a confirmation request for buy-it-now on the iPhone. For sure I cannot find any option to enable or disable such confirmations in the app's settings (nor even in my account settings when I log in using a browser - but the account settings are not very intuitive to me, so there is a chance I missed the relevant setting).
But if the ebay app DID present a confirmation request, it was deemed accepted and dismissed so quickly - probably in the same swipe that triggered the "buy it now" button in the first place - that my wife saw nothing.
One moment scrolling.
The next moment on the hook for hundreds of dollars for a product she was just investigating.
If ebay does not ask for confirmations for "buy it now" on the iPhone, then they are negligent.
If ebay DOES ask for confirmations for "buy it now" on the iPhone, then they are negligent once again by implementing the confirmation step in such manner as it can be so easily dismissed without even being seen. They should e.g. have it appear for at least a second with buttons disabled before enabling the buttons.
But in my attempts to find others with the same problem, and how they resolved it, my Google searching turned up nada, zip, zero. Are we the only people on the planet who have hit this snag?
I Googled for things like "ebay iPhone buy-it-now accident", "ebay buy-it-now mistake", and other combinations of words, but no, I'm not finding anyone reporting this particular problem. And of course the ebay help was useless on the topic.
Come to think of it, ebay and PayPal are bedfellows, and we had a run in with PayPal's incompetence a few years ago - still partially unresolved despite PayPal's repeated claims that they have completely remedied the problem.
So I guess it shouldn't surprise me at all if ebay too proves worse than useless in resolving the issue.
There is an ebay help article on canceling a sale for sellers who find themselves unable to complete the transaction, but nothing it seems for buyers.
And no mention of the possibility of unintentional buy-it-now activation, anywhere in the help (yet surely that must frequently occur).
And the "dispute resolution center" gives no useful options at least for the time being - it says we must wait 10 days before even contacting the dispute resolution center!
We've contacted the seller, explained the situation, and I even offered to cover his lost listing fees.
So now we're in a situation where, depending on the good graces of the seller, we might :
a) end up with merely a truckload of wasted time. Yeah, thanks ebay for facilitating that.
or
b) end up with even a bit more wasted time trying to pay whatever few dollars it turns out to be in compensation (when we were not at fault in the first place) to the seller who is as much a victim in the circumstances as we are - but we don't want ebay's negligence to spiral on and affect others, so we're willing to cover the lost listing fees, even though it is ebay's fault.
or
c) end up with a strong negative feedback with no good opportunity to defend ourselves (so much for due process) when we do very few ebay transactions, have fabulous feedback so far, and thus one strong negative would be a substantial (and unwarranted) mar on our ebay reputation.
So, we'll see how it turns out, but based on my interactions with PayPal, I'm doubting ebay will have any conscience in this regard.
Wednesday, March 31, 2010
You gotta turn, bro! iPhone hip GPS
The iPhone's built-in GPS (via Google Maps) is very helpful. Not perfect, but definitely very helpful.
So we use it a lot.
It pulled a fast one on us this morning though, causing me much amusement.
"Hang a right". Are you serious? The iPhone - so well spoken - now speaks hip?
"Keep goin' on ..." Goin'? Golly goodness! It's turned Texan! :o)
Or this one :
"ya gotta take the turn off onta ..."
Holey moley! My iPhone has truly become trendy! I don't mean it's trendy to have an iPhone, I mean the iPhone itself has trendiness of its own!!! :o)
So, kudos to whoever in Google or Apple gave me this amusement this morning - well done. :o)
So we use it a lot.
It pulled a fast one on us this morning though, causing me much amusement.
"Hang a right". Are you serious? The iPhone - so well spoken - now speaks hip?
"Keep goin' on ..." Goin'? Golly goodness! It's turned Texan! :o)
Or this one :
"ya gotta take the turn off onta ..."
Holey moley! My iPhone has truly become trendy! I don't mean it's trendy to have an iPhone, I mean the iPhone itself has trendiness of its own!!! :o)
So, kudos to whoever in Google or Apple gave me this amusement this morning - well done. :o)
Thursday, February 18, 2010
Engin voicebox (Sipura SPA 3102) sharing WiFi via LAN cable to Windows 7 laptop
My laptop has wireless and LAN. I only need the wireless.
My Engin 3102 voicebox (a re-badged Sipura SPA something-or-other) has LAN, but not wireless.
What if I want to run my VoIP over wireless?
OK, ok, if you can, it's simplest to just plug the voicebox directly into your broadband router.
But what if, for whatever reason, you can't, or don't want to?
Turns out, it is possible to plug the voicebox into the laptop via the LAN port, and have the voicebox piggy-back on the laptop's WiFi connection.
You beauty!
Apparently in Windows XP you can do it through Internet Connection Sharing.
I have Windows 7 Ultimate, and whilst I enabled Internet Connection Sharing, I never managed to get the voicebox to work through the laptop that way.
After more digging, I discovered that bridging network connections was the trick I needed.
Open Control Panel, go to Network And Sharing Center, then on the left-hand-side, choose the "Change adapter settings" option.
This will list all of your network adapters, including your LAN and WiFi adapters.
Select both (click on one, then ctrl-click the other), then right-click on either of the selected two and a menu gives an option to bridge the adapters.
Voila! It was that easy!
However, apparently if you have previously enabled Internet Connection Sharing, you'll need to disable it first - apparently it is incompatible with bridged network adapters.
So now I can have my voicebox and phone handset right near my laptop, up the other end of the house, far away from the router and without running cables through the house.
Nice.
My Engin 3102 voicebox (a re-badged Sipura SPA something-or-other) has LAN, but not wireless.
What if I want to run my VoIP over wireless?
OK, ok, if you can, it's simplest to just plug the voicebox directly into your broadband router.
But what if, for whatever reason, you can't, or don't want to?
Turns out, it is possible to plug the voicebox into the laptop via the LAN port, and have the voicebox piggy-back on the laptop's WiFi connection.
You beauty!
Apparently in Windows XP you can do it through Internet Connection Sharing.
I have Windows 7 Ultimate, and whilst I enabled Internet Connection Sharing, I never managed to get the voicebox to work through the laptop that way.
After more digging, I discovered that bridging network connections was the trick I needed.
Open Control Panel, go to Network And Sharing Center, then on the left-hand-side, choose the "Change adapter settings" option.
This will list all of your network adapters, including your LAN and WiFi adapters.
Select both (click on one, then ctrl-click the other), then right-click on either of the selected two and a menu gives an option to bridge the adapters.
Voila! It was that easy!
However, apparently if you have previously enabled Internet Connection Sharing, you'll need to disable it first - apparently it is incompatible with bridged network adapters.
So now I can have my voicebox and phone handset right near my laptop, up the other end of the house, far away from the router and without running cables through the house.
Nice.
What's the (Google) Buzz?
What's the buzz with the Buzz? Buzz off, Buzz, I'm too busy!
OK, I grant it's cool how it pulls in data from so many sources. But still, what, am I supposed to click in to the Buzz several times a day, and scroll through a long list of buzzes, looking for ones that have been updated?
No thanks.
OK, I grant it's cool how it pulls in data from so many sources. But still, what, am I supposed to click in to the Buzz several times a day, and scroll through a long list of buzzes, looking for ones that have been updated?
No thanks.
Sunday, February 7, 2010
Secure data removal when disposing of a PC
So my laptop (er, craptop) Toshiba Tecra A6 is at end-of-life, and I'm getting rid of it.
Of course, the hard disk is laden with commercial-in-confidence data, so what do I do?
Short answer : Eraser! Open-source, and it provides well over a dozen secure data removal options, including deleting specific files, 'wiping' disk free space, etc.
How did I use? I deleted all my files off the laptop, created a new Administrator user account and deleted my old user account, and then I used Eraser to ensure all that juicy data I just deleted can't be retrieved.
Nice. I'm a fan. Get it here.
Of course, the hard disk is laden with commercial-in-confidence data, so what do I do?
Short answer : Eraser! Open-source, and it provides well over a dozen secure data removal options, including deleting specific files, 'wiping' disk free space, etc.
How did I use? I deleted all my files off the laptop, created a new Administrator user account and deleted my old user account, and then I used Eraser to ensure all that juicy data I just deleted can't be retrieved.
Nice. I'm a fan. Get it here.
Tuesday, February 2, 2010
Merging WPF assemblies
Life can be unnecessarily complex, especially if you work with technology!
WPF is great. One of the ten best things Microsoft has ever done. (Er - not that they haven't also done loads of terrible things, but that's another story.)
Unfortunately, WPF windows and user controls are compiled into BAML, every time you rebuild your application, and the compile-to-BAML process is not very efficient.
I have, hmmm, probably 50 to 100 WPF windows and user controls in a particular project, and on a 3.2ghz CPU, app build time is around 12 seconds. And that's with heaps of RAM, the superb Intel X25-M SSD, and other speed features.
Compile the project without WPF windows and user controls, and it takes more like a second.
In other words, compilation to BAML is just plain slow.
Yet every time you change anything in the project's source code - regardless of whether or not you actually modified any XAML files or associated code-behind files - the BAML files are regenerated.
With C#, those BAML files are (it seems) regenerated just when you rebuild the project - which wastes some time.
But with VB.NET, those BAML files are constantly being regenerated as the VB.NET IDE performs ongoing recompilations of the entire project for Intellisense purposes.
This means that, working on a large VB.NET project with lots of XAML windows and user controls, you can face an unresponsive IDE several times a minute as it constantly compiles and recompiles and re-re-compiles, taking more than 10 seconds every time.
Slow, slow, slow, slow, slow, slow.
And for those of us who are into rapid testing and release cycles, slow builds are productivity killers.
So I refactored the solution, putting the windows and user controls in a WPF DLL, leaving most of the application logic in the main project (the WPF EXE that already existed).
There were a few tricks to getting that to work, but now build time is slashed. Unless I actually modify a window or user control in that DLL, the DLL is not rebuilt, and so I save roughly 10 seconds each time. And if you're making a series of minor tweaks and re-running, as is typical during testing cycles, that can easily translate into a 10% to 30% reduction in time spent by the developer. THAT'S good!
Of course, whatever XAML window or user control I happen to be working on at the time, I leave in the main WPF EXE, and only transfer it into the WPF DLL once I've tested it, and the usual flood of change requests for the new screen have died down.
That way, I'm rarely modifying the WPF DLL, and so I'm rarely copping the full 12-ish second build time - sufficiently rarely that the slowness of the full build is largely irrelevant.
All good and well ...
... and I highly recommend it if you need the speed boost ...
... BUT, things fall apart if you try to use a tool that merges assemblies.
I spent hours today digging around, and this is what I found out :
All of the XAML windows and user controls that have "Build Action" set to "Page" (which is the default), are compiled into a single assembly manifest resource named {AssemblyNameMinusFilenameExtension}.g.resources (e.g. MyApp.g.resources).
Within that one assembly manifest resource is a bunch of BAML items, one for each window or user control.
Now, if you change the name of the assembly manifest resource, WPF can no longer locate the BAML files.
So let's for example say you have two assemblies : MyWpfExe and MyWpfDll.
MyWpfExe.exe contains an assembly manifest resource named MyWpfExe.g.resources.
MyWpfDll.dll contains an assembly manifest resource named MyWpfDll.g.resources.
Problem is, if you merge the assemblies together, these two assembly manifest resources do not get merged, and because WPF will ONLY look for assembly manifest resources that match the assembly name, one of the assembly manifest resources (and all associated windows and user controls) will be ignored.
e.g. MyMergedWpfExe.exe contains two assembly manifest resources :
MyWpfExe.g.resources
MyWpfDll.g.resources
... but WPF will only look for one, matching the assembly name. i.e. the MyWpfDll.g.resources will be completely ignored.
Obvious solution? Well, somehow merge the two assembly manifest resources into one. But no easy cigar. I expect it can be done. I'll leave that as an exercise to the reader, if they care. (I found no existing tools that do the job, so it would probably require someone to write a tool especially for this purpose.)
I ended up finding a way that didn't require me to write a special tool. It's cumbersome, it's "clunky", but it does work, and it meets my immediate needs, and I can always improve it later.
So here goes (and warning : it is very technical!) :
There are two parts to my trick.
Part 1) Trick WPF into loading TWO DIFFERENT assembly manifest resources, from the SAME assembly, BOTH of which will be fully consulted when loading windows and user controls. The heart of this trick is to rename one of the assembly manifest resources to include the "en-US" culture. Unfortunately, this trick can only work if there are ONLY two assemblies with BAML stuff being merged, and it gets tricky if you are using localisation for other purposes (although you can still do it). (More details below.)
Part 2) The compiled BAML contains a link to the original assembly name, and of course, post-merging, the original assembly ain't anywhere to be found. So, ridiculous as it might seem, you actually need to temporarily produce a version of the DLL that has the same assembly name as the EXE. (More details below.)
So, step by step, it goes something like this :
Step 1) Alter MyWpfDll.dll's project settings so that its Assembly Name matches the exe's Assembly Name (MyWpfExe).
Step 2) Build just the DLL (MyWpfExe.dll, due to the rename in step #1).
Step 2) Open MyWpfExe.dll in Lutz Roeder's Reflector.
Step 3) Drill down through the tree view until you find the resource named MyWpfExe.g.resources. Right-click it and save it somewhere - e.g. C:\MyWpfExe.g.resources.
Step 4) Revert the name change from step #1. (i.e. reconfigure the MyWpfDll project to use MyWpfDll as its assembly name again instead of MyWpfExe.)
Step 5) Rename MyWpfExe.g.resources to MyWpfExe.g.en-US.resources.
Step 6) "Add existing file" to the MyWpfExe project, and choose MyWpfExe.g.en-US.resources.
Step 7) Ensure that MyWpfExe.g.en-US.resources has Build Action set to "Embedded Resource" (which is the default at least on my computer, so that SHOULD already be fine).
Step 8) Build the "solution" (MyWpfExe.exe and MyWpfDll.dll).
Step 9) Merge assemblies.
Voila! That was very painful and cumbersome, but you now have two WPF assemblies merged together, in a manner that all of the BAML from both assemblies is still accessible.
Alternatives :
* Of course, one option since you have full source code for both projects, is to make a project file that combines all source files into one mega project. Only use that project file when doing your release build. Not ideal, but an option, especially if you can find or make a tool that will automatically combine two VS.NET projects into a single project. (And hey - if you can find or make such a tool, it'll probably be less un-ideal than what I've presently settled for! It's just, when I finally found something that met my immediate purposes, I decided to not waste any further time refining it for the moment.)
WPF is great. One of the ten best things Microsoft has ever done. (Er - not that they haven't also done loads of terrible things, but that's another story.)
Unfortunately, WPF windows and user controls are compiled into BAML, every time you rebuild your application, and the compile-to-BAML process is not very efficient.
I have, hmmm, probably 50 to 100 WPF windows and user controls in a particular project, and on a 3.2ghz CPU, app build time is around 12 seconds. And that's with heaps of RAM, the superb Intel X25-M SSD, and other speed features.
Compile the project without WPF windows and user controls, and it takes more like a second.
In other words, compilation to BAML is just plain slow.
Yet every time you change anything in the project's source code - regardless of whether or not you actually modified any XAML files or associated code-behind files - the BAML files are regenerated.
With C#, those BAML files are (it seems) regenerated just when you rebuild the project - which wastes some time.
But with VB.NET, those BAML files are constantly being regenerated as the VB.NET IDE performs ongoing recompilations of the entire project for Intellisense purposes.
This means that, working on a large VB.NET project with lots of XAML windows and user controls, you can face an unresponsive IDE several times a minute as it constantly compiles and recompiles and re-re-compiles, taking more than 10 seconds every time.
Slow, slow, slow, slow, slow, slow.
And for those of us who are into rapid testing and release cycles, slow builds are productivity killers.
So I refactored the solution, putting the windows and user controls in a WPF DLL, leaving most of the application logic in the main project (the WPF EXE that already existed).
There were a few tricks to getting that to work, but now build time is slashed. Unless I actually modify a window or user control in that DLL, the DLL is not rebuilt, and so I save roughly 10 seconds each time. And if you're making a series of minor tweaks and re-running, as is typical during testing cycles, that can easily translate into a 10% to 30% reduction in time spent by the developer. THAT'S good!
Of course, whatever XAML window or user control I happen to be working on at the time, I leave in the main WPF EXE, and only transfer it into the WPF DLL once I've tested it, and the usual flood of change requests for the new screen have died down.
That way, I'm rarely modifying the WPF DLL, and so I'm rarely copping the full 12-ish second build time - sufficiently rarely that the slowness of the full build is largely irrelevant.
All good and well ...
... and I highly recommend it if you need the speed boost ...
... BUT, things fall apart if you try to use a tool that merges assemblies.
I spent hours today digging around, and this is what I found out :
All of the XAML windows and user controls that have "Build Action" set to "Page" (which is the default), are compiled into a single assembly manifest resource named {AssemblyNameMinusFilenameExtension}.g.resources (e.g. MyApp.g.resources).
Within that one assembly manifest resource is a bunch of BAML items, one for each window or user control.
Now, if you change the name of the assembly manifest resource, WPF can no longer locate the BAML files.
So let's for example say you have two assemblies : MyWpfExe and MyWpfDll.
MyWpfExe.exe contains an assembly manifest resource named MyWpfExe.g.resources.
MyWpfDll.dll contains an assembly manifest resource named MyWpfDll.g.resources.
Problem is, if you merge the assemblies together, these two assembly manifest resources do not get merged, and because WPF will ONLY look for assembly manifest resources that match the assembly name, one of the assembly manifest resources (and all associated windows and user controls) will be ignored.
e.g. MyMergedWpfExe.exe contains two assembly manifest resources :
MyWpfExe.g.resources
MyWpfDll.g.resources
... but WPF will only look for one, matching the assembly name. i.e. the MyWpfDll.g.resources will be completely ignored.
Obvious solution? Well, somehow merge the two assembly manifest resources into one. But no easy cigar. I expect it can be done. I'll leave that as an exercise to the reader, if they care. (I found no existing tools that do the job, so it would probably require someone to write a tool especially for this purpose.)
I ended up finding a way that didn't require me to write a special tool. It's cumbersome, it's "clunky", but it does work, and it meets my immediate needs, and I can always improve it later.
So here goes (and warning : it is very technical!) :
There are two parts to my trick.
Part 1) Trick WPF into loading TWO DIFFERENT assembly manifest resources, from the SAME assembly, BOTH of which will be fully consulted when loading windows and user controls. The heart of this trick is to rename one of the assembly manifest resources to include the "en-US" culture. Unfortunately, this trick can only work if there are ONLY two assemblies with BAML stuff being merged, and it gets tricky if you are using localisation for other purposes (although you can still do it). (More details below.)
Part 2) The compiled BAML contains a link to the original assembly name, and of course, post-merging, the original assembly ain't anywhere to be found. So, ridiculous as it might seem, you actually need to temporarily produce a version of the DLL that has the same assembly name as the EXE. (More details below.)
So, step by step, it goes something like this :
Step 1) Alter MyWpfDll.dll's project settings so that its Assembly Name matches the exe's Assembly Name (MyWpfExe).
Step 2) Build just the DLL (MyWpfExe.dll, due to the rename in step #1).
Step 2) Open MyWpfExe.dll in Lutz Roeder's Reflector.
Step 3) Drill down through the tree view until you find the resource named MyWpfExe.g.resources. Right-click it and save it somewhere - e.g. C:\MyWpfExe.g.resources.
Step 4) Revert the name change from step #1. (i.e. reconfigure the MyWpfDll project to use MyWpfDll as its assembly name again instead of MyWpfExe.)
Step 5) Rename MyWpfExe.g.resources to MyWpfExe.g.en-US.resources.
Step 6) "Add existing file" to the MyWpfExe project, and choose MyWpfExe.g.en-US.resources.
Step 7) Ensure that MyWpfExe.g.en-US.resources has Build Action set to "Embedded Resource" (which is the default at least on my computer, so that SHOULD already be fine).
Step 8) Build the "solution" (MyWpfExe.exe and MyWpfDll.dll).
Step 9) Merge assemblies.
Voila! That was very painful and cumbersome, but you now have two WPF assemblies merged together, in a manner that all of the BAML from both assemblies is still accessible.
Alternatives :
* Of course, one option since you have full source code for both projects, is to make a project file that combines all source files into one mega project. Only use that project file when doing your release build. Not ideal, but an option, especially if you can find or make a tool that will automatically combine two VS.NET projects into a single project. (And hey - if you can find or make such a tool, it'll probably be less un-ideal than what I've presently settled for! It's just, when I finally found something that met my immediate purposes, I decided to not waste any further time refining it for the moment.)
Tuesday, January 26, 2010
PLINQO : Data caching for the masses
The single biggest way to improve the speed of a database app is to cache data in memory, cutting-down on round-trips to remote servers.
But caching usually requires tedious hand-coding.
Apparently not-so any more.
I haven't checked it out yet, but CodeSmith claims their new PLINQO technology has built-in data caching mechanisms. That sounds like a very easy way to get substantial speed improvements in one's app!
It works in concert with LINQ to SQL.
In short, it's an entity framework that purportedly makes data caching easy. Exactly how easy? I haven't played with it yet, so I can't comment.
Switching frameworks is obviously a big effort, and I'm reasonably satisfied with the frameworks I'm already using, but this data-caching feature of PLINQO is enough to intrigue me - I think I might check it out.
But caching usually requires tedious hand-coding.
Apparently not-so any more.
I haven't checked it out yet, but CodeSmith claims their new PLINQO technology has built-in data caching mechanisms. That sounds like a very easy way to get substantial speed improvements in one's app!
It works in concert with LINQ to SQL.
In short, it's an entity framework that purportedly makes data caching easy. Exactly how easy? I haven't played with it yet, so I can't comment.
Switching frameworks is obviously a big effort, and I'm reasonably satisfied with the frameworks I'm already using, but this data-caching feature of PLINQO is enough to intrigue me - I think I might check it out.
Thursday, January 21, 2010
LogMeIn : Remote Mac screen sharing to Windows
A client has a Mac that I frequently need to log into remotely.
It's a brand-new Mac Mini, running Snow Leopard.
Getting the built-in VNC server to work with a Windows client was a very major pain.
Most VNC viewers simply refused to connect at all.
I did eventually find one Windows-based VNC viewer that would connect to the "Screen Sharing" on the Mac.
But lo-and-behold, the Screen Sharing service would frequently freeze up and stop accepting new connections, and I would need to call the client and get someone to physically disable and re-enable the Screen Sharing service to resolve the problem.
Further, the VNC connection would usually drop out after just a few minutes of inactivity, meaning I was constantly closing the VNC viewer and restarting it.
All in all, it was like doing a forced march on a broken leg.
Ouch.
So I went a huntin' for other options.
Must share a Mac's screen to a Windows client.
Preferrably free, although I would willing pay up to a few tens of dollars.
The only options I found wanted around $100 per year. That's not scalable. What if I picked up another client with a Mac needing similar remote support? That'd be another $100 per year per Mac being supported. Worth it for some, but not worth it in my particular case.
Then I found LogMeIn.
I tried it.
The Free edition supports screen sharing exactly like I want.
The Pro (non-free) edition has extra cool features like a "whiteboard" mode where the viewer can 'draw' on the screen, and both the person on the Mac, and the viewer on his remote PC, can see the drawing.
The Free version, it turns out, comes with time-limited access to the Pro features.
Smart move on LogMeIn's part.
I was experimenting with all these cool features, and then the Mac died the death.
My client told me that not only was I unable to connect, but they found the Mac in some unusable state and had to reboot it.
Hmmm.
Et tu, LogMeIn?
After such a surge of hope when LogMeIn initially worked, I was feeling very disappointed.
A web search turned up an odd clue : someone recommended running LogMeIn in 32-bit mode.
I'm not a Mac man, and I don't know how to enable "32-bit" mode for an app.
But I did manage to find a "Rosetta" mode for LogMeIn.
After enabling "Rosetta" mode for LogMeIn (right-click the Start LogMeIn app, and the option is in there somewhere), and studiously avoiding the fancy whiteboard and other tools (just in case they were to blame), LogMeIn now works WONDERFULLY for me. WONDERFULLY.
I can actually have a reliable, unbroken remote desktop session from a Windows box to a Mac box, any time of day or night!
It's like humanity finally arrived in the 21st century!
So, kudos to LogMeIn.
And if you give it a try and the Mac dies the death, then the solution is one or both of : Use Rosetta mode, and/or don't use those delicious tempting "Pro" tools.
I could experiment more and figure out exactly which of those two variables made the difference, but time is so short I could hardly justify writing this note, let alone doing another half hour or hour of experiments, so sorry - hopefully this article will at least help some other wandering soul out there on the road to PC-Mac blissdom. :o)
It's a brand-new Mac Mini, running Snow Leopard.
Getting the built-in VNC server to work with a Windows client was a very major pain.
Most VNC viewers simply refused to connect at all.
I did eventually find one Windows-based VNC viewer that would connect to the "Screen Sharing" on the Mac.
But lo-and-behold, the Screen Sharing service would frequently freeze up and stop accepting new connections, and I would need to call the client and get someone to physically disable and re-enable the Screen Sharing service to resolve the problem.
Further, the VNC connection would usually drop out after just a few minutes of inactivity, meaning I was constantly closing the VNC viewer and restarting it.
All in all, it was like doing a forced march on a broken leg.
Ouch.
So I went a huntin' for other options.
Must share a Mac's screen to a Windows client.
Preferrably free, although I would willing pay up to a few tens of dollars.
The only options I found wanted around $100 per year. That's not scalable. What if I picked up another client with a Mac needing similar remote support? That'd be another $100 per year per Mac being supported. Worth it for some, but not worth it in my particular case.
Then I found LogMeIn.
I tried it.
The Free edition supports screen sharing exactly like I want.
The Pro (non-free) edition has extra cool features like a "whiteboard" mode where the viewer can 'draw' on the screen, and both the person on the Mac, and the viewer on his remote PC, can see the drawing.
The Free version, it turns out, comes with time-limited access to the Pro features.
Smart move on LogMeIn's part.
I was experimenting with all these cool features, and then the Mac died the death.
My client told me that not only was I unable to connect, but they found the Mac in some unusable state and had to reboot it.
Hmmm.
Et tu, LogMeIn?
After such a surge of hope when LogMeIn initially worked, I was feeling very disappointed.
A web search turned up an odd clue : someone recommended running LogMeIn in 32-bit mode.
I'm not a Mac man, and I don't know how to enable "32-bit" mode for an app.
But I did manage to find a "Rosetta" mode for LogMeIn.
After enabling "Rosetta" mode for LogMeIn (right-click the Start LogMeIn app, and the option is in there somewhere), and studiously avoiding the fancy whiteboard and other tools (just in case they were to blame), LogMeIn now works WONDERFULLY for me. WONDERFULLY.
I can actually have a reliable, unbroken remote desktop session from a Windows box to a Mac box, any time of day or night!
It's like humanity finally arrived in the 21st century!
So, kudos to LogMeIn.
And if you give it a try and the Mac dies the death, then the solution is one or both of : Use Rosetta mode, and/or don't use those delicious tempting "Pro" tools.
I could experiment more and figure out exactly which of those two variables made the difference, but time is so short I could hardly justify writing this note, let alone doing another half hour or hour of experiments, so sorry - hopefully this article will at least help some other wandering soul out there on the road to PC-Mac blissdom. :o)
Subscribe to:
Posts (Atom)