Microsoft geeft lijst ongedocumenteerde functies vrij

Om de Amerikaanse staten tegemoet te komen heeft Microsoft een lijst van 272 - tot nu toe ongedocumenteerde - API calls openbaar gemaakt op haar MSDN website. Een programmeur kan gebruik maken van dit soort API calls om de functionaliteit van het besturingssysteem aan te roepen. Het bleek echter dat niet al deze functies waren gedocumenteerd, waardoor concurrenten vreesden dat Microsoft 'verborgen' functies gebruikte om haar eigen software beter liet werken dan die van hun. Als deel van de schikking werd dus afgesproken dat alles boven water moest komen. Eerder maakte het bedrijf om dezelfde reden de gegevens van 113 communicatie-protocollen bekend. Binnen enkele weken volgt bovendien een SDK, die programmeurs kunnen gebruiken om software te schrijven die de tot nu toe onbekende functies aanroept:

"The release of the API information along with the SDK will allow software developers to tap into the full functionality of Windows Media," Jupiter Research analyst Michael Gartenberg said. "This type of broad support leads to the creation of ad hoc communities to provide features and functions not in Media Player natively and therefore helps build adoption rates" for third-party programs.

[...] "The value this is going to have on the industry is going to be difficult to determine over the short term," Gillen said. "But you may look back five years from now and say, 'Microsoft released 270 or so APIs and 269 weren't that meaningful, but this one was picked up by this software company that leveraged it and became a superstar.' It's hard to predict what's really going to happen."

Lees meer informatie op C|Net News.com.

Reacties (48)

[TaXaN]

Zie ook http://www.theregister.co.uk/content/4/26803.html

[Erhnam]

Ik hoop dat het de opensource tengoede komt. Misschien dat het WINE project iets met deze lijst kan.

Zoiezo worden bestaande programma's beter en stabieler omdat die nu meer inzicht hebben op de Windows API's

[freggy]

Het wine project is hier juist niks mee, al deze functies hadden zij al lang reverse engineered. De echte functies waarmee het Wineproject iets zou kunnen doen, zijn nog altijd duister... Dit is de zoveelste zet van Microsoft om een schijn te geven dat ze hun de concurrentie meer kansen willen geven.
Lees bijvoorbeeld de reactie van een wine developer op http://www.winehq.com/hypermail/wine-devel/2002/08/0364.html
Ook dit is interessant:
http://www.theregister.co.uk/content/4/26803.html

[Maestro.mosjuh]

ehhh....... veel weet ik niet van wine;
dat laat toch spellen die voor windows geschreven zijn werken op unix?
maar als spelletjes programmeurs eerst de api-functies niet kenden, konden ze die ook niet gebruiken; nu kennen ze ze wel dus moeten de programmeurs van wine deze ook implementeren; dus meer werk.
dus ze kunnen er wel wat mee maar of ze het ook leuk vinden...

[Verwijderd]

Je hebt ongeveer gelijk. Wine is voor gewone programma's. WineX is voor spelletjes (ik denk dat daar dan iets DirectX-achtigs inzit.

Het zou Wine wel enigszins kunnen helpen. De software die Microsoft schrijft kan die functies wel gebruiken. Dat was tot nu toe voor Wine lastig. Nu is er kans dat Wine de software van Microsoft beter ondersteunt. Sommige delen van Office waren altijd nog een probleem.

Het is trouwens sowieso maar de vraag of Wine dit kan gebruiken. Misschien moet je wel eerst bepaalde voorwaarden accepteren voordat je hier een blik op mag werpen.

[raptorix]

Kan iemand mij dit vertellen? Je hebt toch software die API calls monitort met functie naam en parameters?

Als deze funcites al gebruikt werden doro MS dan zou dat toch bekent moeten zijn?

[Verwijderd]

Ik denk ook dat dat de manier is waarop men achter het bestaan van de api's gekomen is. Welicht via het WINE en WINEX project

Maar het gaat dus om het opzettelijk achterhouden van informatie over de werking van het OS door Microsoft met als enige plausibele bedoeling concurrentievervalsing.

[Koffie]

* 786562 Koffie
Waar in welk land ter wereld bestaat er een wet die zegt dat als je een programma/OS/applicatie/whatever schrijft dat je dan publiekelijk alles ins en outs moet vrijgeven

Ze hebben een OS geschreven, mooi
Ze hebben er een aantal functies ingevrod, mooi
Ze hebben een aantal functies zelfs vrijgegegeven en gedocumenteerd, mooi
Ze geven nu nog meer functies vrij, mooi
Ze houden een aantal functies interne (om welke reden dan ook), is hun eigen goedrecht.

[Verwijderd]

Waar in welk land ter wereld bestaat er een wet die zegt dat als je een programma/OS/applicatie/whatever schrijft dat je dan publiekelijk alles ins en outs moet vrijgeven

Overal natuurlijk. Indien api calls achterhouden tenminste - zoals dat hier het geval is - concurrentievervalsing impliceert

[Verwijderd]

klopt, maarrr: sommige api's vragenop of vullenin akelige grote structures. je ziet (monitort) dus als argument wel een mooie pointer naar een geheugenlocatie, maar je moet nog steeds flink prutsen om er een beetje wijs uit te worden. en nog lastiger is het als de api enkel geexport wordt vanuit z'n module aan de hand van z'n ordinal... dan heb je dus ook geen cryptische naam meer waar je op af kan gaan.

[Beaker]

Ben zelf programmeur en ben dus vol interesse ff op de msdn site gaan kijken, maar de vrijgegeven functies/methoden zijn nou niet echt spectaculair.
Oke, er zit er hier en daar een tussen die wel eens van pas kunnen komen, maar om nou te spreken van het vrijgeven van grote geheimen, niet echt.

[Speed24]

Nou ja, er zitten hele nuttige tussen:
PathIsExe

Determines whether a file is an executable by examining the file extension.

Return Value
Returns TRUE if the file extension is .cmd, .bat, .pif, .scf, .exe, .com, or .scr. Returns FALSE otherwise.

Hier kun je misschien wel leuke dingen mee doen:
WM_APPCOMMAND Notification

The WM_APPCOMMAND message notifies a window that the user generated an application command event, for example, by clicking an application command button using the mouse or typing an application command key on the keyboard.

[PuzzleSolver]

Ik keek er ook net ff door en kwam deze tegen.

Windows Functions

DeregisterShellHookWindow
EndTask
FindWindow
FindWindowEx
InternalGetWindowText
IsHungAppWindow
RegisterShellHookWindow
SwitchToThisWindow

Ehhh. FindWindow en FindWindowEx zijn toch al wat langer bekend, mischien moeten we er nu 270 onbekende API's van maken? Maar goed ook in dit lijstje staan al weer een paar leuke en redlijk interresante calls.

[JohanDM]

Niet alle API calls die MS nu vrijgeeft zijn compleet nieuw of onbekend te noemen. Een groot aantal wel, maar hier zit ook een serieus aantal al bekende API's bij waarvoor ze de documentatie enkel vervolledigd hebben. Dit is ook het geval bij de FindWindow API die je noemde, zo kun je nu daar als extraatje lezen dat je daarmee MS InteliType kan dedecteren. Het is dus niet allemaal nieuw, maar wel vollediger.

[Ick]

Deze is ook wel erg leuk: PathYetAnotherMakeUniqueName()

[strompf]

Weet iemand misschien voorbeelden van liflalfjes die M$ wel kan programmeren, maar derden niet, omdat M$ toegang zou hebben tot deze en/of andere ongepubliceerde functionaliteiten?

Ik bedoel niet zozeer systeemtechnische zaken zoals SMB vs. Samba, of M$ SQL Server & Apple Quicktime die (althans lang geleden, op NT) een deel van het OS kon omzeilen, maar functionaliteiten op applicatie-niveau.

De laatste jaren had ik bv. steeds meer 't idee, dat je zwevende menubalken alleen maar in M$-based applicaties hebt, zoals VB programma's.

???

[Verwijderd]

Zwevende menubalken (docking menus heet dat officieel) kun je met Visual Studio 6 gewoon maken hoor... En als IK al een applicatie met docking menus kan maken, dan kan Adobe/Macromedia/etc dat ook echt wel hoor

[servies]

Het gaat erom dat Microsoft ervan wordt verdacht bepaalde API's voor zichzelf te houden die bijvoorbeeld een performancewinst kunnen opleveren wat hen een voordeel kan opleveren bij een applicatie. Stel bijvoorbeeld dat er een API call is die er voor zorgt dat een willekeurig bestand in 2 seconden wordt opgeslagen op de harde schijf. En er bestaat nog een API call die hetzelfde doet in 10 seconden. Je maakt de 2e bekend aan de buitenwereld maar zelf maak je gebruik van de 1e, dan levert dat jou een concurrentievoordeel op, jouw applicatie is immers een stuk sneller dan die van de concurrenten.

[johanvdw]

Hmm. Zou dit betekenen dat er nu een virusgolf zal komen met foutjes in die verborgen api's, totdat de meeste fouten hersteld zijn?

Dat gebeurt wel eens bij closed-source projects die open source worden, dan komen er ineens veel beveiliginsupdates.
OK, ik weet het, die API's worden niet open-source, maar in elk geval opener dan ze nu al waren.

(reactie op darthdrinker)
Extra API's zijn extra functies, zijn dus functies die de tands des tijds op virusgebied nog niet hebben kunnen weerstaan. Door het feit dat ze niet gedocumenteerd waren zijn ze ook minder gecontroleerd op mogelijke virussen. Want 'virusschrijvers weten toch niet hoe ze die dingen moeten gebruiken'. Cfr security through obscurity.

[darthdrinker]

Dit zijn methods die eerst niet en nu wel ter beschikking staan van de programmeur.
Er worden niet hele API's openbaar gemaakt, de API was er al.
Er waren echter nog enkele functies binnen die API niet gedocumenteerd, dat is nu wel het geval.
Ik heb sterke twijfels of dit tot meer virussen zal gaan leiden...
De API worden idd verre van open source, het enige wat microsoft doet is als het ware vertellen wat een functie binnen de API doet en hoe je het kunt gebruiken. Er wordt dus GEEN source vrijgegeven.
Ik denk dus, nogmaals, niet dat hier meer virussen van zullen komen.

[PipoDeClown]

De meeste zijn aliassen van bekende routines, van de overige zijn er reverse engineered en programmeurs hebben al hun eigen _betere_ oplossingen gebakken of worden gewoon nooit gebruikt.

[Verwijderd]

Jep, als het echt zo'n ontzettend spectaculaire functies waren geweest had MS ze ook niet zo gemakkelijk vrijgegeven, denk je wel? Gewoon een makkelijk gescoord punt voor MS.

[boner]

pff. wat dom.
MS-DOS is zo instabiel geworden mede omdat alle hidden api-call, toen nog dos-calls genoemd, werden gebruikt. Als nu MS niet meer weet wie welke API gebruikt moeten ze er tot het einde der tijden in aanwezig moeten blijven. Lees het OS wordt er alleenm maar groter en trager door. Als ze alleen zelf ervan gebuik maken, hebben ze ook de controle en de macht om de api-s te killen.

Hetzelgde geldt en goldt overigens niet alleen voor MS maar ook voor veel processoren. Ik heb zelf op mijn 6510 van die CBM64 nog ergens een lijst van hidden opcodes liggen.

[justice strike]

heel simpel men wil apis killen?? gewoon een nieuw os op de markt brengen. Dat windows 2000 compatible was met win95 was maar in een paar gevallen zo. een nieuw os betekent natuurlijk geen 100 % garantie voor compatibiliteit. overigens was windows nt helemaal niet compatible met win95 (of in beperkte mate)

het is dus gewoon mogelijk om api's te killen, daar hoef je niet de api's voor te verbergen. (api's killen doe je toch alleen maar bji een nieuwe versie van een type os)

[4AMD]

Die rechtzaken hebben zin; nu is het hek van de dam!

Het blijkt dus dat het wel degelijk 'helpt' om MS voor de rechter te slepen; het zijn misschien welliswaar kleine dingen, maar het helpt wel. Ik wens de EU veel succes in hun rechtzaak met Bill.

[Verwijderd]

Volgens mij is het ook zo dat ze alle API calls hebben vrijgegeven, op één na (API met beveiligingsfuncties). Tenminste, dat stond in Automatisering Gids, dusseh... correct hun if zij are wrong