Re: using gzlib from c#
From: Bonj (benjtaylor)
Date: 12/04/04
- Next message: Earl Damron: "Re: Background ops / threading question"
- Previous message: Earl Damron: "Re: Adding key events to a label"
- In reply to: Stefan Simek: "Re: using gzlib from c#"
- Next in thread: Bonj: "Re: using gzlib from c#"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 4 Dec 2004 14:20:21 -0000
>Well, your very funny kind of person.
And? That in itself doesn't make me a bad programmer.
>First, you are going to write your own encryption,
Well no, actually that's where you're wrong. If you'd read the whole of my
recent thread about encryption "how good an encryption algorithm is this"
(100+ posts) you'd have discovered that I was trying to solicit ideas as to
how practicable an idea it was to use my own algorithm, but was convinced
that it wouldn't be a good idea, and decided to use DPAPI instead.
>own compression
The very existence of this thread contradicts that.
> and whatever else, because you think you'll do better than people whose
> products are widespread.
Wrong again. The difference being, that I'm willing to use *some* components
developed by other people that are widespread, but I'm discerning in that I
don't believe that just because a component is widespread, it's
automatically going to be better than my own component. And at the end of
the day, please don't insult my intelligence by claiming that there is
no-one at all out there that's less intelligent than I am or a worse
programmer than I am, that has managed to widely distribute their component,
and therefore that I should put my trust in any component I find in the
internet, safe in the knowledge that because it's made it onto the internet
it *must* be better than anything I could cook up myself.
>On the other hand, you won't use a library because it's only TWO YEARWS
>since people begun to use it?
>
No.
I won't use it because it hasn't successfully proved itself to me in a nice
short time.
Second arrogance: I don't see why I should spend very much of my *own* time
researching some interface or other that is *only* related to a particular
piece of *somebody else*'s work.
Like I say - compression is quite a hard thing to do. And it's not entirely
unfeasible that even very clever people have failed to do it well - I'm not
saying SharpDevelop fit into this category - it might just be the fact that
it was unlucky that I happened to download a bad test project.
And also,
I won't use a library because it's only two years since people began to use
it *when there's an equivalent one that's been around for a lot longer than
two years*.
I'm not one a ".NET snob" - I don't think that all unmanaged code is to be
untrusted because it doesn't have the benefit of a GC and therefore might
succumb to memory leaks. I recognise the benefit of .NET - which is that the
fact that because it's got a GC means you can write code faster - not
necessarily better. If I have to free() / delete stuff that I've malloc'd /
new'd doesn't mean that I'm going to forget to do that just because it's
unessential to the operation of the program, and therefore making the
program worse, it just means that I'm going to have to spend a bit of time
checking that I have made such clean-up calls.
This, and other RAD characteristics of .NET enables you to write complex
functionality in a short time. Since this is a project just for myself, then
I am more than happy to take advantage of .NET for it* - however I
personally feel that using something *just* because it is written in .NET is
a silly decision, and one that would make me a ".NET snob".
You've admitted that you think the only reason why I should use the
SharpDevelop version of the zlib library is so I can have my project purely
in managed code. And I'm answering back by saying the only reason I'm using
the older, unmanaged version of the zlib software is so I can have my
project purely in *good* code.
> Just for fun, I've used the SharpZipLib yesterday for the first time. I've
> made several tests and it didn't fail me even once. It works perfectly for
> anything I could try.
How glib of you. ( I mean, how gzlib of you.)
*If you want to see why I wouldn't use C# for anything I plan to sell, see
http://groups.google.com/groups?q=g:thl2660319408d&dq=&hl=en&lr=&selm=%23WPRkX%24PCHA.2568%40tkmsftngp10
"Stefan Simek" <simek.blah@kascomp.blah.sk> wrote in message
news:%23qIFE9U2EHA.208@TK2MSFTNGP12.phx.gbl...
> My fingers got tied up... ;)
>
> ... *two years* > Stefan
>
> "Stefan Simek" <simek.blah@kascomp.blah.sk> wrote in message
> news:eqqZZ7U2EHA.524@TK2MSFTNGP09.phx.gbl...
>> Well, your very funny kind of person.
>>
>> First, you are going to write your own encryption, own compression and
>> whatever else, because you think you'll do better than people whose
>> products are widespread.
>>
>> On the other hand, you won't use a library because it's only TWO YEARWS
>>
>> "Bonj" <Bonj@discussions.microsoft.com> wrote in message
>> news:B51237DE-AF89-4CBC-9FCA-60FEDDC7F68E@microsoft.com...
>>> In addition, SharpZipLib is developed by "SharpDevelop" - I've tried the
>>> "SharpDevelop" "IDE" before and found it appalling, so I don't actually
>>> trust
>>> anything written by them.
>>> It set up a load of bogus users with random strings as their names, and
>>> made
>>> them owners of its directory structure, I had to fiddle around removing
>>> them
>>> all after I'd uninstalled it. Cygwin did exactly the same thing (only to
>>> its
>>> own directory structure though). (GNU people trying their hand at
>>> Microsoft
>>> stuff? What's that all about anyway?)
>>> And whoever's written "SharpZipLib" - however well they've tried to
>>> convert
>>> it, it can only be a maximum of two years old - as that's how old C# is.
>>> The
>>> unmanaged version looks like it's been around a lot longer than that,
>>> and
>>> seems to have gone through numerous versions and bug fixes.
>>>
>>>
>>> "Stefan Simek" wrote:
>>>
>>>> You can avoid using unsafe code:
>>>>
>>>> [DllImport("zlib1.dll", CallingConvention=CallingConvention.Cdecl)]
>>>> static extern short compress(IntPtr dest, ref uint destLen, IntPtr
>>>> source,
>>>> uint sourceLen);
>>>>
>>>> short compress(byte[] dest, ref uint destLen, byte[] source, uint
>>>> sourceLen)
>>>> {
>>>> // do some checking on null references...
>>>>
>>>> GCHandle hDest = GCHandle.Alloc(dest, GCHandleType.pinned);
>>>> GCHandle hSource = GCHandle.Alloc(source, GCHandleType.pinned);
>>>>
>>>> try
>>>> {
>>>> return compress(hDest.AddrOfPinnedObject(), ref destLen,
>>>> hSource.AddrOfPinnedObject(), sourceLen);
>>>> }
>>>> finally
>>>> {
>>>> hSource.Free();
>>>> hDest.Free();
>>>> }
>>>> }
>>>>
>>>> But I would recommend using the SharpZipLib anyway.
>>>>
>>>> HTH,
>>>> Stefan
>>>>
>>>> "Bonj" <benjtaylor at hotpop d0t com> wrote in message
>>>> news:eLFb5dQ2EHA.1400@TK2MSFTNGP11.phx.gbl...
>>>> > Thanks, that seems to work.
>>>> >
>>>> > "Bonj" <benjtaylor at hotpop d0t com> wrote in message
>>>> > news:eHbitVL2EHA.2180@TK2MSFTNGP10.phx.gbl...
>>>> >>I tried it with
>>>> >> [DllImport("zlib1.dll", CallingConvention=CallingConvention.Cdecl)]
>>>> >> static extern Int16 compress(ref byte[] dest, ref uint destlen,
>>>> >> byte[]
>>>> >> source, int sourcelen);
>>>> >> and it still does the same thing, bombs on the call to that method.
>>>> >>
>>>> >> I also tried it with the return value as int (Int32) and that did
>>>> >> the
>>>> >> same thing aswell.
>>>> >>
>>>> >>
>>>> >> "Bonj" <benjtaylor at hotpop d0t com> wrote in message
>>>> >> news:%23vbXbQL2EHA.3064@TK2MSFTNGP10.phx.gbl...
>>>> >>>I downloaded the gzlib library from zlib in order to do compression.
>>>> >>>(http://www.gzip.org/zlib)
>>>> >>> The prototype of the compression function seems to be
>>>> >>> int compress (Bytef *dest, uLongf *destLen, const Bytef *source,
>>>> >>> uLong
>>>> >>> sourceLen);
>>>> >>> It is meant to be called by C, but I would rather use it from C#.
>>>> >>>
>>>> >>> So I wrote the following C# program to test it, but it failed to
>>>> >>> work.
>>>> >>> The call to compress doesn't return or throw an exception, it
>>>> >>> simply
>>>> >>> bombs the program. I'm probably calling it wrong, but have no idea
>>>> >>> why.
>>>> >>>
>>>> >>> This is the program:
>>>> >>> using System;
>>>> >>> using System.IO;
>>>> >>> using System.Security;
>>>> >>> using System.Runtime.InteropServices;
>>>> >>>
>>>> >>> class class1
>>>> >>> {
>>>> >>> // int compress (Bytef *dest, uLongf *destLen, const Bytef *source,
>>>> >>> uLong sourceLen);
>>>> >>> [SuppressUnmanagedCodeSecurityAttribute()]
>>>> >>> [DllImport("zlib1.dll")]
>>>> >>> static extern Int16 compress(ref byte[] dest, ref uint destlen,
>>>> >>> byte[]
>>>> >>> source, int sourcelen);
>>>> >>>
>>>> >>> static void Main(string[] args)
>>>> >>> {
>>>> >>> if(args.Length != 2)
>>>> >>> {
>>>> >>> Console.WriteLine("Usage: testgz <inputfile> <outputfile>");
>>>> >>> return;
>>>> >>> }
>>>> >>> try
>>>> >>> {
>>>> >>> int filelen = (int)((new FileInfo(args[0])).Length);
>>>> >>> uint outputlen = (uint)Math.Ceiling(1.001 * filelen) + 12;
>>>> >>> using(FileStream fsr = new FileStream(args[0], FileMode.Open,
>>>> >>> FileAccess.Read, FileShare.Read))
>>>> >>> {
>>>> >>> byte[] inputbytes = new byte[filelen],
>>>> >>> outputbytes = new byte[outputlen];
>>>> >>> fsr.Read(inputbytes, 0, filelen);
>>>> >>> if(compress(ref outputbytes, ref outputlen, inputbytes, filelen)
>>>> >>> ==
>>>> >>> 0)
>>>> >>> using(FileStream fsw = new FileStream(args[1], FileMode.Create,
>>>> >>> FileAccess.Write, FileShare.Read))
>>>> >>> {
>>>> >>> fsw.Write(outputbytes, 0, (int)outputlen);
>>>> >>> fsw.Close();
>>>> >>> }
>>>> >>> fsr.Close();
>>>> >>> }
>>>> >>> }
>>>> >>> catch(Exception ex)
>>>> >>> {
>>>> >>> Console.WriteLine(ex.ToString());
>>>> >>> }
>>>> >>> }
>>>> >>> }
>>>> >>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>
>>
>
>
- Next message: Earl Damron: "Re: Background ops / threading question"
- Previous message: Earl Damron: "Re: Adding key events to a label"
- In reply to: Stefan Simek: "Re: using gzlib from c#"
- Next in thread: Bonj: "Re: using gzlib from c#"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
