.NET - Skydda källkoden.

Ta det inte på fel sätt men den här typen av diskussioner och frågeställningar är ofta ett symptom på att man inte har ordning på sina prioriteter. Att vilja skydda sina produkters design och affärshemligheter är en sak, att försöka motverka piratkopiering en annan och att hindra företag/individer från att begå licensöverträdelser en tredje.

Angående att det är enkelt att dekompilera C#-kod är eftersom att koden kompileras till bytekod. Med andra ord så är det inte bara Microsoft som har det här "problemet", utan även SUN med Java och många andra språk som kompileras till bytekod.

Hur bra programmerare man har anser inte jag ha något med språket man kodar. Att vara en bra programmerare för mig betyder att man kan lösa de problem som uppstår när man kodar på ett snyggt sätt samt inte gör en massa vurpor (buggar tillåts, ingen är perfekt).
Okej för att man behöver hålla tungan lite mer i mun när man kodar C/C++ då man måste tänka på pekare och minneshantering, men på vilket sätt gör detta att man är en bättre programmerare?
Sedan kan man vara mer eller mindre bra på ett/flera språk, men så länge man har rätt tankesätt anser jag att man är en duktig programmerare.

Tänker man efter lite så inser man att "cracka" och "pirata" kod inte är så långt ifrån varandra. Båda går ut på att man ser till att få tag i källkoden (antingen dekompilering eller disassemblering, beroende på vad man utgår ifrån) och analyserar den. Är man tillräckligt skicklig för att lista ut hur man knäcker ett kopieringsskydd genom att analysera assemblerkod så borde man kunna lista ut hur andra saker är uppbyggda (inte kodmässigt, utan idémässigt). Det hela beror på vad man definerar som "pirata", om det är att sno kod rakt av så går det såklart inte med binärkod, men om det är att sno idéer som gäller, då är det en annan femma (minus det faktum att man utför uppgifter på olika sätt i olika språk).

Varken bytekod eller binärkod är säkert, om någon verkligen vill få tag på kodlösningar genom någon annans kompilerade kod så går det, men frågan är hur många som faktiskt orkar göra något liknande.

Hur många av Microsofts program som skrivs i .NET har jag ingen aning om. Men jag skulle gissa på att Microsoft kommer att gå över till det mer och mer i framtiden. Det är trots allt ett verktyg som tillåter en att snabbt skapa applikationer och det är knappast omöjligt att faktiskt skriva en binärkompilator för det.

Jag har snubblat över en länk till Skater .NET Obfuscator och dess freeware version http://www.rustemsoft.com/SkaterLight.htm ett par gånger. Kanske kan det vara något ?

Kan även inflika att min övergång från c++ till .NET ett par år sedan var ett lyckat drag.
En bra programmerare för mig är en någon som kan leverera fungerande lösningar på kort tid (läs billigt). Och .NET plattformen är för det en utomordentligt bra utgångspunkt.

OT:
De kommer säkert påstå att de skall gå över till det för att sälja. VB var exemeplvis en mycket större kassako för microsoft jämfört med C++. C++ är svårare och tjäna pengar på. En dum användare är en bättre kund än en smart användare.
Microsoft är fullt medvetna att om de går över och gör nyckeprodukter i .NET så är leder det spikraka vägen till bolagets undergång även med deras extremt välfyllda kassa.

Jag har sett X antal företag gå åt skogen just på grund av att de valt sämre teknik med okunniga programmerare, det farligaste som kan hända är att det är någon mindre kunnig som fjäskat sig upp och bestämmer. Personen har fått för sig att det den kan är det bästa och har stor makt. Projekten går oftast mycket bra i början när de använder dessa förenklade språk med smidiga utvecklingsverktyg (automatgenerering av kod, dra och släpp o.s.v.). På bara några månader kommer de väldigt långt om en person tittar på programmet även om det ofta bara är relativt tomma skärmar.
Men någon gång så dyker projekten, varför kan man fråga sig? Jo för att de oftast glömt av några centrala delar (de 10% av koden som gör 90% av allt jobb) som är helt avgörande att de fungerar smärtfritt.

Det är idag riktigt svårt och få tag på skickliga programmerare just på grund av alla dessa förenklade språk. Förr när utvecklingsverktygen var rätt kassa så fick programmeraren göra mycket mer av jobbet (tänka mer) vilket gjorde att programmeraren övade upp sin skicklighet. Idag behöver programmeraren inte tänka lika mycket och därmed blir den heller inte lika skicklig.

En .NET programmerare får ju spendera största tiden med att lära sig det gigantiska klassbibliotek som följer med, inte att lösa uppgifterna själv.

Just att variabelnamn och metodnamn lagras i klartext finns även i Objective-C, det språk som är det allra största för att utveckla applikationer till Mac. Det har använts sedan NeXTstep-tiden och jag vågar påstå att det inte är särskilt vanligt att folk dekompilerar programmen. Dessutom uppvägs de få nackdelar som blir av att man har en otrolig dynamism i språket, något som är väldigt bra att ha när man programmerar objektorienterat. Exempelvis kan man göra saker som:

SEL action = NSSelectorFromString(@setStringValue:);
if ([someInstance respondsToSelector:action])
{
    [someInstance performSelector:action withObject:@Some string];
}

Det som görs (om vi skulle använda Javatermer iaf, har ingen koll på vad för termer man använder i C#) är alltså att vi tar ett metodnamn från en sträng, kollar om ett visst objekt kan utföra metoden, och om den kan det så gör vi det. Strängen skulle vi istället kunna ta vid runtime, det skulle fungera ändå. Om vi inte ville använda en sträng så hade vi kunnat använda SEL action = @selector(setStringValue:) istället, och hade vi inte viljat ha det såhär dynamiskt hade vi kunnat bara göra [someInstance setStringValue:@Some string] istället (men det kollar inte att someInstance faktiskt kan svara på meddelandet).

Många språk har inte sådan här dynamism, och i många andra språk är det svårt att använda sånt här, men i Objective-C så skulle det helt enkelt inte gå om man inte hade kvar namnen i koden.

Angående den där C/C++/C#/Java-debatten. Jag måste säga att C++ är det objektorienterade språk vars objektmodell är minst objektorienterad. Vill man lära sig objektorienterad programmering så ska man ju inte lära sig C++, utan då är Java och antagligen C# (har inte använt, därför antagligen) bättre.

Låt inte din rädsla för nya tekniker snöa in dig i ett C/C++ krig. Du gör helt fel när du drar slutsatsen att .net programmerare är sämre än C++ programmerare. Shit va många kassa c++ programmerare världen är full av...

.Net är ju en samlig av olika tekniker, du kan ju använda C++ ifall du vill, men som egen företagare (10år c++) kan jag lätt säga att resultatet är det
viktigaste, samt kostnaden. Inte vägen dit.
Sen är det ju så att ju fler rader du skriver, ju fler buggar har du i din kod. C# kan ju göra saker på 10 rader som du annars behöver 10000 rader för i C++. Jag skulle göra lossless rotering av jpg bilder i c++, skall dess utom sälja mjukvaran så ingen glp får användas. Blev ju ruskigt lätt att göra skalet i c++, sen använda COM mot c# dll bara för rotationen.

Nu är det väl så att .Net minskar vinsten för konsulter iom att det blir färre buggar och hela utv processen går på 50% av tiden. Så klart du vill då ha kvar c++...

.NET (VB och liknande) är säkert kanon för snabba konsultuppdrag om man inte har en stor egen kodbas och ta utav.

Helt fel!
När du skriver i C# så har du ett färdigskrivet klassbibliotek som du använder dig av, detta är redan skriven kod. Det finns många klassbibliotek för C++ med som man kan använda sig av om man inte vill skriva sina egna funktioner.
Kommentaren visar även något som sämre programmerare missar men som är så otroligt viktigt, det är ÅTERANVÄNDNING av kod. Använder själv kod som jag kanske skrev för 10 år sedan. Men använder man sig hela tiden av andra klassbibliotek så övar man själv aldrig upp denna färdighet.

Faktum är att det inte finns något språk som går behöver så få rader som C++ om man har skrivit passande objekt (klassbibliotek eller vad man nu väljer och kalla det).

Fråga om någon C# skrivit en egen XML parser? Ingen gör så eftersom man använder sig av de klasser som redan finns och får ta med de nackdelar som följer även om det är ett smidigt sätt och komma igång.

Vem vill egentligen sätta sig och skriva en egen XML-parser? Det är ju avsevärt mycket mer jobb med att skriva sig egen parser och sedan testa den så att den inte innehåller massor med buggar, än att använda libxml eller någon annan redan färdig parser. Där brukar de flesta buggar vara fixade redan.

Om man vill ha upp snabbheten

Om man vill ha upp snabbheten i vad som helst så är väldigt bra att använda ett redan färdigt bibliotek, sedan profilea sitt program. Om biblioteket visar sig långsamt så kan man sedan skriva ett eget.

Allt annat vore för tidig optimering, och för tidig optimering är nästan alltid dåligt.

Varför skriva ett eget bibliotek för sådant när det redan existerar ett som fungerar väl, vad vinner man på det?
Möjligen om det första biblioteket är instabilt eller ooptimerat, då får man en anledning.

En liten fråga, använder du STL när du kodar C++? STL används av säkerligen 99% av alla C++-kodare, beroende på vad de utför för uppgifter (spelprogrammerare tenderar att undvika sådant med automatisk minneshantering ).
Likaså, hur många använder inte Boost, och varför funderar de på att implementera flera av dess bibliotek i C++s standardbibliotek?

Så länge det finns smidiga bibliotek som gör det de ska så tjänar man oerhört mycket tid på att använda färdiga. Det gör en inte till en dålig programmerare, utan snarare tvärtom, man kodar smart.
Visst, det är bra om man kan implementera saker när det väl behövs, alla bibliotek håller inte måtten, eller gör inte som man vill, vilket leder till att man blir tvungen att koda en egen implementation.
Men om biblioteket fungerar så slipper man bry sig om den biten av projektet, det är någon annan som lägger ner tid på det och ser till att koden fungerar schysst och man själv kan fokusera på det andra.

Detta är precis vad du pratar om, återvinning av kod, inte sin egen kod, utan någon annans. Har själv ungefär fem års programmering bakom mig och den erfarenheten är utspridd över en rad språk, många av dem mycket högnivå. Det hindrar inte mig från att när jag väl behöver implementera något själv så ser jag till att lära mig det som krävs för att lyckas.
Dessutom, även om du återanvänder din egen kod, hur mycket lär du dig på det? Om det är kod du skrev för 10 år sedan lär du ju glömma bort hur den fungerar om du aldrig mer skriver om den utan bara copy-pastar hela tiden.

Vi har många medlemmar här på Sweclockers som arbetar med programmering, mängder av dessa använder säkerligen färdiga bibliotek i sitt arbete för att vinna tid, gör detta dem till sämre programmerare?

Har man lite koll på vad programmet kommer att göra så vet man redan innan var krutet skall läggas. Gör du exempelvis en serverapplikation för webben och som använder xml för att skicka data till och från användarna via ajax så är detta ingen vågad gissning samt otroligt viktigt att hanteringen är blixtsnabb.

Det beror på vad du skall göra, finns exakt det du är ute efter så tar du självklart det. Finns det inte så skriver du det själv. Vad som passar beror på uppgiften.

Ibland använder jag STL, det beror om det passar. Gör bl.a. serverappliaktion för webben och då är man också behov av mycket snabbhet vilket gör att man får tänka en hel del på minnesallokeringen. Ta exempelvis string klassen i STL, den är seg som fan eftersom den allokerar om sig vid varje förändring. Medan andra klasser är riktigt optimerade.
Har själv skrivit en egen stringklass och även en för att hantera utf8 text. De som finns passar inte.

Så, om jag skulle koda C# och vilja ha en komplett XML-parser så passar den i standardbibliotektet utmärkt? Nu vet jag inte hur XML-parsern i C# är, men jag antar att den fungerar fint.

Just nu låter det som om du motsäger dig själv.

Varför skall man åter uppfinna hjulet när någon redan har gjort det? XML parsern finns och skulle det vid senare skede visa sig för slött, ja då kan man skriva sin egen, men då skal man veta att detta tar tid och man inför nya buggar. Man skall ju satsa tid på det som är unikt för din produkt, inte sånt som är "off the shelf"

Copy & Paste är helt förbjudet, skall man återvinna så skall det vara hela bibliotek.

Du kan titta på en tidig version av en parser jag gjorde för några år sedan. Står lite där och förklarar även varför jag skrev den. Det tog c.a. 4 dagar och skriva den så speciellt mycket tid behöver det inte ta, den är iofs bättre idag då jag lag till mer funktionalitet. Template baserad idag så om man vill ha felhantering så går den och kompilera för det men vill man det inte så går det och kompilera för det med. Har du någon sådan på lager?

http://www.codeproject.com/soap/serialize_xml.asp

Nu frågade jag om C#, inte C++, gå inte ifrån ämnet.

Nej, det har jag inte. När jag väl kodar C (vilket är relativt sällan) och vill parsa XML (ännu mer sällan) så använder jag libxml. Fyller mina behov och jag slipper uppfinna hjulet igen.
Hade jag velat så hade jag använt en egen parser, men har inte direkt funnit något nöje i att skriva en.

Har däremot ett flertal bibliotek liggandes skrivna för O'Caml, exempelvis ett par stycken för konfigurationsfiler (de är uppbyggda på lite olika sätt, beroende på vad jag behöver för närvarande), ett loggfilsbibliotek samt ett bibliotek för dynamisk laddning av moduler.

Finns inget konfigurationsfilsbibliotek som följer den syntax jag ville ha på filerna, därmed skrev jag ett eget. Det enda fristående loggfilsbiblioteket som jag hittat fungerade inte riktigt som jag ville och slutligen, bibliotek för dynamisk laddning av bytekodfiler existerar inte (annat än det i standardbiblioteket som mitt bygger på, och det är ganska lågnivå).

Men det är ju just det jag försökt berätta, en som kör .NET gör väldigt sällan egna grejjer.

För egen del är det mer regel än undantag att jag gör egna grejjer. Har varit med och tillräckligt mycket problem genom att använda andras och är trött på att skriva om annans kod eftersom det kanske finns buggar där eller det inte riktigt passar.
Detta tillvägagångsätt har sparat mig otroligt mycket tid.

Under min tid som programmerare så har jag sett ett flertal projekt balla ur. Exemepelvis var det för några år sedan ett företag som omsatte c.a. 3 miljarder här i Göteborg. De fick för sig att skriva om deras applikation i java. De sysslade med växelsystem för telefoner. När de var nästan klara så märkte det att prestanda var på tok för dålig och eftersom produkten var så viktigt så sket det sig för hela bolaget.

Återigen så ser jag inte detta som något negativt. Ett rikt standardbibliotek kan man vinna på i längden.

Använder man bibliotek med öppen källkod så kan man åtgärda dessa buggar och skicka in patchar, lite svårare med stängda bibliotek i och för sig. Hur som helst, så länge du själv anser dig behöva skriva egna saker, gör så. Men klaga inte på när andra nöjer sig med redan existerande bibliotek.

Då är det ju deras egna fel för att de inte gjorde efterforskningar i hur Java påverkar prestandan för en sådan applikation. I det här fallet lämpade sig inte Java för ändamålet (eller så höll inte koden måttet), men Java, C# och andra språk lämpar sig ypperligt för en rad andra uppgifter. Exempelvis så skulle jag aldrig använda C till en applikation som enbart ska göra operationer på strängar, utan välja språk som Ruby och Perl, vilka har otroligt stora bibliotek för den typen av uppgifter (Perl skapades ju för stränghantering).

Är varken Java- eller C#-anhängare (själv hade jag gärna sett mer O'Caml på marknaden men funktionella språk används inte så ofta där) men var språk har sina användningsområden.

Detta var ju bara ett exempel, det är extremt vanligt med likartade problem. Ofta finns exempelvis konkurrens bland inhyrda konsulter. En konsult som är duktig tekniskt med dålig på och uttrycka sig blir bortkollrad av en som kanske är värdelös tekniskt men mycket bra på att prata. Pratnissen har precis lärt sig något och tyckt "fan vad bra detta är" och talar sig varm angående hur bra den teknik den använder är. Kunden som kanske inte alls har tekniska kunskaper förstår inte riktigt allt tekniksnack och lyssnar därför på den som snackar bäst. Det blir ett dyrköpt misstag.

Sjukvården är ett område där det finns hur mycket misslyckad projekt som helst, går man in lite och granskar där så blir man helt mörkrädd.

Andra problem som uppstår problematiskt ofta bland mindre kunniga programmerare är "men fan, det gick ju snabbt när jag testa"...
De har kanske gjort någon databasapplikation, när programmeraren testar så finns det 43 poster i databasen och då går det givetvis snabbt. Så går applikationen ut till kund och den importerar existerande data, plötsligt finns det några miljoner poster och kunden får vänta en timme innan applikationen svarar.

Om man förklara sånna här problem för programmerare som tagit till sig ett språk och tycker de är hur bra som helst så fattar de sällan, det blir endast religiösa diskussioner där de inte vet vad de pratar om. De kommer inte lära sig förrän de sitter i skiten med en arg kund som köpt en programvara som inte fungerar.

Jag har bara skummat igenom lite av det du sagt men i kort så skyller du på programmerarna och inte på .NET? Eller? Och detta får du ihop genom:

Använda .NET = Dåliga programmerare som gjort dåligt val
Använda C++ = Bättre programmerare som gjort bra val

Eller?

Det finns något som heter sannolikhetslära och det innebär att sannolikheten att en duktig programmerare väljer ett dåligt språk är liten, det finns ofta någon anledning till varför. Sannolikheten att en inte så bra programmerare väljer ett enklare språk är större, orsaken är att språket just är enklare.

Idag sitter programmerare i rätt många språk, ibland för att man måste (kunden sätter det kravet) eller så har det med teknikval och göra (javascript i browser exempelvis).

Men sitter man enbart i .NET och pratar sig varm om det så brukar det beror på en sak och det är brister i de tekniska kunskaperna.

Varför välja en sämre miljö om man varken måste eller saknar kunskap och därför behöver välja den sämre?

Enligt mig är det bästa sättet att skydda sitt program att skriva ett ordentligt licensavtal. Skitsamma ifall nån försöker cracka programmet, det händer ju för eller senare hur mycket du än försöker skydda det. Man kan ju se Windows som ett exempel på det.

Har du skrivit ett bra licensavtal som säger att användaren inte får använda crackade versioner av programmet så kan du istället tjäna en slant ifall du upptäcker användaren.

När jag funderar på att göra en mjukvara så funderar jag först på vad programmet ska innehålla, ifall det finns färdiga bibliotek och hur mycket jag behöver tänka på prestandan. Gör man en bra kombination kan programmet bli hur bra som helst.

Jag håller med m0REc om att det knappast är en nackdel att .Net-programmerare använder färdiga klasser. Ifall programmet blir bra och de inte brutit mot nån licens så är det ju lugnt?

Har bara skummat delar av tråden, men på förra sidan uppfattade jag det som att någon skrev att det är omöjligt att förstå disassemblad kod. Det är fel. Varenda keygen som finns bygger ju på att någon har förstått hela koden som kontrollerar licensnummer, och sedan skrivit samma kod i ett annat språk. Jag har programmerat applikationer i assembler i nästan tio år, och har man mycket erfarenhet av assembler är det inte mycket svårare än något annat språk. Det finns t.ex. folk som jobbar med att skriva om tappad källkod från disassemblade exe-filer.

Kanske kan fixa en licens gratis till dig, PM'ar isånnafall.

http://www.microsoft.com/expression/
Microsofts flash/flex-killer, använder sig av NET 3.0.

Det finns en anledning till att de som går/gått över till .NET pratar sig varm om det. De/vi anser att vår produktivitet har ökat och fokus hamnar mer på arkitetktur och systemuppbyggnad än detaljerna.

Jag har under de senaste 10 åren arbetat på en mindre firma som specialiserar sig på inbyggnadselektronik och styrning/mätning/verifiering av industri elektronik, PC och inbyggt. Våra kunder finns från mindre företag till stora statliga bolag.
För c:a 3 år sedan började jag migrera från c++ till .NET och C# och min erfarenhet från det är att min produktivitet, alltså kundens pris, blev mer konkurranskraftig och den uppskattade leveranstiden ökade i precision.

Ungefär 1/4 av det kodbibliotek som jag tog fram under min C++ tid används nu som unmanaged .dll's. 2/4 fanns liknande eller bättre/säkrare i .NET och 1/4 skrevs om i C#. Som exempel är mitt USB bibliotek fortfarande i C++ som anropas via C# kod, medan ironiskt nog så ersattes den vanliga seriella kommunikationen med befintlig klass i .NET 2.0.

Idag så löser jag eventuella prestanda problem (väldigt sällan visserligen) med ändring av systemarkitekturen iförsta hand istället för rad för rad optimering.

Men kort, ingen bryr sig förutom den stolte utvecklaren om hur en kunds behov fylls. Må det vara via en egen finurlig algoritm eller en standardiserat redan skriven kod, så länge som kunden är glad.