Executable to generate a system (basic hardware/software configuration) report on Windows? - directx

A lot of our customers report strange problems with our software, which is a 2D game using DirectX. The problems reported are often vague due to the nature of our clientele (which does not know how to make good bug reports or what information to provide).
We have not been able to replicate these problems even though a significant portion of our client base reports them.
We are looking for a way to generate a report (basically just a text file) with basic system information: hardware like graphics card, processor, memory, manufacturer; and software like OS version, anti-virus software in use, DirectX versions, etc. We would then have them send us this report file.
We have looked at using msinfo32 but the switches to limit it to certain categories do not work for us on our test computers, and we do not want all of the information it provides.
edit: msinfo32 no longer supports some of the switches we need to use on Windows 7.

I would look in to Speccy, as it can create such a report. Once run, the user simply has to choose File>Save as Text file to generate a text file of all hardware, though not software and A/V.

Related

How to get which video card(nvdia or amd) is using in DirectX

I need to know how to get which kind of video card is using in directX, because some features in my program are not supported in amd video card and cause crash.
So, I need to get which card the computer is using(some computer may have more than one video card).
So before you throw ATI/AMD under the bus here, make sure that the problem is not actually due to your application. For Direct3D 10/11, be sure to enable the debug device and ensure you do not have any CORRUPTION or ERRORS, and look at all WARNINGS.
Next, see if there is a newer driver available for the repro case. If there is, then just tell your users to update their drivers. If not, and it seems to be a legitimate crash inside the driver then report that as a bug to ATI/AMD (or NVidia or Intel as the case may be).
Test your app on more than one video card/driver combination from each vendor. For indies this can be challenging, but it's an important part of making sure your application works on a broad set of hardware. For Direct3D 11, you need to try various Direct3D hardware feature level devices to ensure good coverage.
Real games do have some extra warnings tied to detecting specific hardware IDs when dealing with wide-spread driver bugs and unofficial vendor-specific extensions). There is an example of doing this detection here based on the vendorid/deviceid combination in DXGI_ADAPTER_DESC or D3DADAPTER_IDENTIFIER9. Locking out all cards from a specific vendor is overkill and likely to just annoy your customers.

If WebGL isn't supported by my graphics card by default, why should I use it?

I am looking to make a web-based game. I saw lots of cool libraries that used WebGL (three.js, pixi.js, and more). The problem is that when I run the examples, I get the message "Your video card does not support Web GL."
Now, I could update my video card driver, but I'm not going to do that. Why not? Because the users of my game would never do that. Asking casual users (my target audience) to update their video card driver is a complete non-starter.
Is there a way to use WebGL without alienating a ton of users?
PS: In case you are wondering, my laptop is no slouch. I bought it Christmas '13 and it runs games like Bioshock Infinite flawlessly.
There are generally two reasons a video card driver may be blacklisted for WebGL by browsers:
because it has bugs that would allow malicious web content to exploit the driver/GPU to attack the system, or
because it has bugs or limitations that would result in severely incorrect rendering.
Because of the first, it's unlikely that, as a content author, there's anything you could do to enable WebGL, as that would constitute a vulnerability.
And this is why you can run BioShock but not WebGL: since the game is a regular application, by running it you've already trusted it with your system, so there's little benefit in preventing it from abusing the GPU/driver. Web pages, on the other hand, are not assumed to be trusted in this way. (If you ask me, it's a long-standing architectural mistake that regular applications have such free run, but that's a rant for another day.)

Is Blackberry WebWorks a good development choice?

This is kind of a dumb question but I've aware of classic style JDE development for Blackberry but I've never tried using WebWorks. BB website says that it's possible to build applications for both smartphones (OS 6.0+) and tablets - sounds fantastic, but what's the price?
Is here anyone using WebWorks on a daily basis and capable of describing pros and cons?
Thanks in advance
I would suggest using it if you build webOS applications before hand. It make porting to the blackberry a breeze.
Use WebWorks if you know html5, Css3 and javascript over Java and C++.
I haven't ran into any issues with the webWorks, ported two applications without running into any issues. Its your standard html5, css3 and javascript you love with blackberry APIs
WebWorks is a good development choice, particularly as it allows easy migration from earlier BB OSes to BB10. It's mostly standard web technologies (HTML5, CSS3, etc.) and the team seems focused on making it perform well (e.g. hardware accelerated WebGL graphics) while at the same time providing BlackBerry-specific APIs to make WebWork apps capable and with good UX (e.g. you can make it look like a native app).
For native apps, you should look into Cascades. This is a modern development environment with good tooling, accelerated graphics, and APIs for building snazzy apps. It's the one that will most be a "BlackBerry app".
AIR remains an option, but I would recommend WebWorks over AIR, as even Adobe is migrating from Flash to web technologies. Likewise, you can develop Android apps on BB10, but unless you are keen on Java programming, you will get more cross-platform support from WebWorks (or even AIR) so there's no particular reason to go the Android route.
WebWorks API is limited, for example it does not have socket, so you cannot port a VNC (UltaVNC, tightVNC ..) to it but you can do it with JDE.
For UI, WebWorks allowed me to write UI of acceptable quality quickly and easily, a thing that I have never succeeded with JDE.
Still on the UI side, I can make use of multi-touch (PlayBook), I don't think this one is possible with JDE.
So depending on your needs you should go either WebWorks or Native, having heard that Java may not be supported in BB10, and Air may not be future proof (Adobe favors HTML5 instead of Flash). Android appli has some lag on start up when it is run on PlayBook, some customers are sensitive to the initial even just one time slow response time.
I'm a huge proponent of Webworks. Ever since I've started using it, it quickly became the default option for my apps going forward. Especially for someone like me who is just writing a few apps on the side, I don't have the time to do it in c++.
The apps I'm writing revolve around home automation. They are client/server based from the get go.
Here's why I like it:
First and foremost, native API support. I can very easily create my own active frames, import invocation from other apps (think camera, stuff like that). I can export portions of my webworks app as an invocation card! Which means I can write say 3 unique apps (in this case home automation, lights, thermostat, security cameras). And I can very easily pull features from each app into the other. Maybe I want to turn my lights on in the living room, I can also import the camera card from my IPcam app and view the results, without having to add that code into my lights app and maintain two separate code lines.
Rapid design. Since I've been dabbling in html since I was a kid, it's now very easy for me to whip up an appealing UI in little time. Because web engines these days offer good performance in terms of graphics capability, I also can make apps that behave very fluid.
Considering the time to make something beautiful, it's hard for me to leave webworks and go for something in c++. Also the big plus is often these apps I'm making are intended for multiple devices, namely an app on my phone and being hosted on my personal website. By maintaining two slightly different css files, most of the time I need no code changes, just load a different css depending on if it's a phone or a pc. (Exactly what you'd do if you were developing a regular old website).
For that matter, I actually don't put my code on the device, I host all of my html and javascript, images etc on my server. The webworks app is just the config.xml pointing it's source to my server, and an icon. A glorified website bookmark on the homescreen, only difference is I can use native API and there's no browser bar in the app.
Also, this way I can still continue to edit the same single codeline on my server, and instantly apply changes to the in-browser app and the on-device app.
This is especially cool if you're designing an app where all of it's data is out in the "cloud", say you work for a publication and you want to write a magazine app which pulls content from your servers on the net.

Google event tracking used by a Delphi desktop application

I've come to a crazy idea to use Google event tracking in Delphi desktop application. I want to track users behaviour workflow to make application better. But it's in javascript.
Is it possible somehow to do it directly from application? Or do I need for example to make a webpage which communicates with Google event tracking API and application sends REST queries to that webpage?
Or maybe I can do it without javascript at all and directly from application?
You should be very careful with this, and warn your users.
Though software running locally is a different thing than software running from a web-site in a browser, the interconnectedness of software is increasing. So is the general feeling in the public on what is right and not to communicate.
For instance, a lot of software 'phones home' to check for the latest version without even asking permission to their users. I can understand that some users have a problem with that, but it indicates the general opinion on this is shifting. The vendors can track usage statistics based on that 'phone home' alone.
I'm not sure if the Google Event Tracking would be the best way to solve usage tracking from a desktop application, but the general idea (collecting usage statistics and error information) can work out very well.
Software from big vendors have been getting usage statistics from their software for years, and they ask their users up-front if sending statistics is OK, and at the time of an error, each time ask them if that is OK too.
In fact the book "Why Software Sucks ... and What Can You Do About It" and presentations from David Platt explains really well how to do this and how to communicate this to your users.
You need to do this in a very anonymous way, and you can because basically you are interested in these things:
what is the largest percentage of errors
what is the largest percentage of features used
what is the smallest percentage of features not used
As long as you communicate percentages, it is clear to explain to your users that the data will be very non-specific.
On the other hand: being able to focus on the actual errors can improve your software a lot.
The errors communicated back to you can contain much detail, so you need to either strip that detail out, or be very upfront with your users indicating which details are being sent to you when communicating individual errors.
--jeroen
I developed my own solution (I called it 'softmeter') to do exactly this. It is a dll that will do all the REST queries to Google Analytics.
There is sample Delphi code that wraps the DLL in a Delphi class so sending an event is simple as
dllSoftMeter.sendEvent('Conversion events', 'Donate clicked', 1);
If you do not mind using 3rd party libraries, you can use it.
In fact I found that most software using it, is Delphi made software.
Here is a more extended sample of the Delphi code for the implementation.
https://www.starmessagesoftware.com/blog/track-delphi-pascal-gui-application-google-analytics
You will need of course to get consent from the end-user.

Anyone ever tried to develop in C or C++ for Blackberry platforms?

Every indication I have, based on my experience in embedded computing is that doing something like this would require expensive equipment to get access to the platform (ICE debuggers, JTAG probes, I2C programmers, etc, etc), but I've always wondered if some ambitious hacker out there has found a way to load native code on a Blackberry device. Anyone?
Edit: I'm aware of the published SDK and it's attendant restrictions. I'm curious if anyone has attempted to get around them, and if so, how far they got.
I've seen this question pop up in a number of different forums over time. The original Blackberries were programmable in C++ but I think that RIM ran up against the problems of trying to implement a secure platform in the C/C++ compile to native paradigm.
The devices do have JTAG ports, but unless one could get hands on the RIM code as a place to start the problem is enormous.
I also have to wonder how useful a Blackberry with a replacement FOSS operating system would be, since it would not likely have the protocols to connect to BES or BIS, send PIN's etc. If one was simply looking for a the power of the hand held computing platform I suspect there are many more likely candidates available.
No, C++ is no longer a supported RIM development tool, as they phased it out a number of years ago. Client applications can be developed in Java (or one of a few 5GL frameworks), and web + sever-side apps can be developed using standard tools.
For those looking for updated information, the new Playbook os, also known as QNX, also known as Blackberry 10 (or it will be when the phones running it come out) is in fact c/c++ based, also using QML and a C++ add on called Cascades.
Unfortunately the official SDK website only seems to mention Java. According to wikipedia, different versions of the BlackBerry use different processors. Combined with the fact that RIM uses a proprietary operating system for the devices, it becomes pretty difficult to develop native code without official tools. There is also a partial API-level security restriction which would further prohibit advanced tinkering.
Just randomly searching for an answer to this and came across http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Native-C-C-SDK/td-p/778009 which mentions that BB intend to release a C/C++ SDK soon, more details will be provided at the 2011 Game Developer Conference.

Resources