Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


samoth

Member Since 18 Jan 2008
Offline Last Active Today, 02:00 PM

#5227026 Is it necessary to license your game?

Posted by samoth on 03 May 2015 - 04:51 PM

While it is a big deal, I just want to clarify that, copyright infringement is civil law not criminal law
It just depends where you live.

For the USA, you are (as far as I know) right. In the EU, on the other hand, things like copyright infringement and plagiarism are under criminal law (with penalties going from fees in the 10k-100k range to prison, depending on what exactly you're found guilty of). That may not be the case in the USA, but considering the sheer cost of a typical US lawsuit (and the totally irrational sums that are being asked in the US) it doesn't make much of a difference, civil law is equally devastating (maybe even more so).




#5226507 Random Number Generation

Posted by samoth on 30 April 2015 - 08:03 AM

Someone said that I should not use public keys because they are suspected of being susceptible to quantum cracking.
No, I said that it is nonsensical to use public key cryptography on the one hand side, and then, at the same time, insist on using OTP (transmitted over a channel secured by public key cryptography) because block ciphers are not secure enough.

 

Because, if anything is susceptible to a future, still hypothetical large-scale quantum computer, it will be public key cryptography.

 

samoth made a suggestion for 512-bit encryption

Again, not what I suggested. I suggested you use 128 bits, or 256 if you really, really, really feel unsafe.

 

I said that you could use 512 bits if you are pathologically paranoid. There is no technical reason why you couldn't do that, it's just that it is silly, and people will laugh at you. However, if you are really, really worried about a backdoor that maybe reduces the 2256 complexity of an attack to 2200 or even 2150 (this would be a bummer, but still it would be pretty harmless since 2150 is still entirely unfeasible), then it costs very little (a mere 32 bytes extra) to use a 512-bit key instead. It's possible, but it doesn't make sense.

Note that although 2*256 = 512, this does not mean that 2512 = 2*2256. It's a slightly bigger number than that.

 

With that in mind, the question "why not 1024- or 2048- or 4096-bit" makes me more and more think that you are not being serious, or that your earlier statement about knowing a lot (or anything) about cryptography isn't true. You should really understand how many orders of magnitude are between a 128-, 256-, 512-, and 1024-bit binary exponent.

 

256-bit symmetric keys are overkill already, but 512-bit keys are (insane + overkill)256. I'll leave it to you to figure what 1024-bit keys are. laugh.png

 

 

Also, one of the things that really bugs me about cryptography is that for the most part, it's not provably secure.

 

Humans, on the other hand, are provably insecure. The symmetric block cipher is not the weak link in your security chain, and the 256-bit key isn't, either.




#5226491 Random Number Generation

Posted by samoth on 30 April 2015 - 06:55 AM

I'm not an expert in the area but that feels to me like the wrong way to go about it. In a lot of places of the world (especially those were an actual terror attack would really be noticed) just shooting someone is bound to cause at least a little bit of investigation. Shouldn't your priority be to make it look like a plausible just-an-accident-scenario?
Hahaha, yes... probably. I'm not precisely an expert with shooting people and doing terrorist stuff and the like, either. biggrin.png

But my point is, people are much less reliable than crypto algorithms. It's more likely that the other guy will let the super awesome secret out (boasting about it in the bar the following evening, or telling his girlfriend, or maybe under the influence of "enhanced interrogation") than that someone will break your cipher.

So if one is paranoid about one, then one should consequentially silence the other. Which of course renders communicating with him and telling him the secret in the first place somewhat superfluous...




#5226484 Random Number Generation

Posted by samoth on 30 April 2015 - 05:49 AM

I just know that computing power increases exponentially over time

No.

Computing power is (roughly) proportional to the number of transistors. Yes, there are other factors, but this is one major factor. The minimum size of transistors is limited by hard constraints. Other effects (induction, leak currents) are already noticeable now, but let's completely ignore these. You will agree that you cannot possibly build a transistor with fewer than one silicium atom, right?
These have a diameter of about 220pm and Haswell (as an example) has 22nm transistors. 22nm = 22,000pm, so in other words, a transistor's diameter is about 100 times the diameter of an atom only. There's not much room downwards for exponential growth, is there?

Of course you can simply make the chip bigger, but the bigger it gets, the more the speed of light becomes a limiting factor. Unless you have a solution for that, too. Yes, you can cheat a bit with 3D transistors, but let's say this gives you maybe another 100,000x increase, it's still nowhere near "exponential". No, Sir.

Of course, brute-forcing a block cipher is an embarrassingly parallel task, so you can just use a cluster of processors. But that's where energy comes into play, again (we've had that one already). Besides, if you grow the number of processors exponentially, you will also have to find an exponential amount of silicon (which is relatively easy up to some point since silicon is abundant on our planet), but eventually there will be none left (or, assuming you magically get the silicon from "somewhere else" we will all die because mass also increases exponentially, and a black hole will form).

On the other hand, if you are really worried about serious cryptographic backdoors which weaken an algorithm by, say, 40 or 50 powers of two, and if you really think that CPUs will get a thousand times faster every year, and one of the major nations' spy agencies will concentrate all their resources on just you (heck, why? just why?), then it doesn't really cost you much to use a 384-bit or 512-bit key instead.

The common key sizes 128 and 256 were artificially set per NIST requirement, but the vast majority of ciphers would handle a 512-bit key just the same. If nothing else, you can chain two independent "official" 256-bit ciphers each taking an independent key to have a 512-bit total key length.

Using 512-bit keys is completely insane, but the added cost for you is close to zero (which is not true for the attacker).

Or, you can just use a standard block cipher with more rounds. Very few attacks exist that can somewhat weaken a full-round implementation of a block cipher, almost all real attacks only work on severely reduced-round versions. Even one or two additional rounds provide a huge security margin. Again thanks to NIST requirements, and due to performance competition, all commonly known algorithms have an "official" number of rounds which is the minimum that is just good enough. Nothing prevents you from doubling that number. Yes, it will run at half the speed, but half the speed of "about a gigabyte per second" is still very acceptable. For every normal amount of communication, the difference is not measurable.

But, again, if you're afraid that the default algorithms are not strong enough against your attackers, you better buy a good finger insurance.
 


- Make a huge OTP with TRUE random data
- Transmit it using a great public key algorithm


Now the OTP has the same strength as the public key algorithm. You have just thrown away the only advantage that an OTP provides besides all its disadvantages.

In particular, since you invoked the "quantum computers" spectre earlier, using a public key algorithm to protect the OTP makes no sense. As pointed out previously, if anything, a quantum computer could be used to efficiently solve discrete-logarithm-style problems and such. So, while you are afraid of using a block cipher which is not very suitable to a quantum computer (or at least it looks that way... maybe it will turn out to be, ask again in 50 years), you are ready to use public key encryption to protect your OTP, when public key systems are just what a quantum computer is expected of being able to target efficiently.

Now of course, the same consideration about key length applies to public key systems, too. Instead of a 256-bit EC which is roughly equivalent to 128-bit symmetric (or 64-bit with quantum computing), you could just use a 512-bit EC (or 16384-bit RSA). It's somewhat slower (but not really noticeable if you don't need to do ten thousand per second), and it costs very little extra. No problemo.

 

The question that remains is, however, do you really need this? And the answer is no.

Why would anyone want to use their awesome super quantum cracking powers to read your uninteresting private conversations if they can just as well use it to log into the national bank and transfer 500 million onto their private account on the Cayman islands? They might intercept Vladimir Putin's letters to his 22 year old Ukrainian lover and post them on Reddit (or sell them to The Sun), which is also a lot more interesting than reading your stuff. They might send a command to a submarine, telling them to fire a missle at North Korea, just to see what happens. They have so many things that are so much more fun to do.
 

- Have every data transmittion very securely authenticated and integrity-checked

This is something that everybody should do all the time anyway, and it is what the network stack and a secure communication protocol indeed do billions of times for a billion of people every day, as a basic requirement.
 

- Never save data to any hard drive and have it cleared from  RAM after each session

That's what the truly paranoid do just so on a multi-user system your private banking information can't accidentially be leaked to another person using the same computer. Which has kind of a merit, but seeing how data is leaked in reality, it is nonsensical. Getting to personal data (including passwords, birthdays, social security numbers, and PINs) only requires a phone call 95% of the time, most people will happily cooperate.

For pretty much every normal person in every normal scenario, never saving any data (except truly vital stuff like a banking PIN) and wiping RAM is unnecessary (clearing pages before reusing them is a standard feature of all modern operating systems anyway). It's just paranoia, in a pathological sense. Nobody is going to break down your door, pour liquid nitrogen over your computer as you're pulling the power plug, and do a memory dump. And if that happens, you have bigger problems.

 

Unless of course you are the head of a terror cell and you have been trained to withstand torture for a week, and your terrorist buddies will attempt to kill the president within that time, so it's vital for you that the only copy of the plan that exists is within your head. Well, good luck with that.

But if that is really the case, you should not use a computer in the first place. You should meet under a dark bridge and exchange data on rice paper, and then eat the piece of paper. And you should shoot the other guy because you can't trust him to keep the secret.




#5226308 Random Number Generation

Posted by samoth on 29 April 2015 - 12:30 PM

it will be encrypted, sent to a user over the Internet, then decrypted by that user. The data will be sent in real time and not stored on any hard drive. I have a method of sharing the key and that shouldn't be an issue.

How shouldn't sharing a key be an issue? This is exactly the issue biggrin.png

 

You either have to give a physical copy to the user personally (say, on an USB stick), or transmit the key over the network. The former case is not realistic, and sending the USB stick by mail is as insecure (indeed, I daresay much more insecure) as using an established crypto algorithm. Transmitting the key over the network in some way (maybe as part of the executable, or using whatever method) makes the OTP system as secure as the security protocol used to transmit the key (that is, as good as TLS if you use TLS, or as good as nothing if you don't use encryption).

 

You mentioned something like "many megabytes" somewhere at the beginning, so this is not trivial either. Plus, do note that every single user must have his individual key, otherwise the OTP is trivially exploitable by xor-ing two users' messages. So you need huge amounts of random, huge huge.

 

A: if you wait a few years/decades, who knows what kind of computing technology will be available, which might be able to crack it in a day!

 

No. Please be aware that 2256 is roughly 1077. A present day computer will not just be unable to execute that many instructions (and decrypting a block takes a few dozen instructions at least) in your lifetime, nor in any other person's lifetime. Or during the probable existence of humankind.

It takes roughly 1060 years to do that, and even assuming that a miracle happens and computers get a billion times faster over night and a billion attackers conspire against you, each using a billion of these supercomputers, it still takes 1033 years. Heck, the entire universe isn't 1033 years old! This is not realistic.

 

And then, consider how much energy is needed for this. Executing instructions costs energy, you can find an evaluation based on a hypothetical ideal computer running at close to zero Kelvin in Schneier's book (which points out that brute-forcing 256 bit keys is impossible even with that theoretical machine). Realistically, you can't expect to get more than 5,000 MFLOPS per Watt out of the best, most energy-efficient computers. Now assume that checking one key can be done in the equivalent of one FLOP (very unrealistic, but feel free to assume that anyway) and assume a technology breakthrough happens so you're a billion times more energy-efficient.

 

Do your math, and you will see that in order to brute-force a single 128-bit key within the lifetime of your grand-grand children, your attacker needs a power source that is approximately equivalent to all power plants in the USA. That's for one key. One.

 

Now, unless you are the most important person in the world (are you?) this one key that they might hypothetically try to crack will definitively not be yours. Realistically, they won't crack anyone else's key either.

 

Really, this "wrench attack" comic is no joke. Why would someone spend the major part of a nation's resources and decades of time if they can just cut off your small finger? Once the knife is onto your ring finger, you will happily tell them where to find the key. And surprise, it didn't cost a lot.

You think this won't happen? Then whatever secret you have is not valuable.

 

 

Quantum computing

 

Oh yes, the dreaded quantum panacea. Mr. Worf, quantum torpedoes! Fire!

 

Maybe this is going to happen, maybe it isn't. Someone builds this huge quantum computer, and has nothing better to do than try and decode your super secret data (really, how important are you? Do you realize how much a large-scale quantum computer costs?).

 

Having "quantum super powers" at hands means that they can solve some (but not all, it is rather unlikely that this will work for a block cipher) hard problems in a time that has an exponent half as big as before. So... it's 2128 instead of 2256. Hypothetically, but not likely. Now, 2128 is still pretty good. It's still impractical by all means. It is still way cheaper to waterboard you or to cut off a few fingers to find out your key, if whatever you have is important.

 

Some algorithms are deliberately given a back door, for the public to only discover too late

[...]

The NSA did this to a particular example, of which I just can't recall the name at the moment.

 

The particular examples would be DES (which was however well-known for decades and for the most part regulated by export laws) and IDEA where the backdoor was not built into the algorithm, but into the crypto boxes that were sold to end users. The algorithm remains unbroken. This backdoor is very similar to the previously mentioned wrench attack insofar as it attacks you (the guy who is stupid enough to buy a tampered crypto box) instead of the algorithm.

 

None of that is relevant for using any of the well-tested modern algorithms. But even so, if you are worried, you can still encrypt your data twice with two algorithms. This pretty much rules out that any single backdoor will allow anyone to decrypt your stuff easily.

 

The risk of unintentionally building your own little backdoor into your homebrewn super awesome crypto is a lot higher than the possibility that something that significantly threatens your secrets is found in an algorithm like Rijandel or Twofish.

 

There are trojans that can infect millions of computers worldwide

What about the trojans that infect your computer to reveal the super secret uncrackable key? Or the trojans that infect your computer to send them the already decrypted data in plaintext?




#5226253 Random Number Generation

Posted by samoth on 29 April 2015 - 08:25 AM

I don't intend to use any overly complex protocols anyway.
Yet you want to use the most complex, most annoying, and most troublesome and error-prone protocol in existence. One-time pad key generation and management is a nightmare. It's what makes one-time pads impractical.

 

Get real. I've been smoking the same weed in the late 1980s. It was when the kool kids exchanged mail via UUCP (or other stone age technologies like Fido and what they're all called). Yes, I'm talking about the time when you were cool if you owned a 1200 bps modem. Not like anyone had anything interesting to say, or that they couldn't have used the phone to talk to people who went to the same school and lived in the same town, but that just wasn't cool. Not like any other person would reasonably have had any interest in anything that anyone from our group had to say anyway.

 

So, all of us being security experts, we used one-time pads to protect our messages. At first, we used a moderately complex homebrew substitution cipher (basically 4 interleaved binary rot13-variants with a different offset each) with incremented each offset with every character encoded to hide patterns. This one delivered surprisingly well for such a naive approach (except the key length was, well, 32 bits...). But being security experts, we figured that this was not good enough. Someone came up with one-time pads, which sounded really cool, so we used that. We distributed the one-time pad (which, lacking a truly good random number generator, probably was not much of a one-time pad, although we tried to make it as good as we could) on CD-writeables.

 

It was the time when a CD writer would cost a fortune and writeable CDs weren't precisely cheap either, but sure enough, all the kool kids had a burner. Burning a CD required a powerful computer with a lot of RAM, and burning took like half an hour during which you could do nothing else on that computer (if you were wise, you wouldn't even touch the mouse!), and one of three CDs came out broken, either thanks to buffer underrun or for no particular reason, or just because CD writeables suck.

So, for a group of 8 people, you wasted a week generating a disk full of kinda-real-random data (much like you would leave the computer on over night just to raytrace a 320*200 scene of a few transparent marbles on an infinite plane) and a complete afternoon burning CDs. And then you had to meet in person to distribute a copy to everybody. We didn't opt for meeting under a bridge like in a spy novel.

 

Guess what happened a few months later. Hint: recordable CDs are not as robust and error-free as you might wish. And yeah, people do lose them and roll office chairs over them, too.

 

In one word, from a usability perspective, one-time pads are just "WTF".

 

On the other hand, established algorithms (say, Twofish or AES, if you will) with a reasonable key length (128 bits, or 256 if you are really paranoid) are easy to manage, reliable, and are just as secure.

 

This is quite comparable to taking a photograph. Something at 20 meters distance is "infinite", and moving it further away still only makes it "infinite". It is unfeasible (and, above all, economically forbidding) to break a 128-bit key, and it is simply impossible (with our present understanding of the universe) to break a 256-bit key. A 16384-bit or 4294967296-bit key is equally impossible to break, and a 2MB one-time pad is also impossible to break. There is, however, no difference between "impossible" and "impossible". The difference is only in the ease of handling.




#5226148 Random Number Generation

Posted by samoth on 28 April 2015 - 02:49 PM

Using a one-time pad is just ridiculous. Yes, it's provably unbreakable, so what. It's also completely impractical.

 

Every well-known, mainstream algorithm such as Rijandel with a key length of 128 or more bits is unbreakable, too. No single secret that you may own can possibly be so valuable that anyone will invest the computional resources needed to break a 128-bit key. Seriously.

 

(Also, the wrench attack pointed out by BitMaster is more real than you may think, for things which are sufficiently valuable.)




#5226122 Is it necessary to license your game?

Posted by samoth on 28 April 2015 - 12:19 PM

Apologies if i may have conveyed my words the wrong way, It merely confused me earlier when the composer vaguely asked for me to license my game for a reason i couldn't understand.
Well, the thing is that what you've been doing is totally illegal. The question is not about licensing your game, but about licensing the stuff that you use in your game.

 

You probably didn't mean any harm, but that doesn't make a difference. Not meaning any harm doesn't protect you from prosecution. You've been lucky since you neither went to jail nor did you have to pay 50 million in damages. Either way, your composer friend's advice is a truly good one. You should most definitively license what you use (or only use freely available material, or generate it yourself).

 

Copying a few sounds or images looks like a crime without victim and is easy enough to do (and it really doesn't hurt anyone, does it?), but  it is a thing that can easily screw up your entire life and get you into a situation where you can just as well buy a piece of rope and hang yourself. Don't risk that.




#5226118 Random Number Generation

Posted by samoth on 28 April 2015 - 12:07 PM


How can it be cryptographically secure if iy's only pseudo-random? That doesn't sound secure at all!

The way this works is, you append some kind of entropy which you can collect from many sources (like, for example, nanoseconds since last received network packet) to a buffer, and run a secure hash function over it, which causes an avalanche effect on the input bits, creating a "more random looking" output. This can be repeated many times, with new entropy being added or no new entropy being added. In the latter case, the output will be merely pseudorandom, but it is still "cryptographically secure" insofar as there is no straightforward way of predicting the output.

If true random entropy is being added continuously, the output remains "truly random" (to some extent, it is only truly random if the number of entropy bits added is equal or higher than the number of bits you pull from the generator, but in every practical respect, it's "truly" random if you pull a lot more anyway, you won't be able to show a difference).

 

 

 


Are you kidding me? That websites limits it to 16k? WTF am I supposed to do with 16k?!

No kidding, generating 16k true random numbers is very hard. And, nobody really needs that much random data.




#5225844 Is it necessary to license your game?

Posted by samoth on 27 April 2015 - 08:08 AM

Clarification is needed. Your composer tells you to license your game, and you didn't do that with your previous one.

 

That means that you made a game and...

  • didn't show it to anyone? That is, you did not publish/distribute it?
  • gave it away for free, and didn't make mention of a license?
  • sold it, but didn't specify a license?
  • something different?

Or, the composer wants you to buy a license for the music he made for you?

 

 

These are all very different things. Some are more harmless, some are mostly harmless, and some are outright troublesome.

 

For example, simply not distributing your game is harmless, it's just a shame you made it and nobody gets to see it.

 

Distributing a game for free without a license is "mostly" harmless. For the most part, no evil things will happen except you don't get any money (which you didn't ask for anyway) and people can do just what they want with your software (they can, and will, do what they want anyway, so who cares!). Be however aware that it is still possible to ask for damages (for moronic reasons such as fitness for an implied use, and for other more valid reasons) in some countries with cowboy laws, even if you gave it away for free. Which means in the most extreme, most perverse possible case, someone might infringe you for causing that meltdown in the city's nuclear powerplant because everybody was busy playing your pong game instead of responding to blinking red lights. Or a car driver might blame an accident on you because he was too busy looking at his phone with your game on it.

 

Now, selling a game without a license (or rather, selling the game) is another thing. This is very bad. You do not normally sell software, never, not ever (well, except when a big $$$ company buys it from you). Instead, you sell a license, which is a limited (usually non-exclusive) right to use that software. Use, not own.

This is usually explicitly stated in the lengthy lawyerese of the license agreement, and often part of the "by doing XYZ you agree..." clause on the sticker on the shrinkwrap (or above the download link), too.

 

If you don't do that, someone might argue that they bought the software (that is, all rights to it) instead. Which, although every sane person would agree that this is nonsensical, is technically true. Now, in states with cowboy laws, this would allow someone to successfully draw you to court (and win the lawsuit) because you later sold the game (which you no longer owned) to someone else.




#5225804 Reusing abandoned trademarks?

Posted by samoth on 27 April 2015 - 04:44 AM

® style marks have lots of paperwork and fees and procedures.

That may be different in the USA, but in the EU it's surprisingly straightforward and easy (done that once 10-12 years ago, no lawyer involved).

 

You go to your country's patent office's website (DPMA in my case), fill out a form with your name and address and the mark you want, and decide for the Nice classes etc, etc, and then you need to pay a fee (I don't quite remember, but I think it was something like 200 Euros).

 

You'll get confirmation mail from the EUPTO (on paper) some 5-6 weeks later, followed by spam from the USPTO a few weeks later who will offer you to also file a mark for the USA at a ridiculous price (I don't remember exactly, but I think it was something like 1,500-2,000 USD). If you just ignore the spam, and if there are no objections from someone who already owns or has filed the same mark registered in another or the same Nice class within some time (I think a month or so?), the mark is yours. Simple as that.

 

You will get spam again 5 years later and 10 years later from dubious "mark renewal service" companies which offer to renew your mark for only 5,000 or so Euros (again, you can safely ignore that and do it yourself for a fraction of the price. Also note that you need not renew it after 5 years at all, the term is 10 years -- don't ask me why you're being offered to do that, they probably think you're stupid or something).




#5225801 c++ shared_ptr usage

Posted by samoth on 27 April 2015 - 04:28 AM

What you are doing can be very advantageous if you plan to move the loop calling functionThatUsesA to another thread later. The shared pointer has shared ownership of the object, so it will keep the object alive for as long as it lives. Which means that if thread 1 fires off thread 2 to do that work and then decides that it no longer needs the resource, it needs not pay attention to synchronize with whoever might need it -- there will be no funny stuff happening with thread 2 accessing an object that doesn't exist any more.

 

On the other hand, if you are writing strictly serial code (as I am inclined to believe from what I've read) then the shared pointer is unnecessary. It's technically correct, but you don't need it. You can guarantee that the pointer will always be valid anyway, so a raw pointer will do, too. From a purely semantic point of view, however, one shouldn't use a shared pointer, if sharing ownership isn't what you mean to express.

 

As to storing as member versus passing as argument, passing a pointer as function argument costs very little if anything. With any luck, the call is inlined anyway, or the parameter is "passed" by re-coloring (is that the right word?) a register so the net overhead is zero. Reading a member from memory may very well be slower than passing the parameter (though most likely it will be in L1 if the compiler isn't smart enough to optimize that out anyway).

 

Using a shared pointer would be rather unwise if you were passing it with every iteration (which you're not doing, luckily). You need to be aware that passing a (non-reference) shared pointer will increment the reference count, and the function returning will decrement it, both being atomic operations.

 

These are not "free" operations, and this can be something that may affect performance, even more so if you have used make_shared. It is usually recommended to use make_shared since that allocates the reference count and the object in one block, which is an optimization (both in memory and runtime). However, on the other hand, an atomic operation is not just somewhat slower, but also invalidates the accessed cache line, which basically means if your object lives together with the ref count, you have a guaranteed cache miss the first time you access the object after passing the shared pointer. Which doesn't matter if you do it a hundred times per frame, but it greatly matters if you do it ten thousand or a hundred thousand times.




#5224829 Inter-process Semaphores in Windows?

Posted by samoth on 22 April 2015 - 04:46 AM

Why so complicated? You can simply use CreateSemaphore (no Ex). Provide a name (any kind of string, really... although there is a recommended naming scheme it doesn't really make much of a difference as long as your name doesn't collide with something different). Win32 semaphores are kernel objects that always work inter-process (just like a Win32 mutex, too).

 

Unless you have a seriously unhealthy situation on your system, like a billion handles open or such, CreateSemaphore will always succeed and return a handle. Now, this may be a new semaphore, or an existing one (if the name already existed), and you would like to know which one it is. If the name already existed, calling  GetLastError immediately after CreateSemaphore returns ERROR_ALREADY_EXISTS (which is not an error!).

 

So, there is not much need for anything more complicated. For security attributes, you can just pass NULL (that gives default security attributes). The handle cannot be inherited if security attributs are NULL, but it can be opened from someone else with the same security token. So, as long as your two processes run under the same effective user, there is never a problem.

 

I would recommend against OpenSemaphore (or any Open... functions in that context) since the sequence of operations is not atomic. You may have OpenSemaphore fail, so consequentially you assume no other process is running and create a new one, but in the mean time another process creates this semaphore. There's a race condition here.

 

It's better to just create a semaphore (which is a single atomic operation) which always succeeds but may report ERROR_ALREADY_EXISTS. In either case, you know exactly what's going on. No possibility of a race.




#5224642 Write ToLower As Efficient, Portable As Possible

Posted by samoth on 21 April 2015 - 02:22 AM

The character is in the Unicode specification so you should be prepared to handle it if you're dealing with Unicode text.
That only shows (once again) how useless Unicode is in practice. Look, it's not just that BitMaster and me happen not to be very familiar with that character, it simply doesn't exist in practice. I've shown this character to about a dozen people between 30 and 70 in my neighbourhood and not one of them took me for serious, they all thought I was joking. There's no way of typing it on a German keyboard either (well, short of using an Alt+numpad code).

 

This article from 2014 even argues that strictly according to the "new writing reform" (which isn't so new anyway), using ß in street names at all is entirely wrong anyway, since the reform mandates ss.

 

Maybe some nutjob made that capital-ß up for April's fool, then three or four other nutters tried to make it "fashionable" without success, and finally the Unicode consortium took it into their standard because someone had smoked weed and still deemed it useful. And since then it's "official". Or something.

 

There exists indeed at least one "real, no-joke" site (which is a Hessian community driven online newspaper) that I could find which uses that letter in their name (Gießener Zeitung) but they are being mocked (even on German typesetting sites) for being "proudly identifying themselves by being the only ones using ß-versal". Also, funnily, note how their URL is written (IDN anyone?). Imagine visitors having to type that letter biggrin.png 

 

I could also find a Bavarian newspaper from 2008 which says "yeah, this is no joke, typographers are trying to push this" as well as "the DDR had that on the cover of their great lexicon in the '50s already, but it didn't get accepted" (though the photos that I could find seem to suggest that isn't true). They also mock the fact that "all keyboards will have to be replaced".

 

Anyway, being a valid code point in Unicode is of course an issue because someone might use it, but as often with Unicode, it's merely an annoyance and a mostly theoretical problem, not a really practical one.

 

A lot of things in Unicode do not make a lot of sense. Heck, there's languages in the BMP which aren't spoken by any living person since a thousand years or which only appear in ancient religious texts of some minority which most people never heard of, and those symbols have lower code points than one very major language which is spoken by two million people every day. Seeing how higher code points encode in more symbols both in UTF-8 and UTF-16, this is nonsensical. Don't even get me started on normalization and things like "numbers in circles" or "small letters" or the varieties of superscript (heck, that's markup, who needs extra symbols for that?) in fear of going totally OT rolleyes.gif

 

The point is that case mapping characters is non-trivial so the correct result depends a lot on what you want to achieve.
That, however, is very true. It's not just non-trivial, it's annoyingly complex (and getting worse with every year).


#5223528 PerfectMMORPG

Posted by samoth on 15 April 2015 - 03:06 PM


My first game allowed players to make there character by changing sliders, very similar to the way MakeHuman works or the one in Mount&Blade. People hated how long it took before thy where done, when I gave them preset characters thy hated the limited choices, with editors thy complained that it was too hard.
Classic! An apparent 50% of the players (really only the most vocal 5%) complain, no matter what you do. And if you listen to them, the other 50% (who not rarely are the exact same people as before) will complain. biggrin.pngbiggrin.pngbiggrin.png

 

"There shall in that time be rumors of things going astray, erm, and there shall be a great confusion as to where things really are, and nobody will really know where lieth those little things with the sort of raffia-work base, that has an attachment. At that time, a friend shall lose his friend's hammer, and the young shall not know where lieth the things possessed by their fathers that their fathers put there only just the night before, about eight o'clock."

(source)

This topic written for professional coders. You may not understand it.
[...]
So i am right. And i will be always right. If you didnt understood my game than dont talk about it.

The combination of a lot of confusing or confused information (at least it seems to be perceived that way by a lot of people here) with statements that are, well, I shall say unintentionally provokative is unlikely to result in a lot of helpful replies.

Telling people things like "this is for professional coders, you may not understand it" and "I'm always right" bears a message that is most probably not well received.

 

Maybe you want to elaborate a few points in more detail, but less personally (so people actually understand what you are talking about, and you don't piss them off from the beginning). Let's first get some facts together, and then tell us what your question is. (Did you ask one?)

 

For example, I have difficulties understanding your triangular number thingie. You said that I don't understand triangular numbers, that's not true but let's just assume that is indeed the case: So you have an "obscure" magical sequence of numbers of which you have collected the first 10.000 or so. They are numbers like 0, 1, 3, 6, 10, 15, 21, 28, 36, 45, 55 etc. and for some reason you assume that you get a diminuishing returns system out of that, and this system is better than easier existing systems. How so? Why would one choose exactly this system?

 

Also, the jump from 1 to 3 is very clearly smaller than the jump from 45 to 55, so advancing one step at a higher level increases speed a lot more (unless there is a reciprocal in there, or something... this is the kind of information that people will need to understand what you're talking about). Insofar, it looks like you're contradicting yourself there.






PARTNERS