How can following two statement be the same?
(1) using System.l1001
(2) using System.Globalization;
That is, how does the compilier know these two representations, at the using
declaration level, are the same?
Thanks.
22  1399 
anon <an**@hotmail.com> wrote: How can following two statement be the same?
(1) using System.l1001
(2) using System.Globalization;
That is, how does the compilier know these two representations, at the using
declaration level, are the same?
It doesn't, as far as I know. Do you have an example which leads you to
suspect that they are the same?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: How can following two statement be the same?
(1) using System.l1001
(2) using System.Globalization;
That is, how does the compilier know these two representations, at the using
declaration level, are the same?
It doesn't, as far as I know. Do you have an example which leads you to
suspect that they are the same?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
It's from an Obfuscation example. I want to know how this is possible in
the first place.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: How can following two statement be the same?
(1) using System.l1001
(2) using System.Globalization;
That is, how does the compilier know these two representations, at the
using declaration level, are the same?
It doesn't, as far as I know. Do you have an example which leads you to
suspect that they are the same?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
It's from an Obfuscation example. I want to know how this is possible in
the first place.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: How can following two statement be the same?
(1) using System.l1001
(2) using System.Globalization;
That is, how does the compilier know these two representations, at the
using declaration level, are the same?
It doesn't, as far as I know. Do you have an example which leads you to
suspect that they are the same?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: It's from an Obfuscation example. I want to know how this is possible in
the first place.
Unless the obfuscator is also obfuscating the system libraries, I don't
see how those two *are* going to be equivalent.
Of course, the obfuscator could have decided to change all namespaces
to System.XXX in order to confuse people - in which case it's worked!
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: It's from an Obfuscation example. I want to know how this is possible in
the first place.
Unless the obfuscator is also obfuscating the system libraries, I don't
see how those two *are* going to be equivalent.
Of course, the obfuscator could have decided to change all namespaces
to System.XXX in order to confuse people - in which case it's worked!
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do this. http://www.semdesigns.com/Products/O...onExample.html
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: It's from an Obfuscation example. I want to know how this is possible
in the first place.
Unless the obfuscator is also obfuscating the system libraries, I don't
see how those two *are* going to be equivalent.
Of course, the obfuscator could have decided to change all namespaces
to System.XXX in order to confuse people - in which case it's worked!
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do this. http://www.semdesigns.com/Products/O...onExample.html
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: It's from an Obfuscation example. I want to know how this is possible
in the first place.
Unless the obfuscator is also obfuscating the system libraries, I don't
see how those two *are* going to be equivalent.
Of course, the obfuscator could have decided to change all namespaces
to System.XXX in order to confuse people - in which case it's worked!
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do this.
http://www.semdesigns.com/Products/O...onExample.html
They basically can't, as far as I can tell - not without also providing
an obfuscated version of the system libraries themselves. If they've
done that, then that's a different matter. Not that creating obfuscated
*source* code is a particularly useful thing anyway, IMO. They've said
how clever they are for removing line breaks, converting text using
\uxxxx format etc - all of which is pointless when, for the most part,
obfuscation is used for *binaries*, not source: just compiling and then
decompiling would remove all the protection there apart from the name
changes.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do this.
http://www.semdesigns.com/Products/O...onExample.html
They basically can't, as far as I can tell - not without also providing
an obfuscated version of the system libraries themselves. If they've
done that, then that's a different matter. Not that creating obfuscated
*source* code is a particularly useful thing anyway, IMO. They've said
how clever they are for removing line breaks, converting text using
\uxxxx format etc - all of which is pointless when, for the most part,
obfuscation is used for *binaries*, not source: just compiling and then
decompiling would remove all the protection there apart from the name
changes.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Do you think these guys know something we don't know? At least for changing
the names to system classes?
But in regards to obfuscating source code, let's say if you did compile it
and then decompiled it.
The decompiled version would like or be similar to the source code which
would be obfuscated anyway.
The name changes would be, at least to me, a somewhat considerable hurdle to
figure out or use the source code in the first place. You would have only a
glimmer of an idea of what the source code did as you could not read that
anyway.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: This is where I saw it. So I looked and I saw they started to change
the names at the system level and then I said, how did they manage to do
this. http://www.semdesigns.com/Products/O...onExample.html
They basically can't, as far as I can tell - not without also providing
an obfuscated version of the system libraries themselves. If they've
done that, then that's a different matter. Not that creating obfuscated
*source* code is a particularly useful thing anyway, IMO. They've said
how clever they are for removing line breaks, converting text using
\uxxxx format etc - all of which is pointless when, for the most part,
obfuscation is used for *binaries*, not source: just compiling and then
decompiling would remove all the protection there apart from the name
changes.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Do you think these guys know something we don't know? At least for changing
the names to system classes?
But in regards to obfuscating source code, let's say if you did compile it
and then decompiled it.
The decompiled version would like or be similar to the source code which
would be obfuscated anyway.
The name changes would be, at least to me, a somewhat considerable hurdle to
figure out or use the source code in the first place. You would have only a
glimmer of an idea of what the source code did as you could not read that
anyway.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: This is where I saw it. So I looked and I saw they started to change
the names at the system level and then I said, how did they manage to do
this. http://www.semdesigns.com/Products/O...onExample.html
They basically can't, as far as I can tell - not without also providing
an obfuscated version of the system libraries themselves. If they've
done that, then that's a different matter. Not that creating obfuscated
*source* code is a particularly useful thing anyway, IMO. They've said
how clever they are for removing line breaks, converting text using
\uxxxx format etc - all of which is pointless when, for the most part,
obfuscation is used for *binaries*, not source: just compiling and then
decompiling would remove all the protection there apart from the name
changes.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon wrote: This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do this.
http://www.semdesigns.com/Products/O...onExample.html
it's hard to know what they're doing in the example, but there are a
couple of comments that I think I can make:
1) using statements (of the namespace sort) do not get compiled down to
IL - they're used by the C# compiler to make dealing with nested
namespace names more convenient. However, the emited IL always deals
with the full typenames, so I'm not sure how a decompiler would generate
using statements, except by noting which nested namespaces are used in
the entire assembly and emitting a using statement for some or all of
those. In this case, the using statements would not magically appear in
the same order in the decompiled source as they were in the original
source as they seem to do in the example.
2) More importantly, there are no types from the System.Globalization
namespace being used in the example. If no types from that namespace
are used, then the decompiler would be free to put pretty much any
namespace it wanted in place of "using System.Globalization;". However,
I'm at a loss as to why it would decide to do anything with
System.Globalization if no types from that namespace are used.
Looking at the example some more, I notice that the following namespaces
get renamed:
antlr
antlr.collections
System.Globalization
System.IO
These seem to correspond to the namespaces that don't actually get used.
That would explain why they can rename those namespaces, but it
doesn't explain why they'd have anything at all for those namespaces in
the decompiled code. Maybe I'm mistaken in my point #1, but I don't
think so.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
anon <an**@hotmail.com> wrote:
It's from an Obfuscation example. I want to know how this is possible
in
the first place.
Unless the obfuscator is also obfuscating the system libraries, I don't
see how those two *are* going to be equivalent.
Of course, the obfuscator could have decided to change all namespaces
to System.XXX in order to confuse people - in which case it's worked!
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
--
mikeb
anon wrote: This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do this.
http://www.semdesigns.com/Products/O...onExample.html
it's hard to know what they're doing in the example, but there are a
couple of comments that I think I can make:
1) using statements (of the namespace sort) do not get compiled down to
IL - they're used by the C# compiler to make dealing with nested
namespace names more convenient. However, the emited IL always deals
with the full typenames, so I'm not sure how a decompiler would generate
using statements, except by noting which nested namespaces are used in
the entire assembly and emitting a using statement for some or all of
those. In this case, the using statements would not magically appear in
the same order in the decompiled source as they were in the original
source as they seem to do in the example.
2) More importantly, there are no types from the System.Globalization
namespace being used in the example. If no types from that namespace
are used, then the decompiler would be free to put pretty much any
namespace it wanted in place of "using System.Globalization;". However,
I'm at a loss as to why it would decide to do anything with
System.Globalization if no types from that namespace are used.
Looking at the example some more, I notice that the following namespaces
get renamed:
antlr
antlr.collections
System.Globalization
System.IO
These seem to correspond to the namespaces that don't actually get used.
That would explain why they can rename those namespaces, but it
doesn't explain why they'd have anything at all for those namespaces in
the decompiled code. Maybe I'm mistaken in my point #1, but I don't
think so.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
anon <an**@hotmail.com> wrote:
It's from an Obfuscation example. I want to know how this is possible
in
the first place.
Unless the obfuscator is also obfuscating the system libraries, I don't
see how those two *are* going to be equivalent.
Of course, the obfuscator could have decided to change all namespaces
to System.XXX in order to confuse people - in which case it's worked!
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
--
mikeb
mikeb wrote: anon wrote:
This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do
this.
http://www.semdesigns.com/Products/O...onExample.html
it's hard to know what they're doing in the example, but there are a
couple of comments that I think I can make:
1) using statements (of the namespace sort) do not get compiled down to
IL - they're used by the C# compiler to make dealing with nested
namespace names more convenient. However, the emited IL always deals
with the full typenames, so I'm not sure how a decompiler would generate
using statements, except by noting which nested namespaces are used in
the entire assembly and emitting a using statement for some or all of
those. In this case, the using statements would not magically appear in
the same order in the decompiled source as they were in the original
source as they seem to do in the example.
2) More importantly, there are no types from the System.Globalization
namespace being used in the example. If no types from that namespace
are used, then the decompiler would be free to put pretty much any
namespace it wanted in place of "using System.Globalization;". However,
I'm at a loss as to why it would decide to do anything with
System.Globalization if no types from that namespace are used.
Looking at the example some more, I notice that the following namespaces
get renamed:
antlr
antlr.collections
System.Globalization
System.IO
These seem to correspond to the namespaces that don't actually get used.
That would explain why they can rename those namespaces, but it doesn't
explain why they'd have anything at all for those namespaces in the
decompiled code. Maybe I'm mistaken in my point #1, but I don't think so.
I see now that the obfuscator is not obfuscating compiled IL, but
obfuscating directly from the source. As noted by Jon Skeet, that's not
a particularly useful thing to do. I guess it gets you a certain level
of obfuscated names in any assembly compiled from the obfuscated source,
but the tricks they pull with using \uXXXX encoded characters won't buy
a single thing once compiled.
However, it does explain how they can rename get the using statements.
It's a simple as:
The namespaces are not used, so they can rename them however they want.
To get the obfuscated source to compile, they would need to provide a
namespace somewhere that the compiler can match up with or there's a
compiler error. There doesn't need to be anything useful in that
namespace, however.
One thing that I am still curious about is that they rename the
Hashtable class. This causes a compiler error. I believe that this is a
mistake in their obfuscation example. Hashtable should have been
included in the list of public items that should not be renamed.
....<snip>...
--
mikeb
mikeb wrote: anon wrote:
This is where I saw it. So I looked and I saw they started to change the
names at the system level and then I said, how did they manage to do
this.
http://www.semdesigns.com/Products/O...onExample.html
it's hard to know what they're doing in the example, but there are a
couple of comments that I think I can make:
1) using statements (of the namespace sort) do not get compiled down to
IL - they're used by the C# compiler to make dealing with nested
namespace names more convenient. However, the emited IL always deals
with the full typenames, so I'm not sure how a decompiler would generate
using statements, except by noting which nested namespaces are used in
the entire assembly and emitting a using statement for some or all of
those. In this case, the using statements would not magically appear in
the same order in the decompiled source as they were in the original
source as they seem to do in the example.
2) More importantly, there are no types from the System.Globalization
namespace being used in the example. If no types from that namespace
are used, then the decompiler would be free to put pretty much any
namespace it wanted in place of "using System.Globalization;". However,
I'm at a loss as to why it would decide to do anything with
System.Globalization if no types from that namespace are used.
Looking at the example some more, I notice that the following namespaces
get renamed:
antlr
antlr.collections
System.Globalization
System.IO
These seem to correspond to the namespaces that don't actually get used.
That would explain why they can rename those namespaces, but it doesn't
explain why they'd have anything at all for those namespaces in the
decompiled code. Maybe I'm mistaken in my point #1, but I don't think so.
I see now that the obfuscator is not obfuscating compiled IL, but
obfuscating directly from the source. As noted by Jon Skeet, that's not
a particularly useful thing to do. I guess it gets you a certain level
of obfuscated names in any assembly compiled from the obfuscated source,
but the tricks they pull with using \uXXXX encoded characters won't buy
a single thing once compiled.
However, it does explain how they can rename get the using statements.
It's a simple as:
The namespaces are not used, so they can rename them however they want.
To get the obfuscated source to compile, they would need to provide a
namespace somewhere that the compiler can match up with or there's a
compiler error. There doesn't need to be anything useful in that
namespace, however.
One thing that I am still curious about is that they rename the
Hashtable class. This causes a compiler error. I believe that this is a
mistake in their obfuscation example. Hashtable should have been
included in the list of public items that should not be renamed.
....<snip>...
--
mikeb
anon <an**@hotmail.com> wrote: Do you think these guys know something we don't know? At least for changing
the names to system classes?
But in regards to obfuscating source code, let's say if you did compile it
and then decompiled it.
The decompiled version would like or be similar to the source code which
would be obfuscated anyway.
Well, the decompiled source code wouldn't have the \uxxxx bits in when
they're not needed, and it would have appropriate line breaks. For
instance, here's a similar program to the one they were talking about,
but done by hand:
using System;class \u0051{static void \u004d\u0061\u0069\u006e()
{\u0043\u006f\u006e\u0073\u006f\u006c\u0065.\u0057 rite\u004cine
("\u0048\u0065\u006c\u006c\u006f");}}
(It could be made worse, but that'll do...)
Looks pretty bad, right? Until you run it through a decompiler, which
gives (for the Main method, for instance):
private static void Main()
{
Console.WriteLine("Hello");
}
The only bit of obfuscation left is the class name (Q).
The name changes would be, at least to me, a somewhat considerable hurdle to
figure out or use the source code in the first place. You would have only a
glimmer of an idea of what the source code did as you could not read that
anyway.
Absolutely. Obfuscators renaming code is absolutely great - it's the
extra "features" they're promoting (like putting everything on one
line, changing some of the text to include unicode escapes, etc) which
make no odds in the long run.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: Do you think these guys know something we don't know? At least for changing
the names to system classes?
But in regards to obfuscating source code, let's say if you did compile it
and then decompiled it.
The decompiled version would like or be similar to the source code which
would be obfuscated anyway.
Well, the decompiled source code wouldn't have the \uxxxx bits in when
they're not needed, and it would have appropriate line breaks. For
instance, here's a similar program to the one they were talking about,
but done by hand:
using System;class \u0051{static void \u004d\u0061\u0069\u006e()
{\u0043\u006f\u006e\u0073\u006f\u006c\u0065.\u0057 rite\u004cine
("\u0048\u0065\u006c\u006c\u006f");}}
(It could be made worse, but that'll do...)
Looks pretty bad, right? Until you run it through a decompiler, which
gives (for the Main method, for instance):
private static void Main()
{
Console.WriteLine("Hello");
}
The only bit of obfuscation left is the class name (Q).
The name changes would be, at least to me, a somewhat considerable hurdle to
figure out or use the source code in the first place. You would have only a
glimmer of an idea of what the source code did as you could not read that
anyway.
Absolutely. Obfuscators renaming code is absolutely great - it's the
extra "features" they're promoting (like putting everything on one
line, changing some of the text to include unicode escapes, etc) which
make no odds in the long run.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
see below...
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: Do you think these guys know something we don't know? At least for
changing the names to system classes?
But in regards to obfuscating source code, let's say if you did compile
it and then decompiled it.
The decompiled version would like or be similar to the source code which
would be obfuscated anyway.
Well, the decompiled source code wouldn't have the \uxxxx bits in when
they're not needed, and it would have appropriate line breaks. For
instance, here's a similar program to the one they were talking about,
but done by hand:
using System;class \u0051{static void \u004d\u0061\u0069\u006e()
{\u0043\u006f\u006e\u0073\u006f\u006c\u0065.\u0057 rite\u004cine
("\u0048\u0065\u006c\u006c\u006f");}}
(It could be made worse, but that'll do...)
Looks pretty bad, right? Until you run it through a decompiler, which
gives (for the Main method, for instance):
When you say run it through a decompiler, Is that the very first step?
Or do you mean (1st) compile, then (2nd) decompile?
And which decompiler would you be talking about?
private static void Main()
{
Console.WriteLine("Hello");
}
The only bit of obfuscation left is the class name (Q).
The name changes would be, at least to me, a somewhat considerable
hurdle to figure out or use the source code in the first place. You would have
only a glimmer of an idea of what the source code did as you could not read
that anyway.
Absolutely. Obfuscators renaming code is absolutely great - it's the
extra "features" they're promoting (like putting everything on one
line, changing some of the text to include unicode escapes, etc) which
make no odds in the long run.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
see below...
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... anon <an**@hotmail.com> wrote: Do you think these guys know something we don't know? At least for
changing the names to system classes?
But in regards to obfuscating source code, let's say if you did compile
it and then decompiled it.
The decompiled version would like or be similar to the source code which
would be obfuscated anyway.
Well, the decompiled source code wouldn't have the \uxxxx bits in when
they're not needed, and it would have appropriate line breaks. For
instance, here's a similar program to the one they were talking about,
but done by hand:
using System;class \u0051{static void \u004d\u0061\u0069\u006e()
{\u0043\u006f\u006e\u0073\u006f\u006c\u0065.\u0057 rite\u004cine
("\u0048\u0065\u006c\u006c\u006f");}}
(It could be made worse, but that'll do...)
Looks pretty bad, right? Until you run it through a decompiler, which
gives (for the Main method, for instance):
When you say run it through a decompiler, Is that the very first step?
Or do you mean (1st) compile, then (2nd) decompile?
And which decompiler would you be talking about?
private static void Main()
{
Console.WriteLine("Hello");
}
The only bit of obfuscation left is the class name (Q).
The name changes would be, at least to me, a somewhat considerable
hurdle to figure out or use the source code in the first place. You would have
only a glimmer of an idea of what the source code did as you could not read
that anyway.
Absolutely. Obfuscators renaming code is absolutely great - it's the
extra "features" they're promoting (like putting everything on one
line, changing some of the text to include unicode escapes, etc) which
make no odds in the long run.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: Looks pretty bad, right? Until you run it through a decompiler, which
gives (for the Main method, for instance):
When you say run it through a decompiler, Is that the very first step?
Or do you mean (1st) compile, then (2nd) decompile?
You'd compile first - but typically the only reason for obfuscation is
to protect your binaries anyway. If you don't want people reading your
source code, why give them it in any form to start with?
And which decompiler would you be talking about?
That was using Reflector, but I believe I'd get the same result with
others.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
anon <an**@hotmail.com> wrote: Looks pretty bad, right? Until you run it through a decompiler, which
gives (for the Main method, for instance):
When you say run it through a decompiler, Is that the very first step?
Or do you mean (1st) compile, then (2nd) decompile?
You'd compile first - but typically the only reason for obfuscation is
to protect your binaries anyway. If you don't want people reading your
source code, why give them it in any form to start with?
And which decompiler would you be talking about?
That was using Reflector, but I believe I'd get the same result with
others.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Alexander Eisenhuth |
last post by:
Hallo all there,
maby I don't see the forest because of all that trees, but :
from struct import *
# how can I convert
f = float(0.5)
|
by: Christopher Benson-Manica |
last post by:
I'm wondering about the best way to do the following:
I have a string delimited by semicolons. The items delimited may be in any of
the following formats:
1) 14 alphanum characters
2) 5...
|
by: fooboo |
last post by:
Does anyone know if a easier way (built in function, or something) that
can verify that a string is an alphanumeric number? Here is what I am
doing now:
for(i=0; i < strlen(temp); i++){...
|
by: KA Kueh |
last post by:
Dear all,
I have a requirement to replace the ' character with ASCII character (146)
in C# but it seems that when I do the following the conversion is lost.
char t = Convert.ToChar(146);...
|
by: Senna |
last post by:
Hi,
Have a symmetric encryption method that returns a base64 string. I then get
the hex representation of that string with the code below
public static string Base64ToHex(string input)
{...
|
by: Fred Nelson |
last post by:
Hi:
I'm more than a little confused with this question:
I need to create a char type from the first letter in a string - for
example:
string mystring;
char mychar;
|
by: karthi |
last post by:
hi,
I need user defined function that converts string to float in c.
since the library function atof and strtod occupies large space in
my processor memory I can't use it in my code.
regards,...
|
by: Steve Edwards |
last post by:
Hi,
I'm re-writing some code that had relied on some platform/third-party
dependent utility functions, as I want to make it more portable.
Is there a standard C/C++/stl routine for changing an stl...
|
by: WaterWalk |
last post by:
Hello, I'm currently learning string manipulation. I'm curious about
what is the favored way for string manipulation in C, expecially when
strings contain non-ASCII characters. For example, if...
|
by: news.chi.sbcglobal.net |
last post by:
I have a question about string literals with C++/CLI.
Is there a difference between the following two lines?
String ^s1 = gcnew String("Hello");
String ^s2 = gcnew String(L"Hello");
I have...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
