[win32] Meerdere instanties van client starten

[Gertjan]

Van een bepaald mobiel platform wordt door de fabrikant een win32-client meegeleverd, om vanuit Windows met het platform te kunnen connecten/synchroniseren. Van deze client kan echter maar 1 instantie opgestart worden. In verband met test-doeleinden wil ik op 1 pc meerdere clients kunnen draaien, maar het programma biedt hier zelf dus geen mogelijkheden voor.

Ik weet niet precies of de beperking van maar 1 instantie door het OS wordt geregeld, of door het programma zelf, maar ik vermoed het laatste. Ik ben dus op zoek naar mogelijkheden om het programma te foppen en zo meerdere clients te kunnen starten.

Ik heb dit topic in P&W gezet, omdat ik denk dat dit op te lossen moet zijn met een soort wrapper, die de clients start. Ik vindt het alleen erg lastig om hier zoekwoorden voor te bedenken, en heb verder geen aanknopingspunten.
Kan iemand me een zetje in de goede richting geven?

[ Voor 1% gewijzigd door Gertjan op 18-11-2005 11:03 . Reden: dt -> d :X ]

[curry684]

Meestal lossen programma's dit op door het registreren van een named kernel object, zijnde een mutex of event. Daar is niet omheen te werken behalve door het gebruiken van virtual servers, wat sowieso voor test-doeleinden een goed idee is

[TallManNL]

Af en toe wil het nog wel eens lukken door m.b.v run as (mogelijk alleen XP) het programma onder een ander account te draaien. Hiervoor is het wel nodig dat de 'Secondary Logon' service draait. Of het lukt hangt echter volledig af hoe het programma de meerdere instanties tegengaat. Sommige scannen de running processes van de current user, sommige checken alle processes en anderen werken zoals curry684 al zei met named kernel objects. Alleen in de eerste situatie zal mijn suggestie werken.

Anyway:
Rightclick op icoontje, kijk of er "Run as..." in je contect menu staat. selecteer die en selecteer een andere user.

[jvdmeer]

TallManNL schreef op vrijdag 18 november 2005 @ 10:54:
Anyway:
Rightclick op icoontje, kijk of er "Run as..." in je contect menu staat. selecteer die en selecteer een andere user.

Die zal er nooit staan, tenzij je samen met de rechtermuisknop ook de shift-toets indrukt.

[Gertjan]

@curry
Ok, bedankt voor die named kernel objects, geeft me weer wat leesvoer . Hoe zit dat met die virtual servers, het klinkt als een enorme overhead op je systeem als je een virtual server nodig hebt voor elke client. Of zit ik met een andere soort virtual server in mijn hoofd? Heb je hier misschien wat meer informatie over, een linkje bijvoorbeeld?
We hebben van de fabrikant van de software al te horen gekregen dat zij tot 200 van deze clients op een gewone computer kunnen draaien. Maar misschien dat zij net een iets andere versie gebruiken, zij hebben de sourcecode per slot van rekening. Helaas zijn ze niet zo scheutig met informatie

@TallManNL
Thnx, maar het werkt niet om het als een andere user te draaien. Dan krijg ik gewoon de eerste instantie weer terug.

[TallManNL]

jvdmeer schreef op vrijdag 18 november 2005 @ 11:07:
[...]


Die zal er nooit staan, tenzij je samen met de rechtermuisknop ook de shift-toets indrukt.

Via de remote desktop test die ik voor mijn test op mijn machine thuis uitvoerde (@work op win2000)
werkt het zonder shift iig voor shortcuts in de quicklaunch bar, inderdaad niet getest met desktop icons

Edit
Net getest via RDP weer, zowel desktop als start menu shortcuts krijg ik Run as altijd in het context menu te zien zonder shift toets in te duwen.

[ Voor 16% gewijzigd door TallManNL op 18-11-2005 11:20 ]

[curry684]

Ali_Illegali schreef op vrijdag 18 november 2005 @ 11:12:
@curry
Ok, bedankt voor die named kernel objects, geeft me weer wat leesvoer

To elaborate: de meest logische manier om een programma tot single-instance te beperken is de volgende (pseudo)code in de WinMain:

C++:

HANDLE singleInstanceGuard = CreateMutex(NULL, FALSE, "MyProgramNameGuard");
if(!singleInstanceGuard)
  HandleError();
else if(GetLastError() == ERROR_ALREADY_EXISTS)
{
  CloseHandle(singleInstanceGuard);
  ActivateOtherInstanceViaIPC();
  return 0;
}

Omdat named kernel objects gegarandeerd uniek zijn binnen het complete systeem zijn ze hier bij uitstek geschikt voor. Helaas houdt dat dus ook in dat er niet omheen te werken is

Hoe zit dat met die virtual servers, het klinkt als een enorme overhead op je systeem als je een virtual server nodig hebt voor elke client. Of zit ik met een andere soort virtual server in mijn hoofd? Heb je hier misschien wat meer informatie over, een linkje bijvoorbeeld?

MS Virtual Server
MS Virtual PC
VMWare

Wordt massaal gebruikt om te testen omdat je met relatieve low-overhead alle
OS'en in diverse configuraties op 1 computer kunt zetten, eigenlijk voornamelijk beperkt door HD-ruimte. En als je een virtuele bak om zeep helpt zet je een kopietje van de HD-image terug en na 2 minuten heb je weer een werkend systeem

We hebben van de fabrikant van de software al te horen gekregen dat zij tot 200 van deze clients op een gewone computer kunnen draaien.

In dat geval zouden ze iig geen kernel objects of named pipes gebruiken. Ik denk dat je er weinig aan hebt als ze niet vertellen hoe ze het wel controleren.

[Hydra]

Probeer eens een kopie van de executable te maken? Sommige programma's checken gewoon of er al een proces met die naam draait.

[jvdmeer]

TallManNL schreef op vrijdag 18 november 2005 @ 11:19:
[...]


Via de remote desktop test die ik voor mijn test op mijn machine thuis uitvoerde (@work op win2000)
werkt het zonder shift iig voor shortcuts in de quicklaunch bar, inderdaad niet getest met desktop icons

Edit
Net getest via RDP weer, zowel desktop als start menu shortcuts krijg ik Run as altijd in het context menu te zien zonder shift toets in te duwen.

Klopt, wat ik typte geldt inderdaad alleen voor de executable zelf.

[.oisyn]

Je kùnt er overigens wel omheen, maar dat vereist wat lowlevel hacking. Wat je moet doen is de entry voor CreateMutex in je import address table laten wijzen naar een functie van jezelf die je in de adress space van dat process hebt gezet (VirtualAllocEx(), WriteProcessMemory()). In die functie check je vervolgens of het de naam betreft van de mutex waarop gechecked wordt (hier kun je achter komen met wat debugwerk), zodat je in dat geval een bogus mutex terug kunt geven die lokaal is aan dat proces. Vervolgens denkt de applicatie gewoon dat ie de enige is en laat ie het runnen van meerdere instances toe.

Maar goed, de vraag is of je zoveel moeite wilt doen . Maar er is met google wel wat over te vinden, de keywords zijn "dll injection" en "import address table". Op www.sysinternals.com is vast ook wat info te vinden.

.edit: heh, sterker nog, [google=dll injection import address table], de eerste hit

[ Voor 7% gewijzigd door .oisyn op 18-11-2005 13:02 ]

[Verwijderd]

sorry voor de voorgaande post.

Pak Numega Softice, set hier en daar een "goede" breakpoint en zoek naar de check. patchen die hap en hoppla.
of pak w32dasm en zoek naar de error string die het programma geeft en trace terug tot je de check hebt gevonden. NOP de jump of de call en je bent klaaaaaaar! (laatste werkt niet altijd overigens)

[The Eagle]

Tsja, je kunt het moeilijk of makkelijk oplossen. Persoonlijk zou ik gewoon voor een aantal Virtual Machines gaan - maar dat moet je dan wel net voor handen hebben

[Gertjan]

Er zijn dus zo te zien in elk geval wel oplossingen te bedenken, ze verschillen alleen nogal in complexiteit . Ik ga er volgende week mee prutsen, dus we zullen zien wat het wordt.

The_Eagle schreef op vrijdag 18 november 2005 @ 13:13:
Tsja, je kunt het moeilijk of makkelijk oplossen. Persoonlijk zou ik gewoon voor een aantal Virtual Machines gaan - maar dat moet je dan wel net voor handen hebben

Dat klinkt op zich als de makkelijkste oplossing, maar een VM klinkt mij in de oren als zwaar, zeker als je er meerdere tegelijk gaat draaien. Daarnaast: een complete VM/VP gebruiken om 1 klein programmaatje te draaien, lijkt mij hetzelfde als een punaise in een prikbord drukken met een hamer. Maar goed, ik heb er geen ervaring mee, dus misschien valt het mee (iemand die dit kan bevestigen of ontkennen?)

[curry684]

Een VM met een computer die 2% CPU-tijd en 200Mb RAM gebruikt drukt op je computer voor 2% CPU-tijd en 200Mb RAM, that's all. En dat RAM wordt nog netjes gepaged ook, dus tenzij je er 10 tegelijk wil draaien geen probleem.

[The Eagle]

Tsja, je kunt er dan iig 2 tegelijk draaien
Ik heb hier op mijn werk een VM dev-omgeving (want onze ICT afdeling kreeg het door de veel te streng afgeregelde beveiliging niet voor elkaar mijn development-tools goed te laten werken) en met 1GB RAM merk je eigenlijk niet eens echt dat je op een ander station zit te werken. 512 is echter een beetje krap voor een VM versie van XP onder XP maar dat ligt er ook aan wat je er precies mee wilt doen. Mijn ervaring is iig dat mijn VM XP omgeving ca 350mb ram pakt. Dus dan moet jij denk ik wel ongeveer in kunnen schatten wat je nodig hebt

Bijkomend voordeel voor jou: extra RAM is goedkoper dan nieuwe machines. Met een beetje mazzel heb je als je ivm het testen extra RAM aanvraagt, ineens 2 gig ram, die je ook na de tests kunt houden omdat niemand er meer naar kraait

[Gertjan]

Tja, extra RAM is inderdaad niet zo duur, maar ik denk dat het voor onze opstelling toch redelijk aan de prijs gaat worden. Ik heb nu een Pentium 4 systeem met 512 MB RAM. Hierop kan ik ieg niet meer dan 10 VM's draaien. De bedoeling is echter om een schaalbare testomgeving te creeren, die tot 1000 clients moet kunnen simuleren. Met 10 VM's per computer hebben we hier denk ik niet voldoende pc'tjes staan . Om maar niet te spreken over het installeren van 10 VM's op 100 pc's .

Ik ga in elk geval even proberen hoe het performed, om een referentiepunt te hebben. Maar ik denk dat ik, ondanks de complexiteit, meer heb aan de manieren die .oisyn en jaxkz noemden.

Hydra schreef op vrijdag 18 november 2005 @ 11:47:
Probeer eens een kopie van de executable te maken? Sommige programma's checken gewoon of er al een proces met die naam draait.

Nope, werkt ook niet.

[ Voor 19% gewijzigd door Gertjan op 18-11-2005 14:46 ]

[Noork]

Ali_Illegali schreef op vrijdag 18 november 2005 @ 14:44:
....De bedoeling is echter om een schaalbare testomgeving te creeren, die tot 1000 clients moet kunnen simuleren. Met 10 VM's per computer hebben we hier denk ik niet voldoende pc'tjes staan . Om maar niet te spreken over het installeren van 10 VM's op 100 pc's .

En om ook maar niet te spreken over 1000 extra licenties voor je OS. Misschien kun je toch maar weer te raad gaan bij de leverancier.

[curry684]

Ali_Illegali schreef op vrijdag 18 november 2005 @ 14:44:
Ik ga in elk geval even proberen hoe het performed, om een referentiepunt te hebben. Maar ik denk dat ik, ondanks de complexiteit, meer heb aan de manieren die .oisyn en jaxkz noemden.

Daar heb je geen bal aan zolang je niet weet op welke manier ze single-instance guarden

Vergeet sowieso ook niet dat ze ipv named mutex ook named events, waitable timers, semaphores of pipes kunnen gebruiken. Hell, ze kunnen het zelfs met een hidden tempfile doen naast alle al genoemde opties. Of met FindWindow

[.oisyn]

Maar een named mutex is wel de meest gangbare, en als het idd klunsen zijn die FindWindow gebruiken ben je al snel klaar door gewoon even de windowtitle aan te passen

[MSalters]

curry684 schreef op vrijdag 18 november 2005 @ 11:38:
[...]

To elaborate: de meest logische manier om een programma tot single-instance te beperken is de volgende (pseudo)code in de WinMain:

C++:

HANDLE singleInstanceGuard = CreateMutex(NULL, FALSE, "MyProgramNameGuard");
if(!singleInstanceGuard)
  HandleError();
else if(GetLastError() == ERROR_ALREADY_EXISTS)
{
  CloseHandle(singleInstanceGuard);
  ActivateOtherInstanceViaIPC();
  return 0;
}

Omdat named kernel objects gegarandeerd uniek zijn binnen het complete systeem zijn ze hier bij uitstek geschikt voor. Helaas houdt dat dus ook in dat er niet omheen te werken is

Pessimist. Hoe dacht je dat die CreateMutex call werkt? Da's gewoon een DLL call (weliswaar naar de kernel, maar boeien). Inject een DLL, zet een breakpoint op CreateMutex, "fix" de mutex naam, en je bent klaar. Continue en de applicatie denkt dat hij de enige is.

[curry684]

MSalters schreef op vrijdag 18 november 2005 @ 22:12:
[...]

Pessimist. Hoe dacht je dat die CreateMutex call werkt? Da's gewoon een DLL call (weliswaar naar de kernel, maar boeien). Inject een DLL, zet een breakpoint op CreateMutex, "fix" de mutex naam, en je bent klaar. Continue en de applicatie denkt dat hij de enige is.

Ja dat zei oisyn ook al, maar ik had de rans-rans methodes voor gangbaar testen even buiten beschouwing gelaten

[Verwijderd]

curry684 schreef op zaterdag 19 november 2005 @ 00:58:
[...]

Ja dat zei oisyn ook al, maar ik had de rans-rans methodes voor gangbaar testen even buiten beschouwing gelaten

if (maakt gebruikt van named mutex)
maak 100 kopien van de executable en laat een hex-editor los op de executable en verander de mutexnaam. (sysinternal process explorer)