DOCSLIB.ORG

Managing the Evolution of .NET Programs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Managing the Evolution of .NET Programs Managing the Evolution of .NET Programs Susan Eisenbach, Vladimir Jurisic and Chris Sadler Department of Computing Imperial College London, UK SW7 2BZ [sue, vj98]@doc.ic.ac.uk School of Computing Science Middlesex University London, UK N14 4YZ [email protected] Abstract Programs in the .NET environment consist of collaborating software components, and the Common Language Runtime has been designed in such a way that linking occurs ‘just-in-time’. This offers a good platform for transpar- ent evolution, provided that compatibility can be maintained between service- providing components and their clients. One goal of program evolution is to use the most recent version of each com- ponent that will actually link. We propose a model of a cache of interdepen- dent evolving components with operations defined to update this cache safely. A demonstration tool Dejavue.NET implements these ideas. 1 Introduction The dynamic link library (DLL) was invented to allow applications running on a sin- gle system to share code. Sharing code in this way confers several distinct benefits. In the first place, applications both when running in memory and when stored on disk are likely to be smaller because duplicated code has been eliminated. In the second place, applications accessing common code share a common functionality so they all do cer- tain things in the same way. This is good for the users, who get a reliable and predictable user interface. It is also makes the operating system design more straightforward, with provision of access to certain facilities through narrow and well-defined interfaces. The main benefit however, arises when the DLL needs to be corrected or enhanced – in other words, to evolve. Because it is linked at run-time, any client applications stand to benefit from the modifications immediately – the new version replaces the old one painlessly, in the sense that the user doesn’t have to do anything apart from launch the application. This is good for application users and developers generally. However there can be pain when a new application is installed on a user’s system: Upgrade: Some enhancements may make the new version of the DLL incompatible with the old one. The new application setup will overwrite the old DLL with the new version, and will execute perfectly, but the old applications may fail. Accidental Downgrade: If an application built with a previous version of the DLL is installed, this is likely to re-install the old version of the DLL too, so the new applications may fail. So, for any individual system that uses DLLs, as soon as something is changed (typically by installing a new – or upgraded – application) it is only a matter of time before the user will descend into “DLL hell” [14,13]. Many Microsoft support personnel report [1] DLL hell as the single most significant user problem that they are called upon to respond to, and Microsoft has struggled to design its way around the problem. We catalogue this in section two. The main contribution of this paper is made in section three where we develop a model of a dynamic linking intended to be a conservative extension of what ac- tually happens. Section four describes the design and development of a utility De- javue.NET [9] based on the model, and conceived to assist library developers in their task of developing DLLs that are trouble free. In section five we report on other recent work which has addressed this problem, and in section six we give some indications of where we want to take this work in the future. 2 DLL Hell Microsoft’s first idea was to introduce version numbers. By allowing several versions of a DLL to co-exist, this could have eased the upgrade problem, provided that each application ‘knew’ which version of the DLL it needed, and provided that the DLL de- velopers only incremented the version number when they made incompatible changes. In practice, this is too much to ask of a heterogenous group of developers and Microsoft did not even try it. Instead, version numbers were used during installation (rather than when the application was first built) to ensure that a previous version did not overwrite a newer version [19]. This would have solved the downgrade problem if the people who wrote the installation scripts had consistently checked version numbers. However, not checking version numbers guaranteed that the current application would run although others may fail (rather than vice versa) so there was little incentive to do this. The next solution cropped up in Windows 2000. The approach was on two fronts. Firstly, a few thousand DLLs were earmarked as protected DLLs, which the file protec- tion system (WFP) will guard. When a new application is being installed, if an attempt is made to download an earlier or later version than the currently installed version of a protected DLL, it will be stopped by the setup system. If there is no currently installed version of the protected DLL, the setup system will install the corresponding version from the home system’s DLL cache, regardless of which version the application actu- ally requires. Protected DLLs can only be updated by a service pack update. This means that the computer system user (via Microsoft) controls the DLLs that exist on his system. The developers thus lose one of the main advantages of DLLs, the ability to perform transparent evolution, and instead must take responsibility for delivering capability on whatever systems their customers have. Developers whose DLLs lie outside the chosen few thousand also lose the benefits of the ‘common functionality’. The second front opened by Windows 2000 loses even more benefits of sharing. So-called ‘side-by-side’ DLLs can be created by associating a specific instance of a DLL with an application. Other applications may use the same version, but will not be sharing the same instance. The DLL developer loses all the potential advantages of 2 dynamic linking, since every side-by-side instance will need to be explicitly replaced. Alternatively, they may use a different version, so the functionality will cease to be common. These mechanisms help to solve the problems of DLL hell and make life more peaceful for Microsoft support personnel, but they do so at the expense of some of the sharing advantages that DLLs were originally invented to exploit. Microsoft’s latest ideas are embodied in the Common Language Runtime (CLR) of the .NET environment. .NET aims to provide developers with a component-based execution model. Any application will consist of a suite of co-operating software com- ponents amongst whose members control is passed during execution. The CLR needs to be ‘language-neutral’ (hence Common) which means it should be possible to write a component in any one of a variety of languages and have it executed by the CLR; and also that it should be possible to pass data between components written in different languages (using the Common Type System – CTS). The usual way to do this is to introduce an intermediate langauge which the high- level languages compile to, and to constrain their data types to conform to those recog- nised by the intermediate language. .NET achieves this with IL (Intermediary Lan- guage). Whereas most systems with an intermediate language have run-time systems that interpret the intermediate code (usually for portability reasons), the CLR uses a ’just-in-time’ (JIT) compiler to translate IL fragments (primarily method bodies) into native code at run-time. Of course, the native code must run within some previously-loaded context, and when the JIT compiler encounters a reference 1 external to the context, it must invoke some process to locate and establish the appropriate context before it can resolve the reference. This process can be quite involved and is illustrated in Figure 1. When a reference is made to a not yet loaded entity (type or type member) within the current, or another previously-loaded component, a classloader is called to load the corresponding type definition. When a reference is made to an entity external to all loaded components, it will be necessary to load the new component (or assembly in Microsoftspeak) in its entirety via the Library Loader. The CLR has to meet some serious dynamic link- loading demands in order to provide both internal and external data definitions and JIT compilation in the time-frame of native code execution. The design of the .NET assembly reveals some details about how this is accom- plished. In the first place, each Microsoft assembly carries versioning information struc- tured into four fields – Major, Minor, Revision and Build. This allows many versions of the same DLL to co-exist in the system, and gives us the means to associate or disasso- ciate the different versions with one another. For example, versions with the same Major and Minor version numbers would probably be fairly compatible, whilst two versions with widely separated Major numbers would probably not make this system useful. Two things are required. Firstly, we have to agree the semantics of what constitutes Major, Minor etc. and this means we must understand what ‘compatibility’ means. Secondly, we have to be able to exercise some control over which version will be loaded by the Library Loader when a new component is needed at run-time. The Fusion utility in 1 Microsoft distinguishes between references which are in client code and definitions which are in server code. 3 Assembly Resolver (Fusion) Manifest module is not resolved to a loading path Cache Library binaries Loader Metadata definition of the type is not loaded Class Class or interface is not loaded Loader Reference made to an unloaded type Subtypes not checked Verifier Jit Compiler one block of IL Unresolved tokens code processed Resolver A method without a native stub is called Execution of native method code Key Reason Call Figure 1.
Load more

Recommended publications
  • Programming with Windows Forms
    A P P E N D I X A ■ ■ ■ Programming with Windows Forms Since the release of the .NET platform (circa 2001), the base class libraries have included a particular API named Windows Forms, represented primarily by the System.Windows.Forms.dll assembly. The Windows Forms toolkit provides the types necessary to build desktop graphical user interfaces (GUIs), create custom controls, manage resources (e.g., string tables and icons), and perform other desktop- centric programming tasks. In addition, a separate API named GDI+ (represented by the System.Drawing.dll assembly) provides additional types that allow programmers to generate 2D graphics, interact with networked printers, and manipulate image data. The Windows Forms (and GDI+) APIs remain alive and well within the .NET 4.0 platform, and they will exist within the base class library for quite some time (arguably forever). However, Microsoft has shipped a brand new GUI toolkit called Windows Presentation Foundation (WPF) since the release of .NET 3.0. As you saw in Chapters 27-31, WPF provides a massive amount of horsepower that you can use to build bleeding-edge user interfaces, and it has become the preferred desktop API for today’s .NET graphical user interfaces. The point of this appendix, however, is to provide a tour of the traditional Windows Forms API. One reason it is helpful to understand the original programming model: you can find many existing Windows Forms applications out there that will need to be maintained for some time to come. Also, many desktop GUIs simply might not require the horsepower offered by WPF.
    [Show full text]
  • GOTOHELL.DLL: Software Dependencies and The
    GOTOHELL.DLL Software Dependencies and the Maintenance of Microsoft Windows Stephanie Dick Daniel Volmar Harvard University Presented at “The Maintainers: A Conference” Stephens Institute of Technology, Hoboken, NJ April 9, 2016 Abstract Software never stands alone, but exists always in relation to the other soft- ware that enables it, the hardware that runs it, and the communities who make, own, and maintain it. Here we consider a phenomenon called “DLL hell,” a case in which those relationships broke down, endemic the to Mi- crosoft Windows platform in the mid-to-late 1990s. Software applications often failed because they required specific dynamic-link libraries (DLLs), which other applications may have overwritten with their own preferred ver- sions. We will excavate “DLL hell” for insight into the experience of modern computing, which emerged from the complex ecosystem of manufacturers, developers, and users who collectively held the Windows platform together. Furthermore, we propose that in producing Windows, Microsoft had to balance a unique and formidable tension between customer expectations and investor demands. Every day, millions of people rely on software that assumes Windows will behave a certain way, even if that behavior happens to be outdated, inconvenient, or just plain broken, leaving Microsoft “on the hook” for the uses or abuses that others make of its platform. Bound so tightly to its legacy, Windows had to maintain the old in order to pro- mote the new, and DLL hell highlights just how difficult this could be. We proceed in two phases: first, exploring the history of software componenti- zation in order to explain its implementation on the Windows architecture; and second, defining the problem and surveying the official and informal means with which IT professionals managed their unruly Windows systems, with special attention paid to the contested distinction between a flaw on the designer’s part and a lack of discipline within the using community.
    [Show full text]
  • A Programmer's Introduction to Visual Basic.NET
    00 2203-x FM 5/25/01 9:57 AM Page i Dear Reader, I wanted to take this opportunity to explain the rationale behind this book showing up on your shelf for free. Quite some time ago, Sams Publishing determined that the next big thing to hit the programmer/developer community would be Microsoft’s Visual Studio.NET and the .NET Framework. After discussions with many of you, our authors and key Microsoft team members, Sams dedicated itself to a strategy that would support your efforts to learn the .NET Framework as efficiently and as quickly as possible. A Programmer’s Introduction to Visual Basic.NET is the perfect example of how our strong relationship with Microsoft and our dedication to bring- ing you authors who are already respected sources in the community suc- cessfully blend and show that Sams Publishing is the source for .NET learning. Bringing you a Beta2 compliant book by May 2001 was not an easy task. Sams called upon a respected author, Craig Utley, to take on this project. Craig holds a unique place in the VB community where he has been devel- oping in VB since version 1.0. He brings years of experience as a trainer, writer, and speaker to this project and gives you the solid reference you need to make the transition from VB to VB.NET. I hope this book gives you the tools you need to begin to learn VB.NET. I invite your comments and ideas as I work to make Sams the publisher you look to as your .NET learning resource.
    [Show full text]
  • NET Framework Overview
    .NET Framework Overview .NET Framework, CLR, MSIL, Assemblies, CTS, etc. Svetlin Nakov Telerik Corporation www.telerik.com Table of Contents 1. What is .NET? Microsoft .NET platform architecture 2. What is .NET Framework? .NET Framework Architecture 3. Common Language Runtime (CLR) 4. Managed Code 5. Intermediate Language MSIL 6. Assemblies and Metadata 7. .NET Applications Table of Contents (2) 8. Common Language Infrastructure (CLI) and integration of different languages Common Language Specification (CLS) Common Type System (CTS) 9. Framework Class Library 10. Integrated Development Environment Visual Studio .NET Framework Microsoft's Platform for Application Development What is the .NET Platform? The .NET platform Microsoft's platform for software development Unified technology for development of almost any kind of applications GUI / Web / RIA / mobile / server / cloud / etc. .NET platform versions .NET Framework Silverlight / Windows Phone 7 .NET Compact Framework What is .NET Framework? .NET Framework An environment for developing and executing .NET applications Unified programming model, set of languages, class libraries, infrastructure, components and tools for application development Environment for controlled execution of managed code It is commonly assumed that .NET platform == .NET Framework .NET Framework Components Common Language Runtime (CLR) Environment for controlled execution of programmed code – like a virtual machine Executes .NET applications Framework Class Library (FCL) Standard class library
    [Show full text]
  • Windows XP Technical Overview
    Operating System Windows XP Technical Overview Microsoft Corporation Published: May 2001 Abstract This paper provides a technical overview of what’s new in the Microsoft® Windows® XP operating system. It shows how new technologies and features make it easier to get work done, share information, manage your desktop, stay productive while traveling with a mobile computer, obtain help and support, and perform many other computing tasks. Because this paper is an overview, it does not address any area in detail but provides a broad look at the many new technologies and features in Windows XP. This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.
    [Show full text]
  • On the Principles and Future of COM Featuring The
    DEGREE PROJECT 2003:D14 On the Principles and Future of COM Featuring The Random Dot Stereoimage Technology utionen för Informatik och Matematik Anders Alexandersson Avdelningen för datavetenskap vid Instit EXAMENSARBETE Högskolan Trollhättan ⋅ Uddevalla Institutionen för Informatik och Matematik Uppsats för filosofie kandidat i Datavetenskap On the Principles and Future of COM featuring The Random Dot Stereoimage Technology Anders Alexandersson Examinator: Docent Stefan Mankefors Institutionen för Informatik och Matematik Handledare: Andreas Boklund Institutionen för Informatik och Matematik Trollhättan, 2003 2003:D14 i EXAMENSARBETE COM — principer och framtida utveckling exemplifierat med RDS teknologin Anders Alexandersson Sammanfattning Föreliggande arbete är en tillämpning av den komponentbaserade principen för programvaruutveckling, med hjälp av COM - Component Object Model från Microsoft. Inledningsvis finns en analys och beskrivning av de grundläggande principerna för COM, varefter dokumentationen av en komplett implementerad Windowsapplikation finns. Applikationen är utvecklad i C++ och bygger på och exemplifierar den inledande COM teorin, och tar samtidigt principerna för Software Engineering i beaktande. Specifikt är applikationen en RDS (Random Dot Stereoimage) generator, som med hjälp av matematik i tre dimensioner och DirectX skapar äkta tredimensionella bilder på skärmen, vilket är möjligt tack vare människans stereoseende. Resultatet är en syntes av teori och praktik till en sammanhängande bild av den nutida och framtida
    [Show full text]
  • Internet Explorer
    Internet Explorer From Wikipedia, the free encyclopedia Jump to: navigation, search Windows Internet Explorer Wikipedia's Main Page in Windows Internet Explorer 7 running on Windows Vista. Developed by Microsoft Initial release August 1995 (12–13 years ago) Latest release 7.0.5730.13 (Windows XP/Windows 2003 Server) 7.0.6001.18000 (Windows Vista SP1) / 2008 Preview release 8.0.6001.17184 (IE8, Beta 1) / March 5, 2008 OS Microsoft Windows Mac OS System 7 to Mac OS X (discontinued) Solaris and HP-UX (discontinued) Genre Web browser and RSS Reader License Proprietary EULA Website microsoft.com/ie Windows Internet Explorer (formerly Microsoft Internet Explorer abbreviated MSIE), commonly abbreviated to IE, is a series of graphical web browsers developed by Microsoft and included as part of the Microsoft Windows line of operating systems starting in 1995. It has been the most widely used web browser since 1999, attaining a peak of about 95% usage share during 2002 and 2003 with IE5 and 6 but steadily declining since, despite the introduction of IE7. Microsoft spent over 100 million dollars (USD) a year [1] in the late 1990s, with over 1000 people working on IE by 1999. [2] Internet Explorer was first released as part of the add-on package Plus! for Windows 95. Later versions were available as free downloads, or in service packs, and included in the OEM service releases of Windows 95 and later versions of Windows. The most recent release is version 7.0, which is available as a free update for Windows XP Service Pack 2, and Windows Server 2003 with Service Pack 1 or later, Windows Vista, and Windows Server 2008.
    [Show full text]
  • Dot Net Technology Notes (BCA 602)
    Dot Net Technology Notes (BCA 602) BCA VI UNIT I & UNIT II Ms. POONAM VERMA Syllabus The .Net Framework:Introduction Introduction Common Language Runtime (CLR) Common Type System (CTS) Common Language Specification (CLS) Microsoft Intermediate Language (MSIL) Just-In –Time Compilation Framework Base Classes. C -Sharp Language (C#): Introduction Data Types, Identifiers, Variables, Constants and Literals Array and Strings Object and Classes Inheritance and Polymorphism Operator Overloading Interfaces, Delegates and Events Type conversion. C# Using Libraries Namespace- System Input-Output, Multi-Threading, Networking and sockets, Managing Console I/O Operations, Windows Forms, Error Handling. Advance Features using C# Web Services, Window Services, Asp.net Web Form Controls, ADO.Net. Distributed Application in C#, Unsafe Mode, Graphical Device interface with C#. Assemblies and Attributes .Net Assemblies Attributes Generic. 3 Unit-1 Introduction to .Net framework 1. 1 Introduction to Dot Net Framework The .NET is the technology from Microsoft, on which all other Microsoft technologies will be depending on in future. It is a major technology change. Just like the computer world moved from DOS to Windows, now they are moving to .NET. But don't be surprised if you find anyone saying that "I do not like .NET and I would stick with the good old COM and C++". There are still lot of people who like to use the bullock-cart instead of the latest Honda car. .NET technology was introduced by Microsoft, to catch the market from the SUN's Java. Few years back, Microsoft had only VC++ and VB to compete with Java, but Java was catching the market very fast.
    [Show full text]
  • Exploit Development Ch 6: the Wild World of Windows
    Exploit Development Ch 6: The Wild World of Windows Revised 8-3-19 Topics • Win32 API, DLLs, and PE Files • Heaps • Threading • DCOM • Exception Handling • Debuggers Win32 API, DLLs, and PE Files Windows API (Application Programming Interface) • In Linux, a programmer can talk directly to the kernel with syscalls (INT 0x80) • But in Windows the kernel is only accessible through the Windows API • Implemented as a set of DLLs • Changes with each Windows version and Service Pack Windows API (Application Programming Interface) • Every process using the Windows API must use dynamic linking to the DLLs • The Windows API changes more often than Linux Syscalls do • Here's an API call to make a window DLLs (Dynamic Link Libraries) • Pre-compiled library code • Loaded as needed when executable files run • You can see loaded DLLs with Process Explorer – View, Lower Pane View, DLLs – Link Ch 6b PE (Portable Executable) Files • Format used for .EXE and .DLL files – And some other extensions (link Ch 6c) • Can be loaded on every 32-bit (or 64-bit) Windows version • Contains information about all required DLLs • Easy to see with PEView (link Ch 6d) Import Table for Notepad • Windows Server 2008 Version Sections of a PE File • .text – instructions to execute • .data – global variables • .idata – Import descriptors • .rsrc – Resources (icons, etc.) • .reloc – Relocation data Relocating PE Files • DLLs have a Base Address – This is where they are designed to load • But two DLLs might have the same Base Address – And both be used by the same EXE • One of
    [Show full text]
  • Virus Bulletin, August 2000
    ISSN 0956-9979 AUGUST 2000 THE INTERNATIONAL PUBLICATION ON COMPUTER VIRUS PREVENTION, RECOGNITION AND REMOVAL Editor: Francesca Thorneloe CONTENTS Technical Consultant: Matt Ham Technical Editor: Jakub Kaminski COMMENT Divided We Fall 2 Consulting Editors: NEWS & VIRUS PREVALENCE TABLE 3 Nick FitzGerald, Independent consultant, NZ Ian Whalley, IBM Research, USA LETTERS 4 Richard Ford, Independent consultant, USA VIRUS ANALYSIS Edward Wilding, Maxima Group Plc, UK What’s New, PussyCats? 6 TECHNICAL FEATURE IN THIS ISSUE: Moving to Windows 2000 8 • Pack-a-Mac: In the coming months VB will be initiating FEATURE Comparative Reviews for Macintosh products. Full testing The Number of the Beasts 10 protocols, proposed schedules and submission criteria are outlined on p.22. BOOK REVIEW To Boldly Go? 12 • The numbers game: Denis Zenkin is a self-confessed virus prevalence table junkie. He shares his findings over CONFERENCE REPORT the past few years in his Feature on p.10. Tracking Bugs in Ontario 13 • Happy new network? Millennium fever is well and truly OPINION over but what is the reality about moving your corporate network over to Win2K? Péter Ször investigates on p.8. Form, Concept and Other Pleasant Utilities 14 A DAY IN THE LIFE Manic Monday 16 PRODUCT REVIEW VirusBuster for NT 18 REVIEW NEWS Of Macs and Men 22 END NOTES AND NEWS 24 VIRUS BULLETIN ©2000 Virus Bulletin Ltd, The Pentagon, Abingdon, Oxfordshire, OX14 3YP, England. www.virusbtn.com /2000/$0.00+2.50 No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form without the prior written permission of the publishers.
    [Show full text]
  • Vysoké Učení Technické V Brně Brno University of Technology
    VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÉ GRAFIKY A MULTIMÉDIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA AUTOMATICKÉ ZNAČKOVÁNÍ PREZENTACÍ DIPLOMOVÁ PRÁCE MASTER‘S THESIS AUTOR PRÁCE Bc. MICHAL HUŠKA AUTHOR BRNO 2007 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV POČÍTAČOVÉ GRAFIKY A MULTIMÉDIÍ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA AUTOMATICKÉ ZNAČKOVÁNÍ PREZENTACÍ AUTOMATIC TAGGING OF PRESENTATIONS DIPLOMOVÁ PRÁCE MASTER‘S THESIS AUTOR PRÁCE Bc. MICHAL HUŠKA AUTHOR VEDOUCÍ PRÁCE doc. Dr. Ing. JAN ČERNOCKÝ SUPERVISOR Mgr. ROBERT BATŮŠEK, Ph.D. BRNO 2007 Zadání diplomové práce Téma: Automatické značkování prezentací Vedoucí: Černocký Jan, doc. Dr. Ing., UPGM FIT VUT Přihlášen: Huška Michal, Bc. Zadání: Úkolem je vyvinout systém, který bude schopen snímat kamerou plátno, na které je promítána prezentace. Pokud dojde na plátně k výměně snímku nebo jiné změně (např. animace), program zaznamená synchronizační značku do souboru. Program má být navržen tak, aby byl schopen provozu na mobilním telefonu a v podmínkách běžné posluchárny. 1. Prostudujte možnosti přístupu ke kameře na mobilních zařízeních. 2. Navrhněte a implementujte algoritmy pro detekci plátna. 3. Navrhněte a implementujte metody pro detekci změny slajdu. 4. Testujte na reálných datech 5. Navrhněte možnosti eliminace vlivu osoby pohybující mezi kamerou a plátnem. Část požadovaná pro obhajobu SP: Body 1. a 2. zadání Kategorie: Zpracování obrazu Implementační jazyk: C++ Operační systém: Windows Mobile Literatura: • podle pokynů vedoucího Komentář: Diplomová práce je společným projektem FIT a ANF Data. Licenční smlouva Licenční smlouva je uložena v archivu Fakulty informačních technologií Vysokého učení technického v Brně.
    [Show full text]
  • Dark.Netdark.Net
    Dark.NetDark.Net gasgasgasgas 1 簡介簡介 MalwareMalware DotDot NetNet FrameworkFramework .net.net rootkitrootkit AntiAnti techtech QQ && AA 2 MalwareMalware 3 MalwareMalware VirusVirus BackdoorBackdoor TrojanTrojan horsehorse RootkitRootkit ScarewareScareware AdwareAdware WormWorm 4 InfectInfect ExecutableExecutable InterpretedInterpreted filefile KernelKernel ServiceService MBRMBR HypervisorHypervisor 5 HypervisorHypervisor rootkitrootkit AppApp AppApp TargetTarget OSOS HardwareHardware 6 HypervisorHypervisor rootkitrootkit AppApp AppApp RogueRogue appapp TargetTarget OSOS HostHost OSOS VirtualVirtual machinemachine monitormonitor HardwareHardware 7 MalwareMalware designdesign && techtech MetamorphismMetamorphism ObfuscationsObfuscations AntiAnti--emulationemulation AntiAnti--VirtualVirtual MachineMachine AntiAnti--debuggersdebuggers RootkitRootkit TechnologyTechnology 8 MetamorphismMetamorphism push ecx mov ecx, [ebp + 10] push ecx mov ecx, ebp mov ecx, ebp push eax push eax add eax, 2342 push ecx mov eax, 33 mov eax, 33 mov ecx,ebp add ecx, eax add ecx, eax push ecx mov [ebp - 3], eax add ecx,33 pop eax pop eax mov ecx,ebp push esi mov eax, esi add ecx,33 mov esi,ecx push esi push eax mov [ecx-36],eax sub esi,34 mov esi, ecx mov esi, ecx pop ecx mov [esi-2],eax push edx push edx pop esi xor edx, 778f pop ecx mov edx, 34 mov edx, 34 sub esi, edx sub esi, edx pop edx pop edx mov [esi - 2], eax mov [esi-2], eax pop esi pop esi pop ecx pop ecx 9 ObfsucationsObfsucations NORMAL CALL OBFUSCATED CALL L0a: push L1 L0b: push L5 L0: call L5 L0c: ret L1: … L1: … L2: … L2: … L3: … L3: … L4: … L4: … L5: <proc> L5: <proc> L6: … L6: … Call Obfsucations to prevent static analysis 10 AntiAnti--emulationemulation vsvs antianti--debugdebug AntiAnti--debugdebug • Hide the fact that someone with a debugger is stepping/monitoring your program • Focus in differences in system when a debugger is active vs not Memory structures Time usage (ticks) API behaviour Suspicious windows/drivers/services, e.g.
    [Show full text]