On 11/6/2013 3:55 AM, Chris Warburton wrote:
BGB <cr88...@gmail.com> writes:
it is sad, in premise, that hard-coded Visual Studio projects, and raw
Makefiles, are often easier to get to work when things don't go "just
right". well, that and one time recently managing to apparently get on
the bad side of some developers for a FOSS GPL project, by going and
building part of it using MSVC (for plugging some functionality into
the app), but in this case, it was the path of least effort (the other
code I was using with it was already being built with MSVC, and I
couldn't get the main project to rebuild from source via the
"approved" routes anyways, ...).
weirder yet, some of the better development experiences I have had
have been in developing extensions for closed-source commercial
projects (without any ability to see their source-code, or for that
matter, even worthwhile API documentation), which "should not be".
This is probably an artifact of using Windows (I assume you're using
Windows, since you mention Windows-related programs). Unfortunately
building GNU-style stuff on Windows is usually an edge case; many *NIX
systems use source-level packages (ports, emerge, etc.) which forces
developers to make their stuff build on *NIX. If a GNU-style project
even works on Windows at all, most people will be grabbing a pre-built
binary (programs as executables, libraries as DLLs bundled with whatever
needs them).
It's probably a cultural thing too; you find GNU-style projects awkward
on your Microsoft OS, I find Microsoft-style projects awkward on my GNU
OS.
primarily Windows, but often getting Linux apps rebuilt on Linux doesn't
go entirely smoothly either, like trying to get VLC Media Player rebuilt
from source on Ubuntu, and having some difficulties mostly due to things
like library version issues.
granted, generally it does work a little better, like at least "most of
the time" the provided configure scripts wont blow up in ones' face, in
contrast to Windows and Cygwin or similar, where "most of the time"
things will fail to build (short of some fair amount of manual
intervention and hackery...).
and, a few times just finding it easier to go and port the things over
to building with MSVC (and "fixing up" any cases where it tries to use
GCC-specific functionality).
granted, it would also require an shift in focus:
rather than an application being simply a user of APIs and resources,
it would instead need to be a "provider" of an interface for other
components to reuse parts of its functionality and APIs, ideally with
some decoupling such that neither the component nor the application
need to be directly aware of each other.
Sounds a lot like Web applications. I've noticed many projects using
locally-hosted Web pages as their UI; especially with languages like
Haskell where processing HTTP streams and automatically generating
Javascript fits the language's style more closely than wrapping an OOP
UI toolkit like GTK.
can't say, not done much web apps.
I was more thinking though of some of what (limited) experience I have
had with things like driver development.
like, there is some bit of hair in the mix (handling event messages
and/or dealing with COM+), but in some ways, a sort of more subtle
"elegance" in being able to see ones' code "just work" in a lot of
various apps without having to mess with anything in those apps to make
it work.
but, in general though, I try to write code to try to minimize
dependencies on "uncertain" code or functionality.
a few times I have guessed wrong, such as allowing my codec code to
directly depend on my projects' VFS and MM/GC system, but later on
ending up hacking over it a little to make the thing operate as a
self-contained codec driver in this case.
this doesn't necessarily mean shunning use of any functionality outside
of ones' control (in a "Not Invented Here" sense), but rather it
involves some level of "routing" such that functionality can enable or
disable itself depending on whether or not the required functionality is
available (for example, a Linux build of a program can't use
Windows-specific APIs, ..., but it sort of misses out if can't use them
when built for Windows simply because they are not also available for a
Linux build).
sort of like codecs on Windows: you don't have to go write a plugin
for every app that uses media (or, worse, hack on their code), nor
does every media player or video-editing program have to be aware of
every possible codec or media container format, they seemingly, "just
work", you install the appropriate drivers and it is done.
the GNU-land answer more tends to be "we have FFmpeg / libavcodec and
VLC Media Player", then lots of stuff is built by building lots of
things on top of these, which isn't quite the same thing (you need to
deal with one or both to add a new codec, hacking code into and
rebuilding libavcodec, or modifying or plugging into VLC to add
support, ...).
Windows tends to be "we have DirectFoo", then lots of stuff is built by
building lots of things on top of these ;) Note that there are projects
like GStreamer which are designed to be unified interfaces to
libavcodec/ffmpeg/etc; however, they seem to have limitations since
there are now meta-interfaces like Phonon which sit on top of
GStreamer/VLC/mplayer!
yes.
in some cases, the "tyranny" of APIs like the Win32 API and DirectX and
similar isn't entirely a bad thing, as it can help limit the
proliferation of meta-APIs by keeping most functionality "relatively"
close to the level of the baseline OS.
though, one problem (common with many wrapper APIs) is a tendency to
focus more on wrapping functionality, rather than on providing a good
"hub" architecture for things to plug into and export to, hence the
common need to wrap the wrappers to provide additional functionality.
practically, there will be limits though, for example, in my case, the
near complete absence of multimedia APIs (or formats) which support
things like layers or alpha channels, causing a need for an (admittedly
ad-hoc) collection of infrastructure for dealing with a lot of this
(still lacking any good infrastructure for glossing over the handling of
multi-layer video streams though, *).
and, when exporting the functionality to other APIs (VfW, DirectShow,
and VLC), only really simple single-layer video streams can be exported
(any extended functionality would require bypassing the API).
*: note multiple layers in a single video stream, not multiple streams
in a single file.
also, sometimes things can support features indurectly even if not
properly supported by the standard OS level APIs or file-formats, like
AVI files with subtitle streams and similar, and some codecs supporting
features which aren't formally supported by the APIs, ...
Reminds me of the datatypes system in AmigaOS, which was a mechanism for
handling arbitrary file types. The floppy disks/CDs attached to
magazines usually contained a bunch of these (eg. PNG, GIF, etc.) which
could be dragged into the Workbench:Datatypes drawer and existing
programs would magically be able to access files of those types.
Well, that was the theory; many applications ended up bypassing the
system, probably due to lowest-common-denominator effects (ie. generic
access to "images" provides very little control over each particular
format's features). I've only started programming since being on Linux,
so that's pure speculation on my part. Would serve as another example of
environment-provided features which become too limiting for
applications, just like filesystems' embedded metadata.
yeah.
the capabilities of a central API are kind of an issue sometimes.
too few features can lead to limitations, but too many features can
burden writing applications or components, or in some cases hinder an
efficient implementation (for example, where only a small subset can be
implemented efficiently, but where one ends up with a polynomial
complexity factor due to the number of possible feature-combinations and
special-cases, potentially leading either to inefficient fallback cases,
or combinations of features which end up being widely unsupported).
in a few cases, this has had lasting effects, like where only a subset
end up widely implemented, and most of what is left over (in terms of
specified but not-widely-supported features) end up largely forgotten by
history.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
