PDA

View Full Version : Is DirectX really required on Windows?



adamac
2007-12-05, 16:37
I'm wondering if there's a specific reason that SDL was compiled with DirectX support on Windows. I managed to get Jive building and running without DirectX and it appears that everything works just fine.

Installing the DirectX SDK is a pain, so I was hoping this dependency could be removed if it's really not required.

kdf
2007-12-05, 19:08
Building under windows hasn't been a priority with so many global
issues to tackle in the software as a whole.
Early on, a number of graphic library options were turned off for
linux builds (the environ that is most used by the
developers of Jive). I'd expect that DirectX isn't required for
anything right now. In the future, however, Jive is planned to
replace SoftSqueeze as the software client for music. DirectX might
factor in when it comes to audio and the inevitable requests for
visualisations.

I know of only three people who have built on windows (including
yourself). I already have done the hurdle for directX SDK on two
systems
so it's no big deal to me to keep it. But, if you have a patch, it
might be an easier entry for folks who do wish to build for windows
in the near term.
I'm not sure how far in future the rest will be, so can't really say
what the issues might be with removing directX support altogether or
just temporarily.
A patch can still be considered.

-kdf

On 5-Dec-07, at 3:37 PM, adamac wrote:

>
> I'm wondering if there's a specific reason that SDL was compiled with
> DirectX support on Windows. I managed to get Jive building and running
> without DirectX and it appears that everything works just fine.
>
> Installing the DirectX SDK is a pain, so I was hoping this dependency
> could be removed if it's really not required.
>
>
> --
> adamac
> ----------------------------------------------------------------------
> --
> adamac's Profile: http://forums.slimdevices.com/member.php?
> userid=14296
> View this thread: http://forums.slimdevices.com/showthread.php?t=40843
>
>

dean
2007-12-06, 09:40
Yes, please post the patch to remove the DirectX dependency!

Ideally Jive applets would be platform independent and since DirectX
is only Windows, removing it should be safe.

Also, since it seems that you have some Windows skills, do you have
an idea why the built binary isn't portable across machines? Fixing
that would let us create a nightly Jive for Windows build...



On 5-Dec-07, at 3:37 PM, adamac wrote:

>
> I'm wondering if there's a specific reason that SDL was compiled with
> DirectX support on Windows. I managed to get Jive building and running
> without DirectX and it appears that everything works just fine.
>
> Installing the DirectX SDK is a pain, so I was hoping this dependency
> could be removed if it's really not required.
>
>
> --
> adamac
> ----------------------------------------------------------------------
> --
> adamac's Profile: http://forums.slimdevices.com/member.php?
> userid=14296
> View this thread: http://forums.slimdevices.com/showthread.php?t=40843
>
>

adamac
2007-12-06, 15:05
Patch attached.

I haven't seen the other issue you mention.

dean
2007-12-06, 23:39
On Dec 6, 2007, at 2:05 PM, adamac wrote:
> Patch attached.
Thx!

> I haven't seen the other issue you mention.
Ah, did you try running the jive binary on another machine at another
path? If it works for you, great!

kdf
2007-12-07, 09:36
On 6-Dec-07, at 10:39 PM, dean blackketter wrote:
>
>> I haven't seen the other issue you mention.
> Ah, did you try running the jive binary on another machine at another
> path? If it works for you, great!
>
I've never had any luck with this. However, I've never tried moving
it between machines that have all the
libraries installed that are required for building. I assume that
the problem stems from libraries not being
compiled as static, or a need for an installer that adds shared dlls
that are needed.

I've also never tried building a osx or linux binary then moving it
to another system to run it. Although, an
interesting idea once I get my macbook back from the shop. I'll have
two osx machines then,

-kdf

oreillymj
2007-12-10, 17:36
I have built Jive for Windows quite a few times. But never moved the .exe to other machines.

The .exe has a lot of dependencies.

There's a tool here http://www.dependencywalker.com/ that you can point at the .exe which will show you all the referenced dll's.

You can also find Filemon on www.sysinternals.com which you can use to log all disk activity while the app loads. By filtering for jive.exe you can then see disk activity caused by the .exe. It generates a lot of output, but will give you a list of all the files used by the app.

rtitmuss
2007-12-13, 05:00
Patch attached.

Thanks, committed in r1138.

rtitmuss
2007-12-13, 05:02
I have built Jive for Windows quite a few times. But never moved the .exe to other machines.

The .exe has a lot of dependencies.

There's a tool here http://www.dependencywalker.com/ that you can point at the .exe which will show you all the referenced dll's.


A while ago I tried dependencywalker, but could not see what dll's were missing when moving the .exe to other machines. Window's is not really my platform of choice :).

Maybe on the dependency on DirectX has been removed this task will be easier. Is anyone able to help get the installer working?

Thanks,
Richard

Ben Sandee
2007-12-13, 08:05
On Dec 13, 2007 6:02 AM, rtitmuss <
rtitmuss.31j3yb1197547502 (AT) no-mx (DOT) forums.slimdevices.com> wrote:

>
> oreillymj;248188 Wrote:
> > I have built Jive for Windows quite a few times. But never moved the
> > .exe to other machines.
> >
> > The .exe has a lot of dependencies.
> >
> > There's a tool here http://www.dependencywalker.com/ that you can point
> > at the .exe which will show you all the referenced dll's.
> >
>
> A while ago I tried dependencywalker, but could not see what dll's were
> missing when moving the .exe to other machines. Window's is not really
> my platform of choice :).


I don't know if this might be the problem but:

If you are using Visual Studio 2K5, make sure that any generated .exe/.dll
files have their corresponding .manifest files embedded during the make
process. This is a post-link step that is a common roadblock. Not doing
this will cause the executables to fail mysteriously if divorced from those
..manifest files, particularly to those used to any version of any toolchain
written in the history of computing (seemingly). :-)

A less elegant, but simpler alternative is to simply keep the .exe and
..manifest files together forever in the same directory.

Ben

dean
2007-12-13, 08:19
I tested this a few days ago and found that the audio seemed to be a
little delayed, but wasn't sure if it was my windows VM or the
directx change. Not sure if we should revert, but something to keep
an eye on.


On Dec 13, 2007, at 4:00 AM, rtitmuss wrote:

>
> adamac;247423 Wrote:
>> Patch attached.
>
> Thanks, committed in r1138.
>
>
> --
> rtitmuss
> ----------------------------------------------------------------------
> --
> rtitmuss's Profile: http://forums.slimdevices.com/member.php?userid=36
> View this thread: http://forums.slimdevices.com/showthread.php?t=40843
>
>

tomb
2007-12-20, 17:13
Also, since it seems that you have some Windows skills, do you have
an idea why the built binary isn't portable across machines? Fixing
that would let us create a nightly Jive for Windows build...

I took a look at that project after stalling on trying to build the Jive Hardware Platform stuff. At least I know my way around Windows...

One very real possibility of why this doesn't work on other machines except where it's built is that it links dynamically to the C runtime DLLs (like glibc.so). These runtime DLLs are not part of the OS, but are available as a redist. (and the manifest that Ben mentioned plays into version checking between C runtime and exe).

There are basically three solutions:

1. Switch to use static linking. This makes the Windows port self-contained and "just work" without any extra overhead apart from just copying the SDL DLLs and the exe. The drawback is that every single part carries its own partial copy of the C runtime (as much as is needed), the benefit is that there's nothing 'extra' necessary.

2. Switch to use dynamic linking, add an installer that includes the VC redist. The installer would essentially ensure that the C runtime is installed on the system.

3. Switch to static linking, AND make all the parts that are built as a DLL into libs, linking everything into one fat exe.

One of the problems (in general with the Windows build) is that it includes pre-built libraries (for example the freetype library) that were built with different compiler versions/options. This is a potentially iffy situation that can result in all sorts of strange behavior (the library expects a C runtime that's "compatible enough" with the current compiler - and we're about 10 years in difference between the pre-built library's toolchain and the currently active toolchain. It "seems" to work right now but I be too confident that it doesn't just collapse like a house of cards some time.

Solving this would mean re-building the pre-built libs with VC8 and the proper options whenever a new toolchain is used.

Do you guys have any preference which way this should go? Is there any reason for keeping a dynamically linked setup that requires an installer to work on "any" machine as opposed to "works for me (TM)"?

(I guess this makes me person #4 to attempt building this on Windows...)

dean
2007-12-20, 21:07
Thanks, tomb, for looking at this!

On Dec 20, 2007, at 4:13 PM, tomb wrote:
> 1. Switch to use static linking. This makes the Windows port
> self-contained and "just work" without any extra overhead apart from
> just copying the SDL DLLs and the exe. The drawback is that every
> single part carries its own partial copy of the C runtime (as much as
> is needed), the benefit is that there's nothing 'extra' necessary.
Can you elaborate on what "every single part" means? Is this just
the jive.exe?

> 3. Switch to static linking, AND make all the parts that are built
> as a
> DLL into libs, linking everything into one fat exe.
>
> One of the problems (in general with the Windows build) is that it
> includes pre-built libraries (for example the freetype library) that
> were built with different compiler versions/options. This is a
> potentially iffy situation that can result in all sorts of strange
> behavior (the library expects a C runtime that's "compatible enough"
> with the current compiler - and we're about 10 years in difference
> between the pre-built library's toolchain and the currently active
> toolchain. It "seems" to work right now but I be too confident that it
> doesn't just collapse like a house of cards some time.
>
> Solving this would mean re-building the pre-built libs with VC8 and
> the
> proper options whenever a new toolchain is used.
I thought that we were building everything in the pkg directory from
scratch. Which pre-built libs are you talking about?


> Do you guys have any preference which way this should go? Is there any
> reason for keeping a dynamically linked setup that requires an
> installer to work on "any" machine as opposed to "works for me (TM)"?
The goal here is to have a version of the jive.exe that we can
include with the SqueezeCenter installer (and possibly with other
installers) to be run later. Personally, I don't like the idea of
_requiring_ an installer to make an executable work.

rtitmuss
2007-12-21, 02:25
Do you guys have any preference which way this should go? Is there any reason for keeping a dynamically linked setup that requires an installer to work on "any" machine as opposed to "works for me (TM)"?

Well I don't know my way around windows, so I just did enough to get Jive compiling and running with minimal effort. A lot of the Visual studio project files came from the SDL and lua distributions, including those pre-built binaries. Is static linking normally used for windows apps? I don't see any problems changing to static linking, and really we should get rid of the pre-built binaries.


(I guess this makes me person #4 to attempt building this on Windows...)

I know of a few more, we may be in double figures now :)

Richard

tomb
2007-12-21, 09:49
[static linking]
> The drawback is that every
> single part carries its own partial copy of the C runtime (as much as
> is needed), the benefit is that there's nothing 'extra' necessary.[/color]
Can you elaborate on what "every single part" means? Is this just
the jive.exe?
I should have been more precise. "Every single part" means "every output of the linker" (I guess you could could call it "linking unit" in reference to "compilation unit").

In this particular case, this is jive.exe and all the DLLs that are built. The linker, when producing an exe or dll with 'static linking' will pull in all the used parts from the C runtime into the binary. It'll do this independently for jive.exe as well as the DLLs.


I thought that we were building everything in the pkg directory from
scratch. Which pre-built libs are you talking about?
Well, there's a few DLLs for jpeg/png handling - http://svn.slimdevices.com/repos/jive/trunk/jive/src/pkg/SDL_image-1.2.5/VisualC/graphics/lib/ - going by their DLL imports, they were compiled with VC6 - and then there's Freetype that's linked into SDL_ttf (http://svn.slimdevices.com/repos/jive/trunk/jive/src/pkg/SDL_ttf-2.0.8/VisualC/FreeType/lib/) which was compiled with VC6 with static linking (I think). Yeah, there is a freetype source in there, but it's not used in the SDL_ttf build.


The goal here is to have a version of the jive.exe that we can
include with the SqueezeCenter installer (and possibly with other
installers) to be run later. Personally, I don't like the idea of
_requiring_ an installer to make an executable work.
OK, I understand. If I get some time, I'll see if I can get it to be "neat", play around with various configurations. I'll let you guys know.

tomb
2007-12-21, 09:55
Thanks for your comments, Richard.


Is static linking normally used for windows apps? I don't see any problems changing to static linking, and really we should get rid of the pre-built binaries.
"It depends". There's a size tradeoff, since the C runtime adds another 2 or 3 MB of download size (and probably 10 MB of disk space). If an app is "large enough" - especially if it has lots of different parts - dynamic linking is usually used. But as mentioned, it pretty much requires an installer to dump the C runtime redists.

In my daytime job, we've gone from dynamic linking (stuff based on the VC6 toolchain) to static linking (when we were doing VC7.1 (2003), mainly for download size, and now we're going back to dynamic linking. For some situations (such as if you use MFC *and* MFC "extension DLLs"), you don't have an option - it has to be dynamic linking.

Ben Sandee
2007-12-21, 10:26
On Dec 21, 2007 10:55 AM, tomb <
tomb.31yaxz1198256402 (AT) no-mx (DOT) forums.slimdevices.com> wrote:

>
> Thanks for your comments, Richard.
>
> rtitmuss;250515 Wrote:
> > Is static linking normally used for windows apps? I don't see any
> > problems changing to static linking, and really we should get rid of
> > the pre-built binaries.
> "It depends". There's a size tradeoff, since the C runtime adds another
> 2 or 3 MB of download size (and probably 10 MB of disk space). If an app
> is "large enough" - especially if it has lots of different parts -
> dynamic linking is usually used. But as mentioned, it pretty much
> requires an installer to dump the C runtime redists.
>
> In my daytime job, we've gone from dynamic linking (stuff based on the
> VC6 toolchain) to static linking (when we were doing VC7.1 (2003),
> mainly for download size, and now we're going back to dynamic linking.
> For some situations (such as if you use MFC *and* MFC "extension
> DLLs"), you don't have an option - it has to be dynamic linking.


Another case where dynamic linking is better is in the case of security
updates. If a the C runtime (or MFC, etc) has a vulnerability then the
updates can be applied globally, whereas using static linking it will
absolutely require the application be recompiled.

The addition of the new manifest functionality, while painful, will go a
long ways to eliminate 'DLL hell'. Unfortunately the Windows toolchain
diverges even further from UNIX.... There's always MinGW and/or cygwin....

Ben

rtitmuss
2007-12-21, 13:14
There's always MinGW and/or cygwin....

I choose Visual C in the hope it would attract some Windows developers to our community. I still think given a little tlc this is still the best option to support Jive on Windows.

MinGW is a possibility, but cygwin is not compatible due to licenses.

Richard

Ben Sandee
2007-12-21, 13:24
On Dec 21, 2007 2:14 PM, rtitmuss <
rtitmuss.31yjz11198268103 (AT) no-mx (DOT) forums.slimdevices.com> wrote:

>
> Ben Sandee;250628 Wrote:
> > There's always MinGW and/or cygwin....
>
> I choose Visual C in the hope it would attract some Windows developers
> to our community. I still think given a little tlc this is still the
> best option to support Jive on Windows.


I wasn't suggesting you migrate Jive and I fully understand why you would
use Visual C++. Although if someone were to use either MinGW or cygwin for
their own development efforts would you want to stop them? I write this
from my main development machine which is Linux... :-)

Ben

rtitmuss
2007-12-21, 13:39
Although if someone were to use either MinGW or cygwin for
their own development efforts would you want to stop them? I write this
from my main development machine which is Linux... :-)

No I wouldn't want to stop them, as always patches welcome :)

rickwookie
2008-01-15, 16:42
Just thought I'd chip in, since I tried building the Jive software for the first time today and managed to both get it to run and also transfer to another machine.

It was a bit fiddly, but basically I installed VC++ Express (the links in the wiki are a bit out of date, since it's now version 2008, so I updated the wiki accordingly) and managed to build it without needing to add any PlatformSDK files or anything from DirectX.

Once built the exe CAN be run on another machine but there are some VisualC++ runtime DLLs that need to also be on the target machine.

The problem was hard to pin down since the error on the target machine didn't simply say that whatever.dll could not be found, but rather ambiguously that the system was not properly configured.

I'll take a look at it a bit more tomorrow, but basically at the moment if you look at the manifest files for the release build, and compare them with the ones for the debug buid, you'll notice that the release build seems to have a dependancy on both the release and debug versions of the runtime. That must be a mistake and I'll try to fix it, but my workaround was to copy both sets of DLLs from the VC++ Redist folders (debug and release, 4 DLLs each so 8 in total) to the target machine and it worked!

There's a reference to a DirectX lib in the Release build configuration that needs to be deleted to get it to build. I'll post full details of all the tweeks tomorrow.

One small point, if the executable is built using VC++ Express (as opposed to the full paid for version), is there then any restriction to the distribution of the resulting files?

rickwookie
2008-01-16, 05:34
Okay, found the problem.

First, in both the SDL_image and SDL_ttf projects, in the Solution Explorer, right-click the file 'Version.rc' and click 'Exclude From Project'. Then delete 'Version.rc' from both '\src\pkg\SDL_image-1.2.5\VisualC' and '\src\pkg\SDL_ttf-2.0.8\VisualC'. They don't appear to be needed (it builds without them) and they reference "afxres.h" which in turn references "winres.h", neither of which seem to be included with Visual C++ 2008 Express.

All of the projects (bar SDL_ttf, SDLmain and tolua++) had the _DEBUG preprocessor definition in their 'Release' build configuration. Removing it and rebuilding removes the dependency on the debug versions of the VC9 runtime DLLs.

To correctly install the release runtime DLLs on the target machine, use the 'Microsoft Visual C++ 2008 Redistributable Package (x86)' available here:
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en
This sets up the SidebySide stuff (???) in the WinSxS folder to have the correct version DLLs that are referenced by the manifest. I think it's something to do with allowing several different versions of the same DLLs to be present on the same machine without having to have them in each apps local folder. Apparently in Windows(TM) logic, it's simpler than just using a different file name for a different version of a file. ;-)

Then just copy the contents of the built release directory ('\src\pkg\Release') to the target machine, run 'jive.exe' there and you're away. :-)

Richard.

rtitmuss
2008-01-16, 05:48
Excellent, those changes seem to work well. I have checked them in r1461.

Many thanks,
Richard

rickwookie
2008-01-16, 06:04
Sorry I forgot the DirectX reference (after removing it yesterday I can't remember what/where it was!). I guess it's obvious since it'll throw a linker error when you try the 'Release' build anyway.

@rtitmuss: I was just about to PM you to ask if I should check the changes in, but you beat me to it. I was a bit worried anyway since I'm an SVN virgin. I'm using TortoiseSVN, if I'd just right-clicked 'SVN Commit...' would that have been the correct option?

Edit: Actually, that option shows me the diff and I can see that it's in the SDL project 'Release' configuration, Linker->Input->Additional Dependencies, remove dxguid.lib. Also I notice that Linker->General->Additional Library Directories has "C:\Program Files\Microsoft DirectX SDK (February 2007)\Lib\x86". That can probably go too.

rtitmuss
2008-01-16, 06:31
@rtitmuss: I was just about to PM you to ask if I should check the changes in, but you beat me to it. I was a bit worried anyway since I'm an SVN virgin. I'm using TortoiseSVN, if I'd just right-clicked 'SVN Commit...' would that have been the correct option?

You won't be able to commit changes into SVN when you have checked out anonymously. Only regular contributors to the project are added to the commit list. The best way for you to submit changes is using the Create Patch option in TortoiseSVN, then post the patch here or via email.


Edit: Actually, that option shows me the diff and I can see that it's in the SDL project 'Release' configuration, Linker->Input->Additional Dependencies, remove dxguid.lib. Also I notice that Linker->General->Additional Library Directories has "C:\Program Files\Microsoft DirectX SDK (February 2007)\Lib\x86". That can probably go too.

Committed in r1462.

Thanks,
Richard