Low Level Audio - Writing bytes to the sound card?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: binding to C libraries on Windoww

Maurí­cio CA
 > I guess there's a difference in culture here.
 >
 > On Unix, it is usual to distribute programs as source, and build
 > from source.

I see more than a cultural issue here.

Suppose you write bindings to somelib-1.0.2, and release it with
somelib-1.0.2. Then, somelib-1.0.3 is released to solve a serious
security issue with 1.0.2. Linux or unix distributions will update
their repositories, but users of your bindings will blindly keep
using 1.0.2.

Best,
Maurício

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: binding to C libraries on Windoww

Jeffrey Scofield
In reply to this post by Andrew Coppin
Andrew Coppin <[hidden email]> writes:

> I guess there's a difference in culture here.
>
> On Unix, it is usual to distribute programs as source, and build from
> source. (I guess in part because each one of the 12,657,234 different
> Unix variants is slightly different, and the program needs to work
> differently.)
>
> On Windows, it is usual to distribute everything as compiled
> binaries.

I think the real cultural difference is that you aren't a user, you're
a prospective Haskell developer, as others have said.  Developers
pretty much have to install tools (like compilers and preprocessors)
and have to work with source code.

Traditionally, Unix *comes with* thousands of tools that are useful
to developers.  Windows traditionally came with none, at least
none that I was ever able to find.

Since many of the traditional Unix tools are available free, it
makes sense that somebody would want to port them to Windows
*for doing development*.  It's not so much a Unix emulation as
a solution to the lack of native Windows tools.  Of course this
makes sense especially to somebody who has gotten used to
the Unix tools (such as myself).  I would never try to *develop*
seriously under Windows using just what comes preinstalled.

Users of Unix (not developers) are just as used to getting
compiled binaries as users of Windows.  A good example of
this in today's world is Mac OS X (or the iPhone, which is
a small Unix system in essence).  In earlier times, I assure
you that users of Solaris (say) didn't expect to get a source
release of Oracle and compile it up from scratch.  There
were indeed a few different supported versions of Solaris
(different releases and hardware platforms), but this was
Sun's and/or Oracle's problem.

The open source movement has complicated this picture
(mostly for the good, from the user's standpoint), but this
just makes more people into developers in essence.  This
is the price you pay for getting stuff for free.  It seems to
me it doesn't make a lot of sense to complain about this.
If you don't want to be a developer you can usually find
something to buy that will be precompiled for you, or
you can hire somebody.

This is not to say that on a given day it isn't frustrating
when you can't get something to compile, especially
if it's just a tool you need to compile something else.
But this is why developers are so wealthy, they have the
fortitude to work through these problems.  (Ha ha.)

Regards,

Jeff Scofield
Seattle

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: binding to C libraries on Windoww

John Lato-2
In reply to this post by Andrew Coppin
To reply to an earlier point of Andrew's (I can't find the quote now,
sorry), one of the biggest difficulties developers face on Windows is
the lack of common install locations/practices.  Windows software is
usually distributed as a binary, which may or may not include header
files.  These files may be installed in any of numerous locations,
such as C:\Program Files\, the user's home directory, the system
directory, or directly off the drive root.  Defaults are not common
among different programs or even versions of programs, and install
locations are frequently changed by users anyway.  Libraries and
headers are usually not located on the PATH environment variable, and
there's no standard INCDIR or LIBDIR variable either.

While it is Cabal's job to find the location of necessary libraries,
header files, and tools, there simply is no feasible way to do so on
Windows without searching most of the hard drive.  Even then, there's
no guarantee the right version will be found (google "DLL Hell" for
examples of the chaos that ensues).  This is particularly true for
developers, who frequently have multiple versions of libraries
installed.  The only workable approach is to have users specify the
locations of these files, which unfortunately requires more
sophistication than can be expected of most Windows users (and even
some Windows developers).

On a related matter, many packagers resort to using configure-style
configuration setups to assist with binding to C libraries.  Cabal is
now sophisticated enough to handle many of these steps (although not
all), however packagers may not have had an opportunity to update
their build process to remove the dependency on "configure".  These
packages will continue to require cygwin or mingw for the "configure"
step.

One last wrinkle: many distributors of C libraries do not have Windows
machines available to test, and (understandably) have little interest
in supporting a platform they don't have and aren't familiar with.  As
a result, many C libraries are not well supported on Windows and
require somebody familiar with gnu build tools (i.e. gcc, make, and
autoconf) to be usable on Windows *at all*.  This means that, as a
Haskell developer wanting to use these libs, you need to use gnu build
tools because you're not just binding to the library, you're
maintaining a Windows port of it.

C and unix are pretty much designed to work together, and have been
for decades, so I think it's reasonable to expect that Windows is the
side that needs to adapt to support their model.  MS hasn't done so,
which means that C developers would need to unacceptably compromise
unix support in their packages in order to better support Windows.
Cross-platform support precludes windows-native solutions, so you're
left making the best of it with Linux tools (mingw and cygwin) on
Windows.

John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: binding to C libraries on Windoww

Maurí­cio CA
 > To reply to an earlier point of Andrew's (I can't find the quote
 > now, sorry), one of the biggest difficulties developers face
 > on Windows is the lack of common install locations/practices.
 > Windows software is usually distributed as a binary, which may
 > or may not include header files. These files may be installed
 > in any of numerous locations, such as C:\Program Files\, the
 > user's home directory, the system directory, or directly off the
 > drive root. Defaults are not common among different programs or
 > even versions of programs, and install locations are frequently
 > changed by users anyway. Libraries and headers are usually
 > not located on the PATH environment variable, and there's no
 > standard INCDIR or LIBDIR variable either.

If Windows lacks a sane environment, why not to provide one? I
don't know how much of it mingw already provides. If it doesn't,
that would be a nice Haskell project :) It could be called Windows
SaneEnvironment, and include a few basic policies for packages and
a package manager.

When I needed Windows myself I would certainly help maintaining.
It would not be hard to find others who still will.

Maurício

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windoww

Andrew Coppin
In reply to this post by Jeffrey Scofield
Jeffrey Scofield wrote:
> I think the real cultural difference is that you aren't a user, you're
> a prospective Haskell developer, as others have said.  Developers
> pretty much have to install tools (like compilers and preprocessors)
> and have to work with source code.
>  

And I have no problem with needing to install a Haskell compiler. If I
had to install a seperate C compiler to make FFI to C work, that
wouldn't seem unreasonable either. (As it happens, GHC has a C backend,
so the C compiler just happens to be there already.) What does seem very
weird is having to turn my Windows box into a psuedo-Unix system in
order to write native Windows programs.

> Traditionally, Unix *comes with* thousands of tools that are useful
> to developers.  Windows traditionally came with none, at least
> none that I was ever able to find.
>  

True. By default, Windows assumes you are a clueless user, not an expert
developer.

> Since many of the traditional Unix tools are available free, it
> makes sense that somebody would want to port them to Windows
> *for doing development*.  It's not so much a Unix emulation as
> a solution to the lack of native Windows tools.  Of course this
> makes sense especially to somebody who has gotten used to
> the Unix tools (such as myself).  I would never try to *develop*
> seriously under Windows using just what comes preinstalled.
>  

You can't develop anything with just what's preinstalled. (Well, unless
you could writing batch scripts...)

Generally, if you want to develop C or C++ applications on Windows, you
install MS Visual Studio. It gives you the compiler, linker, dependency
management, and a whole bunch of other stuff. You typically wouldn't
install gcc, ld and Automake. (Unless of course you were specifically
trying to port existing Unix code, obviously.)

The thing is, if you're a C programmer on Windows, and you want to write
(say) a program that talks to an Oracle database, typically what you'd
do is install Visual Studio, download the Net8 client DLLs and header
files, compile your application against the Net8 client header files,
link everything, and when your program runs, it dynamically loads the
Net8 DLLs and does its work. But it seems that if I want to talk to
Oracle from Haskell, I'm expected to find the *source code* to the Net8
client and *compile it from source*. This is highly unusual for Windows.
(I wouldn't be surprised if Oracle haven't even released the source code
for their Net8 libraries...) It just isn't the way Windows usually works.

Even without VS, if I'm working in C, all I really need is a compiler
and a linker, and I can build an executable program that talks to
Oracle. But with Haskell, it seems I need to be able to actually build
the Net8 client from source - which, depending on how those sources are
written, is likely to require an entire build system (Automake, a VS
project, whatever). It's a much bigger undertaking than just compiling
the few source file I personally wrote and linking a few bits together.

> This is not to say that on a given day it isn't frustrating
> when you can't get something to compile, especially
> if it's just a tool you need to compile something else.
>  

Oh, hey, I understand why things are like this. You make something work
properly on Linux, and with not that much effort you can make it also
work for BSD, Mac OS, Solaris, HP UX... even certain embedded devices
can potentially run it. You want to make something work on Windows? You
have to do everything totally differently. (No wonder people thought
that things like Cygwin and MinGW were a good idea.)

One of the things that has impressed me about GHC is that it takes
Windows seriously. The compiler and interpretter both work flawlessly on
Windows. They don't try to teraform Windows into just another Unix, they
actually try to do things The Windows Way. I like that. And it's not
like all of Hackage is useless to me; anything that's 100% Haskell
compiles and installs first time, almost every time. It's just
frastrating that all the cool multimedia stuff I'd like to be doing
requires access to C, and that's still currently very difficult. I
understand not many Haskell people use Windows, so it's not so easy for
people to test, and not so many people have a detailed knowledge of
Windows. And with this latest discussion, I'm beginning to understand
why binding to C is so hard.

But, yeah, it *is* still frustrating. ;-) And, unfortunately, I lack the
knowledge or skill to be able to improve the situation...

> But this is why developers are so wealthy, they have the
> fortitude to work through these problems.  (Ha ha.)
>  

Heh, good one. ;-)

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: binding to C libraries on Windoww

Andrew Coppin
In reply to this post by John Lato-2
John Lato wrote:
> To reply to an earlier point of Andrew's (I can't find the quote now,
> sorry), one of the biggest difficulties developers face on Windows is
> the lack of common install locations/practices.  Windows software is
> usually distributed as a binary, which may or may not include header
> files.  These files may be installed in any of numerous locations,
> Libraries and
> headers are usually not located on the PATH environment variable, and
> there's no standard INCDIR or LIBDIR variable either.
>  

Agreed.

> While it is Cabal's job to find the location of necessary libraries,
> header files, and tools, there simply is no feasible way to do so on
> Windows without searching most of the hard drive.
>  

Also agreed.

> The only workable approach is to have users specify the
> locations of these files, which unfortunately requires more
> sophistication than can be expected of most Windows users (and even
> some Windows developers).
>  

Well, I don't know. It's going to vary from package to package, but most
things that have a semi-official Windows version either come as a
Windows Installer package (which, one presumes records where it put
everything *somewhere* in the Windows registry), or possibly the
*developer* package comes as a simple Zip file that you just unzip to
wherever you fancy. Just tell the user the URL to grab the Zip file
from, unzip it and tell Cabal where the root is now. Shouldn't be too
hard. (Famous last words...)

The problem, of course, is that, especially if the file layout differs
significantly in the Windows version of the library, this is going to
absolutely _require_ somebody with a real Windows box and familiarity
with Windows to work on the Cabal packaging. (In extreme cases you might
even end up needing a completely seperate, Windows-only Cabal file.)
Presumably nobody will ever have the time or inclination to construct this.

> On a related matter, many packagers resort to using configure-style
> configuration setups to assist with binding to C libraries.  Cabal is
> now sophisticated enough to handle many of these steps (although not
> all), however packagers may not have had an opportunity to update
> their build process to remove the dependency on "configure".  These
> packages will continue to require cygwin or mingw for the "configure"
> step.
>  

Ah yes, this is pretty much guaranteed to make stuff not work on
Windows. :-) Still, all Unix systems have Automake, configure, etc., so
I guess most people don't even think twice before using it.

I gather it's supposed to be Cabal's job to figure this stuff out in
Haskell land?

> One last wrinkle: many distributors of C libraries do not have Windows
> machines available to test, and (understandably) have little interest
> in supporting a platform they don't have and aren't familiar with.  As
> a result, many C libraries are not well supported on Windows and
> require somebody familiar with gnu build tools (i.e. gcc, make, and
> autoconf) to be usable on Windows *at all*.  This means that, as a
> Haskell developer wanting to use these libs, you need to use gnu build
> tools because you're not just binding to the library, you're
> maintaining a Windows port of it.
>  

This seems to be kind of the catch-22. Nobody uses Windows, so there
isn't much support for Windows, so we don't attract many Windows
users... QED. :-}

> C and unix are pretty much designed to work together, and have been
> for decades, so I think it's reasonable to expect that Windows is the
> side that needs to adapt to support their model.

In other words, "Windows needs to become just like Unix". Not going to
happen. ;-) Argue about whether this is good or bad amoungst yourselves.
But it's not happening.

> MS hasn't done so,
> which means that C developers would need to unacceptably compromise
> unix support in their packages in order to better support Windows.
>  

I don't know about that... Lots of commercial and open-source products
are available for Windows and Unix, seemingly without any problem. (GTK,
for example...) I don't deny that adding Windows support is _a lot more
work_ than adding support for just another Unix, though.

> Cross-platform support precludes windows-native solutions, so you're
> left making the best of it with Linux tools (mingw and cygwin) on
> Windows.
>  

Yeah, it seems for the time being any Haskellers wanting to work on
Windows have to choose either to not use external C libraries or to
install the entire GNU toolchain. *sigh*

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windoww

Erik de Castro Lopo-34
Andrew Coppin wrote:

> Well, I don't know. It's going to vary from package to package, but most
> things that have a semi-official Windows version either come as a
> Windows Installer package (which, one presumes records where it put
> everything *somewhere* in the Windows registry)

Is that done automatically or does the installer have to explicity
set it? What does it look like?

The reason I ask is that I release a binary windows installer for
libsndfile. The binaries are generated using a Linux to Windows
cross-compiler and for the win32 version I run the testsuite under
Wine (windows API emulator). I then run INNO Setup under wine to
generate the installer executable.

> > On a related matter, many packagers resort to using configure-style
> > configuration setups to assist with binding to C libraries.  Cabal is
> > now sophisticated enough to handle many of these steps (although not
> > all), however packagers may not have had an opportunity to update
> > their build process to remove the dependency on "configure".  These
> > packages will continue to require cygwin or mingw for the "configure"
> > step.
> >  
>
> Ah yes, this is pretty much guaranteed to make stuff not work on
> Windows. :-) Still, all Unix systems have Automake, configure, etc., so
> I guess most people don't even think twice before using it.

There are bigger problems than that. The Microsoft compiler still doesn't
support large chunks of the 1999 ISO C Standard. There is stuff in that
standard that makes my life easier so I use it in libsndfile. Its also
why I much prefer to cross compiler from Linux to Windows with a GNU
compiler that supports the vast majority of the 1999 ISO C Standard.

I would be possible to make libsndfile compile with Microsofts compiler
but it would add a whole bunch of #ifdefs all over the place making the
code base fragile and in the long term less maintainable and reliable.

> > MS hasn't done so,
> > which means that C developers would need to unacceptably compromise
> > unix support in their packages in order to better support Windows.
>
> I don't know about that... Lots of commercial and open-source products
> are available for Windows and Unix, seemingly without any problem. (GTK,
> for example...) I don't deny that adding Windows support is _a lot more
> work_ than adding support for just another Unix, though.

Ignoring bugs and features that are common across all platforms in libsndfile
I have spent at least an order of magnitude more time and effort getting
things working with windows that I have with all of the Unixes (including
OSX) summed together. This for a platform I don't use.

> Yeah, it seems for the time being any Haskellers wanting to work on
> Windows have to choose either to not use external C libraries or to
> install the entire GNU toolchain. *sigh*

If those libraries use parts of the C99 standard then yes. Microsoft
has had 10 years to make their compilers compliant. Ask them why they
haven't.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windoww

Robert Greayer-2
In reply to this post by Andrew Coppin


On Mon, Dec 7, 2009 at 4:37 PM, Andrew Coppin <[hidden email]> wrote:

And I have no problem with needing to install a Haskell compiler. If I had to install a seperate C compiler to make FFI to C work, that wouldn't seem unreasonable either. (As it happens, GHC has a C backend, so the C compiler just happens to be there already.) What does seem very weird is having to turn my Windows box into a psuedo-Unix system in order to write native Windows programs.

<snip>

You can't develop anything with just what's preinstalled. (Well, unless you could writing batch scripts...)

Generally, if you want to develop C or C++ applications on Windows, you install MS Visual Studio. It gives you the compiler, linker, dependency management, and a whole bunch of other stuff. You typically wouldn't install gcc, ld and Automake. (Unless of course you were specifically trying to port existing Unix code, obviously.)

It helps, I believe, if you stop thinking of MinGW with MSYS as 'a pseudo-Unix system'.  They're billed as the minimal toolset required on windows to use the GNU compilers and build system (and, as everybody knows, Gnu's not Unix).  The great thing about these compilers is that they're cross-platform and freely available, unlike MS Visual Studio.  I think that it makes sense that open source software developers targeting multiple platforms would want to pick a tool suite that works across all those platforms, and the GNU tools fit that description.  Cygwin truly is a Unix emulation, but MinGW/MSYS is just a packaging of useful open source (GNU) tools for Windows (including a shell).  Many programs that work well as native Windows apps, such as the GIMP, are built with them.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windoww

Richard A. O'Keefe
In reply to this post by Andrew Coppin

On Dec 8, 2009, at 11:00 AM, Andrew Coppin wrote:
>>
>
> In other words, "Windows needs to become just like Unix". Not going  
> to happen.

I have the use of a dual-boot MacOS/Vista laptop.
"Subsystem for Unix-based applications" is a Microsoft download.
It means I can compile C programs using 'cc' or 'c89', and yep,
it's VS behind that curtain.

It's an alternative to MinGW or CygWin that might be worth exploring.
Visual Studio remains a separate product, but SUA is free.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windoww

Erik de Castro Lopo-34
In reply to this post by Robert Greayer-2
Robert Greayer wrote:

> It helps, I believe, if you stop thinking of MinGW with MSYS as 'a
> pseudo-Unix system'.  They're billed as the minimal toolset required on
> windows to use the GNU compilers and build system (and, as everybody knows,
> Gnu's not Unix).  The great thing about these compilers is that they're
> cross-platform and freely available, unlike MS Visual Studio.

These compilers are mostly C99 compliant, also unlike MS Visual Studio.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: binding to C libraries on Windoww

John Lato-2
In reply to this post by Andrew Coppin
> From: Andrew Coppin <[hidden email]>
>
> John Lato wrote:
>
>> The only workable approach is to have users specify the
>> locations of these files, which unfortunately requires more
>> sophistication than can be expected of most Windows users (and even
>> some Windows developers).
>>
>
> Well, I don't know. It's going to vary from package to package, but most
> things that have a semi-official Windows version either come as a
> Windows Installer package (which, one presumes records where it put
> everything *somewhere* in the Windows registry), or possibly the
> *developer* package comes as a simple Zip file that you just unzip to
> wherever you fancy. Just tell the user the URL to grab the Zip file
> from, unzip it and tell Cabal where the root is now. Shouldn't be too
> hard. (Famous last words...)

Indeed, in theory it would work this way.  In practice, not so much.

>
>> On a related matter, many packagers resort to using configure-style
>> configuration setups to assist with binding to C libraries.  Cabal is
>> now sophisticated enough to handle many of these steps (although not
>> all), however packagers may not have had an opportunity to update
>> their build process to remove the dependency on "configure".  These
>> packages will continue to require cygwin or mingw for the "configure"
>> step.
>>
>
> Ah yes, this is pretty much guaranteed to make stuff not work on
> Windows. :-) Still, all Unix systems have Automake, configure, etc., so
> I guess most people don't even think twice before using it.
>
> I gather it's supposed to be Cabal's job to figure this stuff out in
> Haskell land?
>

AFAIK, this is true to an extent.  I think that someone like Duncan
could explain the role of Cabal better than I can.

Of course Cabal was missing much of the necessary functionality until
only recently.  As an example, the possibility of listing C library
dependencies was only added in 1.6 IIRC.

>> One last wrinkle: many distributors of C libraries do not have Windows
>> machines available to test, and (understandably) have little interest
>> in supporting a platform they don't have and aren't familiar with.  As
>> a result, many C libraries are not well supported on Windows and
>> require somebody familiar with gnu build tools (i.e. gcc, make, and
>> autoconf) to be usable on Windows *at all*.  This means that, as a
>> Haskell developer wanting to use these libs, you need to use gnu build
>> tools because you're not just binding to the library, you're
>> maintaining a Windows port of it.
>>
>
> This seems to be kind of the catch-22. Nobody uses Windows, so there
> isn't much support for Windows, so we don't attract many Windows
> users... QED. :-}
>

Agreed (by users I presume you mean Haskell developers).  I remember
that many readers of this list were shocked by the download numbers
for the HP, particularly the high number of Windows downloads.  I
think it goes to show that there is interest among Windows developers,
as long as they have the sense that their platform is
equally-supported compared to Linux.  There are many more potential
windows developers than linux developers due to the size of the
Windows install base, so good Windows support is one of the easiest
ways to expand the audience.

>> C and unix are pretty much designed to work together, and have been
>> for decades, so I think it's reasonable to expect that Windows is the
>> side that needs to adapt to support their model.
>
> In other words, "Windows needs to become just like Unix". Not going to
> happen. ;-) Argue about whether this is good or bad amoungst yourselves.
> But it's not happening.

I don't mean that Windows needs to become just like Unix.  I mean that
if Windows supported a common installation location for .dll's and .h
files (and binary packages regularly provided them), much of this
difficulty would be easily resolved.  It wouldn't be "becoming like
Unix", it would mean adopting to a C distribution model that Unix
happens to share.

Regardless, I think I have a better chance of winning the lottery
jackpot than seeing MS support this in my lifetime.

>
>> MS hasn't done so,
>> which means that C developers would need to unacceptably compromise
>> unix support in their packages in order to better support Windows.
>>
>
> I don't know about that... Lots of commercial and open-source products
> are available for Windows and Unix, seemingly without any problem. (GTK,
> for example...) I don't deny that adding Windows support is _a lot more
> work_ than adding support for just another Unix, though.
>

This goes back to the catch-22 you listed above, but I wouldn't say
Windows support is "without any problem."  First you need active
Windows developers for this.  Commercial products have a big advantage
here.  Second, Windows support means a host of platform-specific bugs
to be dealt with in every part of the package.  These are in addition
to any other bugs that you'd have anyway.

FWIW, I had great difficulty in building hCsound on Windows, and my
primary development box at the time was WinXP.  I did eventually make
it work with the binary csound distribution, but not without a lot of
pain derived from the specifics of the binaries in ways that cabal
can't (and probably shouldn't) be expected to handle.

John
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windows

Andrew Coppin
In reply to this post by Erik de Castro Lopo-34
Erik de Castro Lopo wrote:
> There are bigger problems than that. The Microsoft compiler still doesn't
> support large chunks of the 1999 ISO C Standard.
>  

Seriously? OK, well that's news to me. I was under the impression that
practically all C compilers in existence support the same set of
features. (Although I'm sure each one probably has a few non-standard
additions too.)

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windoww

Andrew Coppin
In reply to this post by Robert Greayer-2
Robert Greayer wrote:

> It helps, I believe, if you stop thinking of MinGW with MSYS as 'a
> pseudo-Unix system'.  They're billed as the minimal toolset required
> on windows to use the GNU compilers and build system (and, as
> everybody knows, Gnu's not Unix).  The great thing about these
> compilers is that they're cross-platform and freely available, unlike
> MS Visual Studio.  I think that it makes sense that open source
> software developers targeting multiple platforms would want to pick a
> tool suite that works across all those platforms, and the GNU tools
> fit that description.  Cygwin truly is a Unix emulation, but
> MinGW/MSYS is just a packaging of useful open source (GNU) tools for
> Windows (including a shell).  Many programs that work well as native
> Windows apps, such as the GIMP, are built with them.

I see. So you're saying that while Cygwin is a Unix emulator, MinGW is
just a set of Unix-style tools which run natively on Windows?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windoww

Stephen Tetley-2
2009/12/9 Andrew Coppin <[hidden email]>:

>
> I see. So you're saying that while Cygwin is a Unix emulator, MinGW is just
> a set of Unix-style tools which run natively on Windows?
>

Yes, in a nutshell MinGW executables are native. Executables in Cygwin
may or may not have dependencies on cygwin.dll the Unix emulation
library (depending whether or not they actually use Unix calls of
course).
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windows

johndearle
In reply to this post by Andrew Coppin
There are several C standards by year of publication. There are also drafts
of those standards. A C compiler may comply with a draft of the official
standard before it became official, but not the official standard itself.
Rarely does anyone seek full compliance with respect to any standard it
seems and it can take years before everyone has bother themselves enough to
bring themselves up to speed with whatever the current standard is supposed
to be.

I use the Microsoft CL compiler (aka Visual C++). It has some undocumented
quirks/optimizations, but for the most part if you are doing native
development it seems fine. It is the official compiler so you just have to
learn to love it.

The problem seems to be if you are coming from a POSIX environment and
assuming that Windows is going to honor its conventions. I personally don't
bother with the C library very much. I deliberately avoid it. Its Win32/64
programming all the way with me. That too has its undocumented quirks, but
is better documented that the brief Java documentation for example. Windows
programming can be quite difficult. It is just that I've been around it for
so long.

Windows and Mac are not designed for people who are not dedicated to working
with these environments. I have experience in both of them. You may want to
use Microsoft Visual C++ to access the Microsoft .NET Framework rather than
bother with the C library. There is a Haskell library designed to help you
access the Microsoft .NET Framework directly from Haskell on Windows. Even
so, you may want to work with C++ to do this because the Microsoft
documentation will not explain to you how to do this in Haskell.

--------------------------------------------------
From: "Andrew Coppin" <[hidden email]>
Sent: 09 Wednesday December 2009 1159
To: <[hidden email]>
Subject: Re: [Haskell-cafe] Re: binding to C libraries on Windows

> Erik de Castro Lopo wrote:
>> There are bigger problems than that. The Microsoft compiler still doesn't
>> support large chunks of the 1999 ISO C Standard.
>>
>
> Seriously? OK, well that's news to me. I was under the impression that
> practically all C compilers in existence support the same set of features.
> (Although I'm sure each one probably has a few non-standard additions
> too.)
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: binding to C libraries on Windows

Erik de Castro Lopo-34
In reply to this post by Andrew Coppin
Andrew Coppin wrote:

> Erik de Castro Lopo wrote:
> > There are bigger problems than that. The Microsoft compiler still doesn't
> > support large chunks of the 1999 ISO C Standard.
> >  
>
> Seriously? OK, well that's news to me.

Yes, seriously:

    http://www.mega-nerd.com/erikd/Blog/Windiots/ms_c99.html

That list  is not complete, just what I felt was stuff that was hard
to do without. The lack  of a standards conforming snpirntf is
particlularly painful.

> I was under the impression that
> practically all C compilers in existence support the same set of
> features. (Although I'm sure each one probably has a few non-standard
> additions too.)

With the GNU compilers (and I suspect most other) the non-standard
features can be switched off. For the GNU compilers -std=c99 or -std=c89
allows the user to pick which standard they are compiling to.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
123