Coffeehouse Thread

55 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Linq is scary

Back to Forum: Coffeehouse
  • User profile image
    Secret​Software


    stevo_ wrote:
    
    figuerres wrote:

    it's much like the whole riaa / music  thing....

    if someone wants it they will get it.


    While I'm not commenting on if .net MSIL should be changed to be more 'secure'. Surely your last comment invalidates your argument, the whole DRM security thing, windows activation security and such- yes it gets broken- but that doesn't mean they stop, they keep going to make it so that less and less people are actually capable of breaking it.


    Agreed.

    I know people can break anything or know how something works. But Its about raising the bar higher each time. Now with MSIL, i see script kiddies, reverse engineering .NET applications with a click on a button. This is really bad. Now if you raise the bar higher, that only highly trained professionals would be able to if they want, then these kinds of people will not spend hours upon hours to break something that is not worth it for them. See the difference?

    The amount of time you put into it will make it hard and unattractive to undertake.

    With MSIL, just  1 click and there you have the code. So you spend alot of hours debugging and fixing stuff, and someone just takes it with a click of a button. Its just not right. and MS should have done a better job about this since the invention of .NET framework.

    There should be native source encryption, using asymmetrical keys, with digital signatures.

    This is one reason why you dont see commerisal applications written in .NET, most are written in Vb6 or C++ or C or other machine-code producing languages.

    The way the .NET framework stuff works, is similar to client-server design without encryption. So your code from the time you compile it to the time its run in the client machine, is never really encrypted.

    So MS really needs to step up and fix this problem.

  • User profile image
    Cornelius Ellsonpeter

    Who are you to criticize the code Don has produced? What code have you generated lately, other than some half-baked, half-completed cryptic mess of an 8-bit turd that you dumped in the Sandbox? What books have you written?

    Wait, don't answer that.

  • User profile image
    figuerres

    SecretSoftware wrote:
    
    stevo_ wrote: 
    figuerres wrote: 

    it's much like the whole riaa / music  thing....

    if someone wants it they will get it.


    While I'm not commenting on if .net MSIL should be changed to be more 'secure'. Surely your last comment invalidates your argument, the whole DRM security thing, windows activation security and such- yes it gets broken- but that doesn't mean they stop, they keep going to make it so that less and less people are actually capable of breaking it.


    Agreed.

    I know people can break anything or know how something works. But Its about raising the bar higher each time. Now with MSIL, i see script kiddies, reverse engineering .NET applications with a click on a button. This is really bad. Now if you raise the bar higher, that only highly trained professionals would be able to if they want, then these kinds of people will not spend hours upon hours to break something that is not worth it for them. See the difference?

    The amount of time you put into it will make it hard and unattractive to undertake.

    With MSIL, just  1 click and there you have the code. So you spend alot of hours debugging and fixing stuff, and someone just takes it with a click of a button. Its just not right. and MS should have done a better job about this since the invention of .NET framework.

    There should be native source encryption, using asymmetrical keys, with digital signatures.

    This is one reason why you dont see commerisal applications written in .NET, most are written in Vb6 or C++ or C or other machine-code producing languages.

    The way the .NET framework stuff works, is similar to client-server design without encryption. So your code from the time you compile it to the time its run in the client machine, is never really encrypted.

    So MS really needs to step up and fix this problem.


    perhaps I am missing something....

    I think you are covering different cases with one blanket wish.

    for example if a "skript kidd" hacks up some code that's one case.

    someone copying code is another.

    and all code encryption fails at runtime as the cpu has to execute something.

    and take this point:  who wants to copy what?

    not all apps are targets for theft.

    for example I have serval .net apps that have to run 7x24 and do so very well, handles a lot of money and I watch for some things related to how it might be abused but... no one is copying the app.

    now if I wrote a game for example then I'd worry more about copies that I was not paid for...

    so part of the level of concern should be what the market is for the code.

    and no compiler I know of for C / C++ encrypts the binaries it makes; you get a 3rd party tool for that....

    why should .net be different in this area than C++ ?

    everyone cries about how easy it is to reverse misl to c#
    but what about x86 code.... I used to write x86 and C and I could follow the asm dump from a program and work out what it did....
    it's not that hard really....

    and we are folks who code and work on this for a living - at least I am.

    most folks would not even try....

    the ones that will - they will and if the code is harder to crack then the challenge goes up and they get more crackers in on the job...

    and what % of the market for this app will want to copy / crack / hack it?

    and how much $$$ will you spend to protect the app from that goup?

    I'd rather spend the $$$ on making the app better, getting the users to love it and buy the next version -- and so on.

    sure I would do some protection, and watch for cracked copies etc...

    but IMHO folks worry to much about this ....

  • User profile image
    Secret​Software

    figuerres wrote:
    
    SecretSoftware wrote:
    stevo_ wrote: 
    figuerres wrote: 

    it's much like the whole riaa / music  thing....

    if someone wants it they will get it.


    While I'm not commenting on if .net MSIL should be changed to be more 'secure'. Surely your last comment invalidates your argument, the whole DRM security thing, windows activation security and such- yes it gets broken- but that doesn't mean they stop, they keep going to make it so that less and less people are actually capable of breaking it.


    Agreed.

    I know people can break anything or know how something works. But Its about raising the bar higher each time. Now with MSIL, i see script kiddies, reverse engineering .NET applications with a click on a button. This is really bad. Now if you raise the bar higher, that only highly trained professionals would be able to if they want, then these kinds of people will not spend hours upon hours to break something that is not worth it for them. See the difference?

    The amount of time you put into it will make it hard and unattractive to undertake.

    With MSIL, just  1 click and there you have the code. So you spend alot of hours debugging and fixing stuff, and someone just takes it with a click of a button. Its just not right. and MS should have done a better job about this since the invention of .NET framework.

    There should be native source encryption, using asymmetrical keys, with digital signatures.

    This is one reason why you dont see commerisal applications written in .NET, most are written in Vb6 or C++ or C or other machine-code producing languages.

    The way the .NET framework stuff works, is similar to client-server design without encryption. So your code from the time you compile it to the time its run in the client machine, is never really encrypted.

    So MS really needs to step up and fix this problem.


    perhaps I am missing something....

    I think you are covering different cases with one blanket wish.

    for example if a "skript kidd" hacks up some code that's one case.

    someone copying code is another.

    and all code encryption fails at runtime as the cpu has to execute something.

    and take this point:  who wants to copy what?

    not all apps are targets for theft.

    for example I have serval .net apps that have to run 7x24 and do so very well, handles a lot of money and I watch for some things related to how it might be abused but... no one is copying the app.

    now if I wrote a game for example then I'd worry more about copies that I was not paid for...

    so part of the level of concern should be what the market is for the code.

    and no compiler I know of for C / C++ encrypts the binaries it makes; you get a 3rd party tool for that....

    why should .net be different in this area than C++ ?

    everyone cries about how easy it is to reverse misl to c#
    but what about x86 code.... I used to write x86 and C and I could follow the asm dump from a program and work out what it did....
    it's not that hard really....

    and we are folks who code and work on this for a living - at least I am.

    most folks would not even try....

    the ones that will - they will and if the code is harder to crack then the challenge goes up and they get more crackers in on the job...

    and what % of the market for this app will want to copy / crack / hack it?

    and how much $$$ will you spend to protect the app from that goup?

    I'd rather spend the $$$ on making the app better, getting the users to love it and buy the next version -- and so on.

    sure I would do some protection, and watch for cracked copies etc...

    but IMHO folks worry to much about this ....


    In client server applications this matters. The difference between C++ and C# is that the compiler digest, the MSIL, is not really secure from reverse engineering. Infact its many orders of magnitude easier to decompile C# app, than C++. Both are doable, but with C++ its compiled into machine code, which is not human readable, and it will take you hours to know where things are and what they do. But in C# you can use, reflector or similar programs, and you have the butter of the app.

    Now cyber criminals, will scan it for vulnerabilities, or even write up their own Zombie application, and screw up your customers.

    So because C# is easier to decompile and hence scan for vulnerabilities, it ought to have some kind of encryption, to protect the code from cybercriminals, and from reverse engineering, as to protect intellecual property of others.


  • User profile image
    Secret​Software

    PaoloM wrote:
    
    thumbtacks wrote:Like...who?

    Anders could work wherever he wants. Just like Scoble. Scoble MADE Microsoft marketing what it was.

    Er... while I admire Anders and Robert, I think you severely underestimate all the other people working there.

    I happen to have on hand a September 2005 paper titled "The LINQ Project - .NET Language Integrated Query". It's authored by Don Box and Andres Hejlsberg.

    Andres may very well work wherever he wants, but he wants to work with Microsoft right now, and whatever he comes out during work hours is intellectual property of the company...


    I think MS gets its ideas from its customer's needs. So there was a need for LINQ, and MS made  it happen.

    Sometimes I think of MS as the Borg.

  • User profile image
    KeyboardG

    Its funny how whats old is new again.... As a foxpro developer I already have native SQL-like code and iterate over the selection(cursors) with scan statements. Just an observation, it seems with .net 3.0 a lot of the advantages of foxpro are being brought into the clr as foxpro sunsets.

  • User profile image
    Secret​Software

    Dark_Halmut wrote:
    

    Its funny how whats old is new again.... As a foxpro developer I already have native SQL-like code and iterate over the selection(cursors) with scan statements. Just an observation, it seems with .net 3.0 a lot of the advantages of foxpro are being brought into the clr as foxpro sunsets.



    Need is the mother of all inventions. So there is a need for this, and hence its reintroduced.

    I am excited about LINQ, and cant wait to get my hands on it as an RTM product in Visual Studio 2007 (Code Name Orcas).


    But I can only imagine what is next. What will MS pull out of the hat in C# 4.0 or VB.NET 10.0 .

  • User profile image
    PaoloM

    thumbtacks wrote:
    Okay, that's true...what he does during work hours is your property.

    But Don Box?

    Seriously.

    Don. Box.

    Uh, tell me, what has Mr. Box done again? Other than put up a holiday jingle that you can stand for about ten seconds at most...

    Besides WCF and SOAP? Uhm... not much, I think.

    Expressionless

  • User profile image
    amotif

    PaoloM wrote:
    
    thumbtacks wrote: Okay, that's true...what he does during work hours is your property.

    But Don Box?

    Seriously.

    Don. Box.

    Uh, tell me, what has Mr. Box done again? Other than put up a holiday jingle that you can stand for about ten seconds at most...

    Besides WCF and SOAP? Uhm... not much, I think.



    Through his writings Don Box single-handedly increased tenfold the number of developers who understand COM enough to use it well and safely. (Without his writings there would only be about 5 such developers, and I would not be one. Smiley)

  • User profile image
    PaoloM

    thumbtacks wrote:
    SOAP is an XML based protocol. First off, XML is not difficult to pick up or to create your own own protocols off of. Next you'll bring up Dave Winer!

    It's easy to come up with your own homegrown file formats.

    I must have missed your contribution in that area... after all, it's all a joke, right?

    Expressionless
    thumbtacks wrote:
    Whether they receive widespread adoption is another thing.

    I don't think the widespread adoption of SOAP is questionable. And it hasn't been questionable for quite some time.
    thumbtacks wrote:
    How much of WCF did Don actually code? Or was he just overseeing things?

    Probably as much as Anders coded LINQ.

  • User profile image
    Secret​Software

    when you are designing things, you dont do the dirty work.

    Its just like engineers who build buildings. They just give logistic support. They are the brains of the project. They hardly mix cement, or put a nail into a wall. They tell the other guys to do the dirty work.

    So in a sense they are the brains, and the coding department is the printer.

  • User profile image
    Secret​Software

    Yes. Now Its not only Andres, the user input , other people input  results in good products.

    Now what would you do differently if you were the cheif designer of C#, than what Andres had done? Aside from what I stated above about reverse engineering, I dont think I would do much different than what Andres has done.

  • User profile image
    ElucidWeb

    thumbtacks wrote:
    
    JohnAskew wrote:The one thing I agree with Thumbtacks about (and it may be the first ;D) is that Anders is a freaking GENIUS. Why? Well Thumb had his chance at discovering and implementing LINQ, but didn't...
    I agree he is a GENIUS. But, like I said elsewhere, when you see what I'm working on (and I still haven't found this implemented elsewhere) someone just might say "whoa". The problem is that I'm doing foundational/low-level work right now...and then I will build rapidly on top of that. I'll post demo code if I get it working the way I want it to.


    You really like to hear yourself talk dont you?

  • User profile image
    DarthVista

    ElucidWeb wrote:
    
    thumbtacks wrote: 
    JohnAskew wrote: The one thing I agree with Thumbtacks about (and it may be the first ;D) is that Anders is a freaking GENIUS. Why? Well Thumb had his chance at discovering and implementing LINQ, but didn't...
    I agree he is a GENIUS. But, like I said elsewhere, when you see what I'm working on (and I still haven't found this implemented elsewhere) someone just might say "whoa". The problem is that I'm doing foundational/low-level work right now...and then I will build rapidly on top of that. I'll post demo code if I get it working the way I want it to.
    You really like to hear yourself talk dont you?
    The sad part about this site is that there seems to be several people here who like to post notes to themselves. Apparently, in this case, open source is the root of Mr. Thumbtacks problem. He's certifiably loony from working with it. Sort of like Dr. Curie and radiation experiments!

  • User profile image
    Dr Herbie

    Thumbs:  just found this collections library which I thought you might find interesting.

  • User profile image
    Secret​Software

    Dr Herbie wrote:
    

    Thumbs:  just found this collections library which I thought you might find interesting.



    Thanks for that.

  • User profile image
    ScanIAm

    Dark_Halmut wrote:
    

    Its funny how whats old is new again.... As a foxpro developer I already have native SQL-like code and iterate over the selection(cursors) with scan statements. Just an observation, it seems with .net 3.0 a lot of the advantages of foxpro are being brought into the clr as foxpro sunsets.



    <cough>codebase</cough>

    The difference, though, is that the LINQ syntax is so very, very much cleaner and in fact, you can use the LINQ construct on a simple collection that never, ever ends up in a database.

    To this day, I still see developers who misuse collections and write:

    for(i=0;i<List.Count;i++)
    {
       SomeType st = (SomeType)List[i];
       ...
    }

    instead of

    foreach(SomeType st in List)
       ...

    Which one is clearer?

    Same with LINQ.

  • User profile image
    Secret​Software

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.