Joe[x86] brought up a good question that I'd like to be covered.

Joe[x86]: In 0x09 SID_GETADVLISTEX, is it possible for Conditions 1 and 2 to be a DWORD, and 3 and 4 to be a QWORD, hence 2 and 4 being null? Also, what is sent for the three string fields? Since list count is a DWORD, couldn't you specify to list 0xFFFFFFFF games?

You can read and respond to the discussion via this link.

Or respond in this thread. All the same, we'd like your input.

Anything is possible, but I'd put my money on "that's not the case," since it is totally illogical. Why would they define the packet format to vary the size of a field based on that field's value?

Also, I can't recall any packet that uses QWORDS except for FILETIMEs (and I'd be willing to go out on a limb and say it reads two DWORDs even in that case, since the windows structure is defined as such), so this packet would be quite a silly place to start.

There's a packet that uses QWORDs. I'll have to look for it later. Anyway, I already responded with:
[quote]I don't understand your reasoning behind the DWORD and QWORD values. You're saying combine the two WORDS into a DWORD and the two DWORDS into a QWORD? That's oversimplification, as the values are actually used. Condition 2 and 4 are unknown at this time, and as such, should not be discarded, as they may have uses unknown.

The three string fields are normally blank, unless you wish to search for an exact game. For example, say you want game information on a game called Socks with the password Shoes. You would set Game Name to "socks" and Game Password to "shoes", and it would give you information on the game. If you did not enter a password, the server would give you an "Invalid Game Password" response. Game statstring is the same thing, if you're looking for games that match a certain player. They're for finding specifics instead of generals.

And finally: Yes, you could say to list 4294967295 by specifying 0xFFFFFFFF for the list count. However, I've never seen more than 20 games in any listing anywhere. That's why I say it's safe to use 0xFF.[/quote]

It's only "safe" to do exactly what the client does. Does the client send 0xFF?

I don't know what the client sends.

It'd be pretty stupid to use 64-bit values for options with values of 1, 2, 3, 4, etc.  I would assume that field at one time was used for something else.  It wasn't until later on during War3 (clan/friend messages and stuff) that Blizzard seemed to stop using 32-bit values for everything.