# from David Golden
# on Saturday 02 July 2011 03:51:
>On Fri, Jul 1, 2011 at 9:23 AM, David Cantrell wrote:
>> ... the complete lack of a reasonable set of
>> tools* on Windows, which just makes me angry whenever I have to
>> touch the blasted thing, made me stop.
>>
>> * starting with a useable shell and editor, documentation, and
>> remote text-based access. ...
>
>Definitely the lack of remote text based access makes it harder. But
>for anyone willing to run Windows in a virtual machine, it's not
>terribly hard anymore. Personally, I use VirtualBox on Ubuntu with a
>Windows 7 guest. I suggest WinXP if you have old licenses kicking
>around, as it's a little less annoying about validation and such.
With a VM install, you still have to wade through the boggy experience
of mousing-around in a completely foreign environment while swearing at
the shell for being completely unreasonable about everything. But none
of this has anything to do with whether your code works on Windows,
only whether you can work within it. IMO, it would be much better to
not be actually using windows (or mac for that matter) if that's not
your preferred environment and you just need to debug some
compatibility issue.
Not to mention the general case of a CPAN author, where you can't assume
that they could be bothered to *obtain* a windows/mac OS, let alone
boot it. Some open and deployable environment / test kit would go much
further than anything involving a VM and proprietary license. I think
the utter lack of convenience in testing for and fixing cross-OS bugs
is the big barrier to getting better cross-OS support. Nobody likes
coding in the dark with a hours-long latency to see if their fix works.
I had no luck getting things to build under wine (IIRC, the trouble came
with XS modules), but it's been a few years and I haven't messed with
it lately. If it did work well, I'm not sure how much it would gloss
over issues of command-not-found and backslashed-path errors.
It seems like you could construct a pretty thoroughly windowsish
environment by hiding all useful commands (e.g. rename /bin,/usr/bin)
and unsetting $PATH, then make some working/temp directories with
spaces in the names. That would catch most of the common problems.
Not sure if you could emulate the brokenness of the backslashes on a
*nix though.
--Eric
--
Peer's Law: The solution to the problem changes the problem.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
