[c#]data inbrengen in draaiend programma

[KillerZero86]

Ik heb een omschrijving van een idee, maar dit levert geen resultaten bij google op. Dus wou ik graag weten of jullie weten of iets dergelijks bestaat:

Op het moment dat een programma al gecompileerd is en draait is het dan mogelijk om bijvoorbeeld via een batch commando een soort parameter in het programma te schieten? Deze wordt dan opgepakt op een manier zoals bijvoorbeeld ook de timed event werkt:

code:

void timer_Elapsed(object sender, ElapsedEventArgs e)

Zodra de timer is afgelopen wordt dit event uitgevoerd.

Iemand een idee?

[Matis]

Begrijp ik het goed dat je een draaiende applicatie (laten we het voor het gemak een exe noemen) wilt aanpassen?

Dat riekt naar wat veel virussen doen, dus ik denk dat je sws problemen krijgt met een virusscanner, daarnaar zou je moeten weten waar de functie-pointer van de timer_Elapsed zich bevindt in de exe en die dan laten wijzen naar een ander stukje geheugen.

[KillerZero86]

Misschien ligt het aan mijn uitleg, dus even anders:

Stel: ik schrijf een programma. Dit programma kent twee modussen en een gui. Op de gui staat een checkbox, als deze ingeschakeld staat is modus 1 geactiveerd, anders modus twee. De gebruiker kan deze checkbox aanpassen om zo te switchen tussen deze modussen. Waar ik naar op zoek ben is een manier om een tweede programma de boolean die aan de checkbox gekoppeld zit te kunnen laten veranderen veranderen. Niets met virussen te maken dus =)

[urk_forever]

Na even wat snel zoeken kom ik op twee mogelijkheden uit:

.Net Remoting
of
Windows Communication Foundation

Microsoft geeft zelf al aan dat Remoting legacy is, dus je kan dan het beste naar WCF kijken.

Wat je kan doen is in app1 een WCF service maken die het mogelijk maakt de modus te switchen en deze te hosten in app1 en vervolgens vanuit app2 die service aanroepen.

Hier nog wat meer informatie:
StackOverflow
Google zoeken

[RobIII]

Zoekterm: IPC
Het kan met WCF, maar dat is misschien wat overkill voor een enkele toggle functie. Met een socket, named pipe of misschien zelfs het lezen van StdIn kom je ook een heel eind, en er zijn nog 2.000 alternatieve methoden.

[KillerZero86]

Al deze dingen zijn toch nog.. te uitgebreid. Ze gaan er allemaal vanuit dat je antwoord wilt hebben (voor wat ik lees) en ik ben op zoek naar iets veel simpelers. Nog eenmaal een poging tot een uitleg:

Ik heb een kinect programma. In dit programma kan je rechterhand twee dingen doen: de muis aansturen of voor arrowkeys spelen. Dit programma werkt volledig op zichzelf, heeft alleen Windows OS nodig om te kunnen werken.

Dit programma is onderdeel van een veel groter schoolproject, deze overdekt heel windows in haar eigen GUI jasje (vergelijkbaar met XMBC). Dit houdt in dat mijn kinect programma normaal gesproken onzichtbaar is. Op dit moment gaat het wisselen tussen key mode en mouse mode met een boolean op de GUI van mijn kinect programmatje, maar daar kom je later niet meer bij. Dus ik wil in het kinect programma een methode. Deze wordt aangeroepen op een zeker moment bijvoorbeeld als iemand in batch "kinect.exe stop" intyped. In de methode wordt de String "stop" opgevangen en daarna this.exit() uitgevoert.

Dus gewoon een hele simpele methode, wat lijkt hier het meest op?

[kluyze]

Zoals RobIII al aangeeft is dit IPC

Socket server en client ^{C# voorbeeld link} maken is echt geen rocketscience. En zo simpel als het maar kan.

Om properties te toggelen kan je nog een config file of database tabel maken, waar jouw kinect software continu van leest. Dan kan je die properties in je file of database extern benaderen.
Aan/uit zetten van een applicatie kan zo ook maar vind ik een minder mooie oplossing.
(Ik zou dan eerder met een aparte file in de main folder van de applicatie werken ala. kinect.start, als de kinect applicatie die vind, en er staat eventueel een bepaalde code in als beveiliging, dan doe een exit() )

Als je met files zou gaat werken, bedenk je dan even wat er gebeurt als je gaat schrijven naar de file op het moment dat je kinect software deze uitleest.

[Mysteryman]

Wat je ook zou kunnen doen is een 'service' maken. Op deze manier kan je in een cmd gewoon 'service kinect stop' doen en je applicatie/service stopt.
Als je vervolgens 'service kinect start' doet, start de service/applicatie weer

[RobIII]

En hoe toggled dat een state

[KillerZero86]

Socket blijkt een geniale oplossing, dank RobIII en kluyze!

Ten slotte heb ik nog een vraagje: hoe gevaarlijk is dit?
Als ik doe:

C#:

Int32 port = 13000;
IPAddress localAddr = IPAddress.Parse("127.0.0.1");
server = new TcpListener(localAddr, port);

En ik poort 13000 open in mijn firewall, kan iemand dan van buitenaf bij dit programma?

[P-Storm]

Volgens mij is het voor je localhost niet nodig dat je een poort open gooit. Maar probeer het uit en test het zou ik zeggen. Als het niet nodig is om een poort te openen zou ik het niet doen.

Kan je niet instellingen van een server applicatie halen, of iets die richting in? Dan kan je een of meerdere programma's gebruiken om de instellingen op te halen of te veranderen.

[Hyperz]

Persoonlijk zou ik het oplossen door een d.m.v. een Mutex zodanig dat je gemakkelijk kunt checken of er al een instance draait (en je dus weet of je het hele programma moet opstarten of gewoon commands moet sturen naar de al draaiende instance) en Named Pipes (om data naar de andere instance te sturen).

Zie: Mutex | Named Pipes voorbeeld

[evolution536]

Een socket gebruiken om via een tcp verbinding de boolean om te zetten lijkt me een goede oplossing. als je dit anders zou willen doen kom je meer in de buurt van DLL/code injectie, of het opzoeken van geheugenadressen en pointers d.m.v. cheatengine

[Matis]

evolution536 schreef op maandag 21 november 2011 @ 08:51:
Een socket gebruiken om via een tcp verbinding de boolean om te zetten lijkt me een goede oplossing. als je dit anders zou willen doen kom je meer in de buurt van DLL/code injectie, of het opzoeken van geheugenadressen en pointers d.m.v. cheatengine

Dat is inderdaad precies wat ik voorstelde in de eerste reply. Echter had ik de TS verkeerd begrepen.

Named pipes zijn voor locale processen erg geschikt. Wanneer de TS vanaf een andere machine zijn applicatie wil laten besturen, dan denk ik dat de TCP-socket het netste is.

[urk_forever]

Je zou ook nog iets kunnen doen met een filesystemwatcher en een xml bestandje waar de opties in staan. App1 houd dan een bepaalde directory in de gaten, App2 schrijft er een bestandje in weg met de opties. De FileSystemWatcher vuurt een event af als dat gebeurd. Vervolgens lees je het bestandje uit in App1 en zet je de goede optie.

[KillerZero86]

Ik ben erg content met de TCP/ICP oplossing. En nu heb ik nog een vraag, en ik hoop dat die in hetzelfde topic mag:

De TCP server is slechts een klein onderdeel van eht totaal programma, maar moet wel constant draaien. Een aparte thread dus. Maar deze thread moet terug rapporteren aan de main. De backgroundworker is een mooie, maar heeft twee nadelen: het kan niet in een andere class (ik vervuil mijn main nu met code die daar niet strikt thuishoort) en het reporting mechanisme kan alleen een getal van 0 tm 100 terugsturen, het moet een percentage zijn van zijn progress. Ook lijkt me de oneindige loop die ik toepas om de server up te houden zo lang als dat het programma aanstaat niet echt het beoogde doel van een BackgroundWorker. Een ander alternatief is om een losse thread aan te maken en 1 variabele te delen, maar ook dit voelt erg vies aan. Is er geen methode die specifiek ontworpen is om een losstaande thread te zijn die heel nauw contact houdt met zijn "maker"?

[HMS]

Kan je niet gewoon een aparte class maken (TCPServer) en die een reference naar je mainprogram mee geven? En dan vanuit TCPServer functies aanroepen op je main?

[RobIII]

De TCP Listener kent toch gewoon asynchrone methodes? (BeginAcceptXXX/EndAcceptXXX)? En met de verkregen socket danwel TcpClient kun je vervolgens ook weer asynchrone methodes gebruiken. Alle asynchrone methodes beginnen met BeginXXX en hebben een bijbehorende EndXXX; zo heb je op een networkstream bijvoorbeeld BeginRead/EndRead en BeginWrite/EndWrite. Zolang je niet heel veel verwerkt in deze methodes moeten deze prima volstaan.

Een backgroundworker is hier niet heel erg geschikt voor, precies om de reden(en) die je zelf al aangeeft. En je moet sowieso al helemaal geen code in je main(form) stoppen die hier mee te maken heeft (als ik je goed begrijp doe je dat nu). Stop 't gewoon in een aparte class die alles op TCP/IP niveau voor je afhandelt en raise events ofzo afhankelijk van de verkregen "externe input".

KillerZero86 schreef op dinsdag 22 november 2011 @ 21:58:
maar ook dit voelt erg vies aan. Is er geen methode die specifiek ontworpen is om een losstaande thread te zijn die heel nauw contact houdt met zijn "maker"?

Events/delegates.

[ Voor 89% gewijzigd door RobIII op 22-11-2011 22:18 ]

[farlane]

KillerZero86 schreef op dinsdag 22 november 2011 @ 21:58:
Is er geen methode die specifiek ontworpen is om een losstaande thread te zijn die heel nauw contact houdt met zijn "maker"?

Volgens mij kun je bij de meeste thread start functies etc een context object meegeven, die kun je vervolgens vanaf beide kanten benaderen.

Natuurlijk moet je wel rekening houden met synchronisatie etc.

[curry684]

Wat kunnen jullie veel scheepskanonnen en kernraketten bedenken om een mug dood te schieten

Voor een simpele kernel-waitable cross-process boolean pak je gewoon een named event. In .NET maak je die via de EventWaitHandle base class. En ineens heb je met 1 regel code aan allebei de kanten een boolean die je aan allebei de kanten kunt uitlezen en (re)setten.

[RobIII]

curry684 schreef op woensdag 23 november 2011 @ 02:04:
En ineens heb je met 1 regel code aan allebei de kanten een boolean die je aan allebei de kanten kunt uitlezen en (re)setten.

En ineens heb je een blocking wait (Correct me if I'm wrong) En daarbij moet je 't dan op simpele signalling houden.

[ Voor 12% gewijzigd door RobIII op 23-11-2011 02:29 ]

[curry684]

RobIII schreef op woensdag 23 november 2011 @ 02:27:
[...]

En ineens heb je een blocking wait (Correct me if I'm wrong). En daarbij moet je 't dan op simpele signalling houden.

Welke blocking wait? Om de state van een ManualResetEvent op te vragen doe je gewoon een WaitOne met timeout 0:

quote: http://msdn.microsoft.com/en-us/library/cc189907.aspx

If millisecondsTimeout is zero, the method does not block. It tests the state of the wait handle and returns immediately.

En de vraag is voor zover ik kan zien nog steeds een bi-state cross-process shared variable, dus simpele signalling voldoet.

[ Voor 15% gewijzigd door curry684 op 23-11-2011 02:30 . Reden: stiekem bij-editen robje! ]

[RobIII]

curry684 schreef op woensdag 23 november 2011 @ 02:29:
[...]

Welke blocking wait? Om de state van een ManualResetEvent op te vragen doe je gewoon een WaitOne met timeout 0:

[...]

Ja, maar dan moet je dus met een timer gaan klooien ofzo.

[curry684]

RobIII schreef op woensdag 23 november 2011 @ 02:30:
[...]

Ja, maar dan moet je dus met een timer gaan klooien ofzo.

Waarom dat, voor zover ik de vraag begrijp heeft kinect.exe z'n eigen logica aan boord om op events van de Kinect sensor te reageren, en wil ie alleen in dat programma aan een boolean kunnen aflezen of ie deze input moet parsen als muis (false) of arrows (true), en moet die boolean vanuit een extern proces gewijzigd kunnen worden. Ik mis de noodzaak tot timers.

[RobIII]

Ooooh; kinect.exe gaat die bool pollen elk (input)event. My bad, dan heb ik niets gezegd
Ik ben hier ergens 't overzicht verloren tussen wat nou waar wie doet

curry684 schreef op woensdag 23 november 2011 @ 02:29:
En de vraag is voor zover ik kan zien nog steeds een bi-state cross-process shared variable, dus simpele signalling voldoet.

Nou, ik trok andere conclusies hieruit. Maar misschien dat ik dat ook verkeerd begrepen heb.

[ Voor 84% gewijzigd door RobIII op 23-11-2011 03:16 ]

[curry684]

RobIII schreef op woensdag 23 november 2011 @ 02:38:
Nou, ik trok andere conclusies hieruit. Maar misschien dat ik dat ook verkeerd begrepen heb.

Dat hele probleem is ergens verdwenen samen met die 500 regels aan asynchronous TCP-server code die je hem hebt aangepraat... again, als ik het goed begrijp

[pedorus]

RobIII schreef op woensdag 23 november 2011 @ 02:27:
[...]

En ineens heb je een blocking wait (Correct me if I'm wrong) En daarbij moet je 't dan op simpele signalling houden.

Blocking wait is natuurlijk prima, je kan gewoon een thread laten wachten en dan een event terugsturen naar je main-thread. Maar aangezien je dus alleen simpele signalering kan doen, lijkt me het niet echt handig.

Een tcp-poort openhouden lijkt me niet heel netjes, ivm de birthday paradox kom je al snel in de problemen doordat meerdere applicaties dezelfde poort willen gebruiken.

Ik zou zelf iets doen met de al eerder genoemde named pipes. Even wat getest omdat ik wat weinig goede voorbeelden zag, en dit lijkt te werken:

C#:

        static void Main(string[] argv)
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            var f = new Form1();
            var unique = Application.ExecutablePath.Replace(':', '/') +
                "{941377EA-62FA-4CB6-899A-C71CBD61EE3F}";
            try
            {
                var pipe = new NamedPipeServerStream(unique);
                new Thread(() =>
                {
                    var s = new StreamReader(pipe);
                    while (true)
                    {
                        pipe.WaitForConnection();
                        var message = s.ReadToEnd();
                        pipe.Disconnect();
                        f.BeginInvoke((Action)(() => { MessageBox.Show(message); }));
                    }
                }) { IsBackground = true }.Start();
            }
            catch (IOException e)
            {
                using (var pipe = new NamedPipeClientStream(unique))
                {
                    pipe.Connect(5000); //note: exception on server gone/timeout
                    using (var stream = new StreamWriter(pipe))
                        stream.Write(argv.Length > 0 ? String.Join(" ", argv) : "!");
                }
                return;
            }
            Application.Run(f);
        }

KillerZero86 schreef op dinsdag 22 november 2011 @ 21:58:
De backgroundworker is een mooie, maar heeft twee nadelen: het kan niet in een andere class (ik vervuil mijn main nu met code die daar niet strikt thuishoort) en het reporting mechanisme kan alleen een getal van 0 tm 100 terugsturen, het moet een percentage zijn van zijn progress.

In principe is het belangrijkste nadeel dat dit geen echte worker is, completed is bijvoorbeeld geen nuttig event in deze context. Je kan prima een Backgroundworker in een aparte class zetten, en die 0-100 kan stiekem iedere int zijn en je kan ook nog een willekeurig object teruggeven bij de progress. Maar eigenlijk kun je dan beter zelf een Thread maken en SynchronisationContext of Invoke gebruiken.

[curry684]

Hoewel ik het er direct mee eens ben dat voor local communications named pipes beter zijn dan TCP-hax mis ik nog steeds de complete noodzaak voor een open communicatiepijp. Voor het simpelweg delen van wat informatie zijn zoveel betere mechanismes die minder performance kosten en minder regels code. Als er meer gedeeld moet worden dan enkel een boolean is een simpele memory mapped file ook nog gewoon een eenvoudige optie...

Wellicht kan topicstarter met z'n huidige inzichten z'n totaalprobleem nog eens een keer goed verwoorden?

[KillerZero86]

Ik gaat nog eens een poging wagen dan.

Op school ben ik 2de jaart TI HBO student, en ik werk aan een project. Dit project gebeurt met een aantal man en beslaat verschillende onderdelen, ieder onderdeel heeft zijn eigen exe, dit omdat er meerdere prorammeertalen gebruikt worden en dat dan weer omdat we vaak open source projecten uitbreiden.

Mijn onderdeel is Kinect, maar dat is eigenlijk nauwelijks relevant vor het probleem, deze is namelijk dat alle programma's moeten praten met elkaar. Het begint in mijn programma met simpele commands als AbsoluteMouseInput, DisableSkeletalTracking, LaunchDebugScreen, enzovoorts. Ieder ander programma uit ons project moet mijn kinect programma kunnen vertellen dat we overgaan van relatieve naar absolute muisbesturing of zelfs dat mijn programma even helemaal op moet houden met tracken. Dat maakt voor mij TCP zo ideaal: het bestaat in iedere taal en Strings uitwisselen kunnen ze allemaal.
Ook is hier veel ruimte voor uitbreiding: ik kan zelfs het beeld dat uit de kinect komt omzetten anar een byte[] en deze wegsturen naar een ander programma. TCP lijkt voor mij nu dus ideaal: oersimpel te implementeren en werkt voor iedere taal.
Dat was probleem 1.

Vlak erna ontstond probleem twee: ik heb een thread nodig die de main niet ophoudt maar er wel mee praat. Hiervoor ben ik me in gaan lezen in events/delegates en vor wat ik er nu van zie lijkt het goed te werken. Let wel: ik heb er nog niet eens een test app voor geschreven

[curry684]

Ah kijk dan is je probleem inderdaad van een vorm waarin een open doorlopende communicatielijn belangrijk is, dan is TCP al niet meer zo'n vreemde optie.

Voor je 2e probleem kun je simpelweg gebruik maken van standaard mutexes e.d., tenzij je ook nog Windows Forms Controls moet aansturen - in dat geval even hier klikken.

[pedorus]

curry684 schreef op woensdag 23 november 2011 @ 12:37:
Voor het simpelweg delen van wat informatie zijn zoveel betere mechanismes die minder performance kosten en minder regels code. Als er meer gedeeld moet worden dan enkel een boolean is een simpele memory mapped file ook nog gewoon een eenvoudige optie...

Performance lijkt me niet een issue, en is ongeveer hetzelfde. Aangezien named pipes zeer waarschijnlijk gewoon een schil om memory mapped files zijn, lijkt het me sterk dat memory mapped files minder code kosten dan die <30 regels hierboven.

Niettemin is TCP waarschijnlijk een betere keus onder windows aangezien bijv. java er anders niet bij kan.

KillerZero86 schreef op woensdag 23 november 2011 @ 13:58:
Vlak erna ontstond probleem twee: ik heb een thread nodig die de main niet ophoudt maar er wel mee praat. Hiervoor ben ik me in gaan lezen in events/delegates en vor wat ik er nu van zie lijkt het goed te werken. Let wel: ik heb er nog niet eens een test app voor geschreven

In het meest simpele geval zet je gewoon ergens een globale boolean die in de mainthread wordt uitgelezen, en heb je dus geeneens events of delegates nodig. Hangt er helemaal vanaf hoe het wachten in de mainthread werkt, bij windows forms is bijvoorbeeld BeginInvoke waarschijnlijk het handigst.

[curry684]

pedorus schreef op woensdag 23 november 2011 @ 15:19:
[...]

Performance lijkt me niet een issue, en is ongeveer hetzelfde. Aangezien named pipes zeer waarschijnlijk gewoon een schil om memory mapped files zijn, lijkt het me sterk dat memory mapped files minder code kosten dan die <30 regels hierboven.

Mwah, MMF ben je het hele gezeik van de omliggen FIFO-queuing kwijt natuurlijk. Performance zal niet echt merkbaar zijn nee, maar qua code-simpliciteit is het toch wel stukken simpeler en overzichtelijker als je gewoon een soort van shared struct nodig hebt en niet een vorm van 'messaging' logica.

Niettemin is TCP waarschijnlijk een betere keus onder windows aangezien bijv. java er anders niet bij kan.

Gezien het hier om een soort van generic plugin architecture lijkt te gaan inmiddels staat dat buiten kijf ja

[pedorus]

curry684 schreef op woensdag 23 november 2011 @ 17:50:
stukken simpeler en overzichtelijker als je gewoon een soort van shared struct nodig hebt en niet een vorm van 'messaging' logica.

offtopic:
Oneens, het is bijna hetzelfde behalve dat het meer code is omdat je nu zelf de synchronisatie met bijv, mutexen moet doen.

[evolution536]

Je zegt dat je projectgroepleden in andere programmeertalen werken aan projecten. Met welke talen werken zij?

Kijk, met CheatEngine kun je gegevens uitlezen en wegschrijven in zowel geheugenadressen van een proces, maar ook in pointers. Zowel met C# als met C++ (misschien een van de talen waar je projectleden mee werken?). Dit lijkt mij een handige oplossing. Als je in je C# programma een pointer maakt die wijst naar een van je variabelen die de boolean bevat die je graag wilt manipuleren, kun je in de andere programma's in alle waarschijnlijkheid de pointer vinden, en aanpassen.

Let op, dit is alleen een idee voor het geval dat je projectleden ook C# of C++ gebruiken. Dit zijn naar mijn weet (ik ben ook maar een simpele ICT beheerder MBO niveau 4 ) 2 talen waarin dit mogelijk is.

Voor het schrijven naar geheugenadressen vanuit C# (en als je dat wilt ook c++) is dit wellicht een leuke oplossing. Ik heb deze gebruikt bij het maken van trainers voor spellen in C#.

WriteProcessMemory
ReadProcessMemory
GetWindowThreadProcessId

Dit is iets wat ik bedacht omdat ik "denk" dat ik je snap, als ik het mis heb dan sorry

[RobIII]

evolution536 schreef op donderdag 24 november 2011 @ 20:52:
Dit is iets wat ik bedacht omdat ik "denk" dat ik je snap, als ik het mis heb dan sorry

Ja, geheugen is gewoon een stapel bits in de bankjes op je mobo. Maar geheugen is niet iets waar je "vanaf de buitenkant" (lees: buiten je eigen proces) zomaar in gaat lopen rommelen. Wat cheatengine doet is héél iets anders dan wat je hier nodig hebt en is ook verre van wat je IPC mag noemen

Leesvoer.
En, als je goed kijkt boven aan de pagina's waar je naar linkt had je ook dit gezien:
_{... > Reference > Diagnostics > Debugging and Error Handling > Basic Debugging > Debugging Reference > Debugging Functions > ReadProcessMemory}
Dat had 't waarschijnlijk ook wel weggegeven Read/Write-ProcessMemory functies zijn voor debuggingdoeleinden, niet voor IPC Je moet dan eerder eens gaan kijken bij:
_{... > Reference > System Services > Interprocess Communications}

[ Voor 67% gewijzigd door RobIII op 24-11-2011 22:58 ]

[curry684]

En als je al met 2 processen in een gedeeld stuk geheugen wil lezen en schrijven zijn de eerder geopperde MemoryMapped Files toch wel een iets netter en handzamer alternatief