On 11/21/2014 9:29 AM, Pascal Quantin wrote:
2014-11-21 14:06 GMT+01:00 Semjon <se...@web.de <mailto:se...@web.de>>: Am 21.11.2014 um 10:06 schrieb Guy Harris: > > On Nov 21, 2014, at 12:48 AM, Semjon <semgo-S0/gaf8t...@public.gmane.org <mailto:gaf8t...@public.gmane.org>> wrote: > >> One of my current problems is with >> >> tvb_get_faked_unicode(...) >> >> which isn't available anymore. >> In my Protocol I have some Ascii-encoded String but which comes as two >> bytes per character. Example: >> {0x0031, 0x0032, 0x0033, 0x0034, 0x0000} in tvb should display in >> GUI/Tree/PacketList as "1234" > > If that's truly ASCII-encoded, that would be a significant waste of bytes - you could just use one byte per character for ASCII; if the second byte is always zero, that byte serves no useful purpose. > > So I'll assume it's a *superset* of ASCII, and that you mean either "UTF-16 encoded string" or "UCS-2 encoded string" rather than "ASCII-encoded string which comes as two bytes per character". > > So: > >> I used to call: >> >> tvb_get_faked_unicode(NULL,tvb, 20, ((tvb_length(tvb)-20)/2),ENC_BIG_ENDIAN) >> >> and display result as %s in col_append_fstr() or as FT_STRING in >> proto_tree_add_string(). >> >> So could anyone give me a hint, is there a function still available for >> this type of encoding > > tvb_get_string_enc(tvb, {offset}, {length of string}, ENC_UTF_16|ENC_BIG_ENDIAN) > > or > > tvb_get_string_enc(tvb, {offset}, {length of string}, ENC_UCS_2|ENC_BIG_ENDIAN) > > depending on whether it's UTF-16 (with surrogate pairs to handle Unicode characters that don't fit in 16 bits) or UCS-2 (supporting only characters in the Unicode Basic Multilingual Plane, without surrogate pairs). > > Note that tvb_get_string_enc() returns a UTF-8-encoded string; octet sequences that can't be mapped to UTF-8 strings will be replaced by the Unicode "replacement character". > >> In general is there a fast/convenient way - other than manually looking >> through the sources after functions that might do what i want - to check >> if this function X is now replaced by function Y. > > No. You could check doc/README.developer, etc. to see if anything is mentioned. > >> Other examples I need to replace are: >> abs_time_to_ep_str() > > abs_time_to_str({wmem scope}, ...) > > The old "ephemeral" and "session" memory mechanisms are deprecated in favor of the new wmem mechanisms. The scope that's equivalent to "ephemeral" scope is, I think, packet scope (right, Evan?), so you'd want > > abs_time_to_str(wmem_packet_scope(), ...) > >> nstime_delta() > > Its replacement is called nstime_delta() and has the exact same arguments. :-) > > However, you need to include <wsutil/nstime.h> to get it declared. > Well thanks a lot everybody for helping. I could resolve almost all of my Problems with Your help. In fact the "ASCII encoded 2-byte-string" is a Unicode String shame on me :-) Unfortunately no luck with nstime_delta(). I already had included <wsutil/nstime.h> My call looks like this: proto_item *it; nstime_t ns; it=proto_tree_add_uint(xyz_tree, hf_xyz_response_to, tvb, 0, 0, xyz_trans->req_frame); PROTO_ITEM_SET_GENERATED(it); nstime_delta(&ns, &pinfo->fd->abs_ts, &xyz_trans->req_time); it=proto_tree_add_time(xyz_tree, hf_xyz_response_time, tvb, 0, 0, &ns); PROTO_ITEM_SET_GENERATED(it); It always generates errors LNK2019/LNK1120 ... unresolved external symbol "__imp__nstime_delta" in function ... Hope You have an idea here. I'm not really good in finding the necessary functions/files to include in such a big project and my search on the www on this was not successful. Hi, assuming that your proprietary dissector is a plugin, ensure that your makefile indicates the path to libwsutil. I guess you are on Windows, so your Makefile.nmake file should contain: !IFDEF ENABLE_LIBWIRESHARK LINK_PLUGIN_WITH= ..\..\wsutil\libwsutil.lib CFLAGS=$(CFLAGS)
See plugins\ethercat for a dissector which uses nstime_delta() [in packet-esl.c].
Also: proto.h (#included by packet.h) #includes nstime.h so you need not explicitly include same.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe