[aken.sys security concerns]

Interesting, thanks for the data. Looks like 9 people with the TSC (though the 1.5 GHz one is quite a low frequency).

The vast majority is apparently running Linux, which reports 1 GHz. Also interesting - they probably scale the

TSC. 4 are using the HPET - unsure whether on Linux or via Aken (and one of them has the frequency hopping thing enabled,

which is why it doesnt exactly hit the frequency of the classic PC master clock). 2 using PMT, which is rather buggy and bad.

It'd really be good to combine this data with OS. Then we've got (most likely) 4 Windows users where QPC is returning TSC/1024.

2 poor guys are most probably using our TGT fallback - that's the one with miserable millisecond resolution and the falling-behind bug.

This is regrettable - I'd love to ask them what hardware they are on. Can we get at that data?

Finally, we have 4 people with 1 MHz (why aren't they combined into one bin) - not sure what that one is, probably Linux again.

It looks like 2(PMT)+4(scaled TSC)+2 TGT out of ~15-20 Windows users would benefit from HPET (the ones with scaled TSC only slighty).

Does seem worthwhile for them. Interestingly, the majority is running Linux (or Mac, I have no idea what they report).

Really do need the OS info to draw a conclusion

[aken.sys security concerns]

using the generic name "timer" in the global scope is more likely to conflict with other code

True. It's on the back burner for now as I've already left for Singapore; we'll see what the new employer's policy is.

And yes, naming is especially hard for this kind of miscellany. jwlib isnt so bad, cbloom appararently reached the same conclusion with cblib

I failed to do this earlier, but I've added it now, so I'll wait another while then look at the data.

Cool, thanks! I am looking forward to seeing this data.

[Build environment and deployment on the Mac]

PPC support is not even on the table, unless a community enthusiast wants to develop and test that When we say "universal" we are only meaning 32/64-bit Intel.

Yes, just to expand on this a bit - there would probably be some additional pain due to byte alignment and endianess (PPC is stricter/different on both counts). That's why we have always assumed only x86/x64 would be supported.

[Game Error]

To expand a bit more on Philip's entirely correct reply:

The message just means the platform/BIOS does not provide a HPET, so activating it understandably fails

r10858 will indeed stop this from appearing, because we would no longer even check for the HPET (unless the user takes additional action by invoking aken_install.bat).

I am not sure why the error code isn't resolved into an error string - that's worrisome and will be investigated tomorrow.

[Had an Atlas crash]

Cool, glad you fixed it

I am a big believer in symbol information in general.

It is apparently possible to force a PDB to match:

http://stackoverflow.com/questions/744870/how-can-you-change-an-age-mismatched-pdb-to-match-properly

That looks too crazy even for my taste, though, so it'd

be nicer to always commit PDBs of any code of ours that

might possibly crash

I don't think the AtlasUI symbols depend on wxW -

did you have any particular problem in mind?

[aken.sys security concerns]

Thanks for mentioning so. That is indeed the expected behavior on Win7 x64.

The error message is misleading or false in that the driver is not unsigned - it is just not signed with a special Microsoft certificate.

You can work around it by enabling test mode (see aken_install.bat) or launching the game with the -wNoMahaf command line switch or updating the game to the most recent SVN revision, which no longer attempts to start the driver. (It will still be accessible if you have used aken_install, though.)

[Had an Atlas crash]

OK. If it's difficult to repro, perhaps we can see the problem from this crashdump once the symbols are available.

It's great that you posted it

[Had an Atlas crash]

Bummer, sorry to hear that.

Presumably you were running with the latest binaries from SVN?

Unfortunately we don't have symbols for AtlasUI.dll in SVN.

@Philip - would you please add them?

[aken.sys security concerns]

I think it would be enough to just report timer_Resolution.

(Incidentally, a colleague asked to namespacify timer.h, turning it

into timer::Resolution etc - any objections?)

The current code only allows choosing one timer (the best

available) and it'd be a spot of a bother to get them all.

However, we can still deduce a lot from that - presence of

an HPET can be gleaned from the chipset (i.e. CPU), and

I would recognize the other timers based on their frequency

(because the CPU frequency is also known).

Let me expand on the 1 ms. That's only if somewhat calls timeSetPeriod

and speeds up the timer interrupts to 1 kHz, which can slow down

the entire system by 10-15% and reduce "battery run time on mobile

systems by as much as 25 percent" [http://download.microsoft.com/download/3/0/2/3027D574-C433-412A-A8B6-5E0A75D5B237/Timer-Resolution.docx]

Certainly not an ideal solution, but it's still better than the

default of 15 ms (!), which is just terrible. And I suppose the

driver, while evil, may still be an attractive option on WinXP

laptops with semi-decent graphics cards.

As to falling behind, here's someone mentioning > 5 s slippage in about

30 minutes play (= 2777 ppm), which apparently took down their

network protocol:

http://osdir.com/ml/games.devel.windows/2002-09/msg00000.html

That's FAR worse than thermal drift, which is on the order of

200 ppm for a really grungy oscillator, and maybe 20 ppm for a

decent quartz.

However, if the network protocol is quite robust to such things,

then we can maybe forget about the slippage. I have no idea why

the previously mentioned game had that problem, but doubt it was

because the developers were idiots.

Good point about the spirit of the GPL. As you can tell, I really

hate the new driver signing hoops, especially because it's to

prevent circumventing DRM (which is truly something that removes

user control). As is, the driver was designed to provide all the

requisite possibilities and therefore not require changes.

Unfortunately that does bring the security issues with it :/

Changes to the driver are actually still possible - the current

signature is no better (actually apparently worse) than some

self-signing thing that could fairly easily be managed.

aken_install would still need to enable test mode, and

additionally just install a certificate.

That said, I agree about the insecurity and scariness. Again, it

comes down to how we balance that vs. battery life or timer problems.

Maybe we'd be best served with some kind of opt-in thing, which

is basically what aken_install already is. I have therefore

disabled StartDriver by default in mahaf.cpp.

Anyway, it certainly would be interesting to get that data

on the number of people with bad timers. Would you please

add timer_Resolution to the hwreport?

[aken.sys security concerns]

Thanks for joining the forum to post your concern!

I imagine the similar winring0 library also removed most of its

functions after version 1.3 for these same reasons.

Let's begin with the signature. You will find it to be

basically OK and trusted by a root certificate, so the

driver's integrity and source can at least be established.

However, Vista and Win7 have apparently started requiring

an additional bit in the certificate, and I'm not clear

on which. "Basic Constraints" and "Key Usage" are marked

with an exclamation point, so those are probably the

culprits. "Digital Signature (80)" looks OK - maybe they

also want an additional one for kernel-mode drivers, but

I haven't come across mention of this and don't see which

of the other possibilities it would be.

Basic Constraints is AFAIK used to limit the chain length,

and I can't do anything about that. Indeed one problem we

are facing is that the certificate is from Fraunhofer,

but I will be leaving their employ within 2 weeks, having

finished my PhD. We therefore cannot count on changes to

the certificate or driver.

Now let's look at the situation concerning driving loading.

Due to the above issue, x86 Windows Vista and later will

refuse to start the Aken service. The x64 versions of

Windows are even more restrictive - they require signing

with a additional "cross certificate". On all of these

systems, the driver will not load unless the user disables

CodeIntegrity checks (resulting in a warning ever time such

drivers load) or enables test-signing mode (which

aken_install.bat is equipped to do). The latter is also a

security hazard in that it allows anything with a semi-decent

(even self-signed) certificate to load. Ironically enough,

the bone-headed attempts at securing the system by effectively

disallowing independent drivers lead to less security. You

will find a similar approach here:

http://www.freeotfe.org/docs/Main/impact_of_kernel_driver_signing.htm

On WinXP x86, the driver will actually load without user

intervention - unless the command-line argument -wNoMahaf

is given. That system is also where normal users' need for

the driver is greatest, because the time source may only have

a resolution of 1 or more ms (too low for game usage) and even

fall behind over time.

So, where to go from here? On the one hand, we could argue

that WinXP is totally insecure anyway because everything

basically runs as Admin. mahaf.cpp could easily examine the

Windows version and act accordingly. We can also throw

up our hands and say we'll do timing as badly as other

games - though problems have been reported, at least we

won't be alone. For example, -wNoMahaf could be made the

default by means of a windows shortcut. It could also be

done from within the game code, but hopefully in such a

fashion that the apps at work don't need an EnableMahaf()

call to be added. On that point - again, I will soon be

switching jobs, and the new employer is quite careful with

IP rights. It is possible that I will no longer safely be

able to contribute to 0ad - that will need to be discussed

with them first. (It would be a shame, because then the

codebase - which I am sure will continue to see use - would

fork and no longer be updated.)

One final point - the driver is also used at work to provide

access to the performance counters, some of which are not

available in VTune/Parallel Amplifier (e.g. Nehalem uncore

for bandwidth/memory controller measurements). This requires

write access to the MSRs. Moving all the logic into the driver

would be possible, but another huge change that won't happen

quickly, i.e. within the next 2 weeks.

So - what's y'all's opinion? How shall we proceed?

[Alpha 7 Crashes before Matches]

Hi! Unfortunately you'll need more than an integrated graphics card to run the game.

It's most likely a video-related crash, possibly because the driver is erroneously reporting support for an extension we require.

Please give it a try on a system with a dedicated graphics card and ensure your driver is up to date.

If it still crashes, please also upload the .dmp file (very important for analyzing other types of crashes) and we'll have a look.

[OpenGL 3 extensions]

These questions are all directed at Philip, but maybe I'll save him some time

IIRC, the shaders were intended to simplify the code and reduce the number of combinations that had to be implemented.

Shaders sometimes decreased the performance, but can also lead to improvements vs. equivalent fixed-function stuff.

I do not know the rationale for the OpenGL3+ extensions. They're not currently in use - perhaps only for completeness or for other applications.

We could print the extensions, but I am wondering as to the intended application.

It would be possible already to grep for ogl_HaveExtension and gather the list, and then match that against those reported in logs/system_info.txt .

The capabilities database requires an analysis tool to be run on the server; that needs to be triggered manually, and I guess it hasn't been done in some time.

[svn version: long texture loading time]

Let me add to that a little bit. The one-time conversion to DDS/S3TC is actually rather compute intensive if you care about quality, because it involves finding the optimal 2 colors for every 4x4 block, which is quite a bunch of combinations.

If you suspect or would like to probe for other slowdowns, you use the TIMER_ACCRUE functionality documented at http://trac.wildfiregames.com/wiki/EngineProfiling .

Anything that gets into the gigaclock range after a minute or two is something we should look at

[64-bit machine]

A minor note on telling whether apps are 32-bit: you can see the Task Manager process listing. If "Image Name" ends in "*32", it's running in 32-bit mode.

That applies to about half of the processes I currently have running, so we're in good company

[RFC: macros for avoiding unused-param warnings]

That's a very good point. I don't see a way to get commented-out names into Doxygen.

There are not THAT many unused parameters, but I agree they should be mentioned in Doxygen.

The commenting-out idea is dead in the water as far as I'm concerned.

Any ideas for better (but still short) names for the macros?

[RFC: macros for avoiding unused-param warnings]

We have two macros for annotating code and preventing unused argument/variable warnings.

void Function(int argument1, float UNUSED(argument2))
{
	ASSERT(argument1 == 0);
	UNUSED2(argument1);
}

The first argument is used only in debug mode, so we need UNUSED2 to suppress the warning.

I never did like that name for the macro, but UNUSED_VARIABLE is a bit too long, and naming

UNUSED differently would be even worse in that regard, because it sometimes occurs several times in parameter lists.

I just had a simple idea - how about replacing UNUSED() with a C-style comment: float /*argument2*/ ?

That shortens the parameter list and leaves the UNUSED name for the current UNUSED2.

Any objections or suggestions for further improvement?

[Pyrogenesis, show time played.]

Great, thanks for sitting down and implementing this! Very useful feature indeed (for optimizing build orders >:-) ).

[TortoiseSVN 1.7 error]

Thanks for the report, this will serve as a warning to anyone wanting to upgrade

A search for that error message didn't turn up anything. Might want to report it to the SVN mailing list.

In the meantime, it's probably best to check out a fresh working copy with 1.7 (or downgrade as you've mentioned).

[nothrow attribute w/ gcc]

Thanks for the report! I was not aware about the restriction on definitions and still haven't found any mention of it.

The closest is http://www.mail-archive.com/commits@stdcxx.apache.org/msg00960.html, which also use the separate DEFINE/DECLARE approach. It's ugly, but preferable to possible pessimization via throw(), so I'll go with that approach.

Am about to commit a fix; sorry about the breakage.

[Working On Upgrade To Premake4]

I concur. There used to be some trouble with the resulting project, but we ruled out the new Premake4 stuff as the cause, and it has since been fixed.

[0 A.D. Portable]

Yeah, I think we agree on that (cache in appdata, everything else that's writable/generated in my documents).

I was just pointing out that the Program Files option is going against the rules and intent.

If you are thinking along the lines of making modding easy (hence everything in Program Files) - is that desire covered by the current option of checking out via SVN and having the entire game tree reside in one directory? I imagine that's what most people do who are seriously inclined to tweak and play around with things.

Those two options might suffice, without requiring any additional logic in the installer.

[0 A.D. Portable]

The question is whether we value the Windows Software Logo requirements, which very explicitly forbid writing data in Program Files and demand Appdata instead:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3859

[Game won't start in Windows]

Thanks very much for this information! As noted in the ticket, I have found the cause; a fix is upcoming.

[Scrolling by keyboard gets stuck]

Thanks for the report; it'd be great if you would look into this!

It could be a problem within SDL, but that's a bit less likely because it seems to happen on the OS X backend, too.

If you see any gremlins lurking within out input handling chain (starting at lib/input.cpp), I will be happy to give it a look and/or apply a patch.

Incidentally, if you see this problem again, it should be possible to work around it by pressing+releasing the same `stuck' key.

The problem does not arise with mouse scrolling because we check each frame whether the mouse is near the border. Once the mouse returns elsewhere, movement will stop immediately.

[Alpha6 Binaries For Mac Os X]

Sorry guys, but that's how it is

We have gone to considerable effort to support OS X at all in the code. Recent work on a new+improved build system has allowed the use of Xcode. Since we lack a developer on the team with OS X who can look into the release process, fix OS X-specific issues and provide binaries at the time of an alpha release, we have to hope someone in the community can do so. That's all we can offer at the moment.