{"id":2313,"date":"2013-12-20T07:00:00","date_gmt":"2013-12-20T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2013\/12\/20\/wouldnt-the-recycle-bin-sample-program-have-been-simpler-without-com\/"},"modified":"2013-12-20T07:00:00","modified_gmt":"2013-12-20T07:00:00","slug":"wouldnt-the-recycle-bin-sample-program-have-been-simpler-without-com","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20131220-00\/?p=2313","title":{"rendered":"Wouldn't the Recycle Bin sample program have been simpler without COM?"},"content":{"rendered":"

\nSteve Wolf suggests that\n\nthe sample program would have been much simpler had the shell\nextension model been a flat Win32 interface<\/a>.\n<\/p>\n

\nOkay, let’s try it.\n<\/p>\n

\nSince this is an extension model, each extension needs to specify\nthe callbacks for each namespace operation.\nPerhaps it could have been done like this:\n<\/p>\n

\nHRESULT (CALLBACK *SHELLFOLDER_EXTENDHANDLER)(\n    void *lpContext,\n    OBJECTTYPE type, void **phObject);\nHRESULT (CALLBACK *SHELLFOLDER_PARSEDISPLAYNAMEHANDLER)(\n    void *lpContext,\n    HWND hwnd, LPBINDCTX pbc, LPWSTR pszDisplayName,\n    ULONG *pchEaten, PIDLIST_RELATIVE *ppidl, ULONG *pdwAttributes);\nHRESULT (CALLBACK *SHELLFOLDER_ENUMOBJECTSHANDLER)(\n    void *lpContext,\n    HWND hwnd, SHCONTF grfFlags, HENUMIDLIST *pheidl);\nHRESULT (CALLBACK *SHELLFOLDER_BINDTOOBJECTHANDLER)(\n    void *lpContext,\n    PCUIDLIST_RELATIVE pidl, LPBINDCTX pbc,\n    OBJECTTYPE type, void **phObject);\nHRESULT (CALLBACK *SHELLFOLDER_BINDTOSTRAGEHANDLER)(\n    void *lpContext,\n    PCUIDLIST_RELATIVE pidl, LPBINDCTX pbc,\n    OBJECTTYPE type, void **phObject);\nHRESULT (CALLBACK *SHELLFOLDER_COMPAREIDSHANDLER)(\n    void *lpContext,\n    LPARAM lParam, PCUIDLIST_RELATIVE pidl1,\n    PCUIDLIST_RELATIVE pidl2);\n... (etc) ...\nHFOLDER CreateShellFolderImplementation(\n    SHELLFOLDER_EXTENDHANDLER pfnExtend,\n    SHELLFOLDER_PARSEDISPLAYNAMEHANDLER pfnParseDisplayName,\n    SHELLFOLDER_ENUMOBJECTSHANDLER pfnEnumObjects,\n    SHELLFOLDER_BINDTOOBJECTHANDLER pfnBindToObject,\n    SHELLFOLDER_BINDTOSTRAGEHANDLER pfnBindToStorage,\n    SHELLFOLDER_COMPAREIDSHANDLER pfnCompareIDs,\n    ... (etc) ...\n    void *lpContext);\n<\/pre>\n
\nThis would be the function that allows a third party to create a\nshell folder implementation.\nYou pass it a bunch of flat callback functions, one for each\noperation that a shell folder supports,\nso that when the application tries to perform that operation on your\ncustom folder, the operating system can ask your custom implementation\nto do that thing.\n<\/p>\n
\nIf additional shell folder operations are added in the future,\nthe operating system needs to know how to ask your shell extension\nwhether it knows how to do  those extended things.\nThat’s what the Extend<\/code> method is for.\nThe operating system could ask to extend your object to one\nthat supports HFOLDER2<\/code> operations.\n<\/p>\n
\nActually, if you look at it, these are exactly the same as\nCOM methods.\nThe first parameter says what object you are operating on\n(“this<\/code>“),\nand the rest are the parameters.\n<\/p>\n
\nOkay, so I’m setting up a straw man that looks just like COM.\nSo let’s do something that looks very different from COM.\nWe could use the window procedure paradigm:\n<\/p>\n
\nHRESULT (CALLBACK *SHELLFOLDER_INVOKE)(\n    void *lpContext,\n    FOLDERCOMMAND cmd, void *parameters);\nHFOLDER CreateShellFolderImplementation(\n    SHELLFOLDER_INVOKE pfnInvoke,\n    void *lpContext);\n<\/pre>\n
\nYour invoke function receives a FOLDER­COMMAND<\/code>\nenumeration which specifies what command the client is trying to\nperform,\nand then switches on the command to perform the command,\nor returns E_NOT­IMPL<\/code> if you don’t handle the command.\nSince each of the methods takes different parameters,\nwe have to do some work to pack them up into a generic parameter\nblock, and then unpack it on the receiving end.\nLet’s assume some helper functions that do this packing and unpacking.\n<\/p>\n
\nHRESULT UnpackParseDisplayName(\n    void *parameters,\n    HWND *phwnd,\n    LPBINDCTX *ppbc,\n    LPWSTR *ppszDisplayName,\n    ULONG **ppchEaten,\n    PIDLIST_RELATIVE **ppidl,\n    ULONG **ppdwAttributes);\n);\nHRESULT UnpackEnumObjects(\n    void *parameters,\n    HWND *phwnd,\n    SHCONTF *pgrfFlags,\n    HENUMIDLIST **ppheidl);\nHRESULT AwesomeShellFolderInvoke(\n    void *lpContext,\n    FOLDERCOMMAND cmd,\n    void *parameters)\n{\n  HRESULT hr = E_NOTIMPL;\n  CAwesome *self = reinterpret_cast<CAwesome*>(lpContext);\n  switch (cmd) {\n  case FOLDERCOMMAND_PARSEDISPLAYNAME:\n    {\n      HWND hwnd;\n      LPBINDCTX pbc;\n      LPWSTR pszDisplayName;\n      ULONG *ppchEaten;\n      PIDLIST_RELATIVE *pidl;\n      ULONG *pdwAttributes;\n      hr = UnpackParseDisplayName(parameters, &hwnd, &pbc,\n              &pszDisplayName, &ppchEaten, &pidl,\n              &pdwAttributes);\n      if (SUCCEEDED(hr)) {\n        hr = ... do the actual work ...\n      }\n    }\n    break;\n  case FOLDERCOMMAND_ENUMOBJECTS:\n    {\n      HWND hwnd;\n      SHCONTF grfFlags;\n      HENUMIDLIST *pheidl;\n      hr = UnpackEnumObjects(parameters, &hwnd, &grfFlags,\n              &pheidl);\n      if (SUCCEEDED(hr)) {\n        hr = ... do the actual work ...\n      }\n    }\n    break;\n    ... (etc) ...\n  }\n  return hr;\n}\n<\/pre>\n
\nThis could be made a lot simpler with the addition of some helper\nfunctions.\n<\/p>\n
\nHRESULT DispatchParseDisplayName(\n  HRESULT (CALLBACK *)(\n    void *lpContext,\n    HWND hwnd, LPBINDCTX pbc, LPWSTR pszDisplayName,\n    ULONG *pchEaten, PIDLIST_RELATIVE *ppidl, ULONG *pdwAttributes),\n  void *lpContext,\n  void *parameters);\nHRSEULT DispatchEnumObjects(\n  HRESULT (CALLBACK *)(\n    void *lpContext,\n    HWND hwnd, SHCONTF grfFlags, HENUMIDLIST *pheidl),\n  void *lpContext,\n  void *parameters);\n<\/pre>\n
\nThe implementation would then go like this:\n<\/p>\n
\nHRESULT AwesomeParseDisplayName(\n    void *lpContext,\n    HWND hwnd, LPBINDCTX pbc, LPWSTR pszDisplayName,\n    ULONG *pchEaten, PIDLIST_RELATIVE *ppidl, ULONG *pdwAttributes)\n{\n  CAwesome *self = reinterpret_cast<CAwesome*>(lpContext);\n  HRESULT hr;\n  ... do the actual work ...\n  return hr;\n}\nHRESULT AwesomeEnumObjects(\n    void *lpContext,\n    HWND hwnd, SHCONTF grfFlags, HENUMIDLIST *pheidl),\n{\n  CAwesome *self = reinterpret_cast<CAwesome*>(lpContext);\n  HRESULT hr;\n  ... do the actual work ...\n  return hr;\n}\nHRESULT AwesomeShellFolderInvoke(\n    void *lpContext,\n    FOLDERCOMMAND cmd,\n    void *parameters)\n{\n  switch (cmd) {\n  case FOLDERCOMMAND_PARSEDISPLAYNAME:\n    return DispatchParseDisplayName(AwesomeParseDisplayName,\n              lpContext, parameters);\n  case FOLDERCOMMAND_ENUMOBJECTS:\n    return DispatchEnumObjects(AwesomeEnumObjects,\n              lpContext, parameters);\n    ... (etc) ...\n  }\n  return E_NOTIMPL;\n}\n<\/pre>\n
\nYou might decide to make the parameter packing transparent\ninstead of opaque, so that they are passed as, say,\nan array of generic types like VARIANT<\/code>s.\n(Note that I’m abusing VARIANT<\/code>s here.\nThese are not valid VARIANT<\/code>s,\nbut it saves me from having to declare my own generic type.\nThis is just a design discussion, not an actual implementation.)\n<\/p>\n
\nHRESULT (CALLBACK *SHELLFOLDER_INVOKE)(\n    void *lpContext,\n    FOLDERCOMMAND cmd,\n    VARIANT *rgvarArgs,\n    UINT cArgs);\n\/\/ error checking elided for expository purposes\n\/\/ In real life, you would have to validate cArgs\n\/\/ and the variant types.\nHRESULT AwesomeShellFolderInvoke(\n    void *lpContext,\n    FOLDERCOMMAND cmd,\n    VARIANT *rgvarArgs,\n    UINT cArgs)\n{\n  CAwesome *self = reinterpret_cast<CAwesome*>(lpContext);\n  switch (cmd) {\n  case FOLDERCOMMAND_PARSEDISPLAYNAME:\n    return self->ParseDisplayName(\n      reinterpret_cast<HWND>(rgvarArgs[0]->byref),\n      reinterpret_cast<LPBINDCTX>(rgvarArgs[1]->byref),\n      reinterpret_cast<LPWSTR>(rgvarArgs[2]->byref),\n      reinterpret_cast<ULONG*>(rgvarArgs[3]->byref),\n      reinterpret_cast<PIDLIST_RELATIVE*>(rgvarArgs[4]->byref),\n      reinterpret_cast<ULONG**>(rgvarArgs[5]->byref));\n  case FOLDERCOMMAND_ENUMOBJECTS:\n    return self->EnumObjects(\n      reinterpret_cast<HWND>(rgvarArgs[0]->byref),\n      reinterpret_cast<SHCONTF>(rgvarArgs[1]->lVal),\n      reinterpret_cast<HENUMIDLIST *>(rgvarArgs[2]->byref));\n    ... (etc) ...\n  }\n  return E_NOTIMPL;\n}\n<\/pre>\n
\n(This is basically the plug-in model that\n\nsome people have chosen to pursue<\/a>.\nIt is also basically the same as\nIDispatch::Invoke<\/code>.)\n<\/p>\n
\nOkay, that’s how you implement the plug-in.\nNow how do you call it?\n<\/p>\n
\nYou would have to pack the parameters, then call through the\nInvoke<\/code> method with your command ID.\nFor example, a call to\nFOLDER­COMMAND_ENUM­OBJECTS<\/code>\nwould go like this:\n<\/p>\n
\n\/\/ was: hr = psf->EnumObjects(hwnd, shcontf, &peidl);\n\/\/ now:\nHENUMIDLIST heidl;\nVARIANT args[3];\nargs[0].vt = VT_BYREF;\nargs[0].byref = hwnd;\nargs[1].vt = VT_I4;\nargs[1].lVal = shcontf;\nargs[2].vt = VT_BYREF;\nargs[2].byref = &heidl;\nhr = InvokeShellFolder(hsf, FOLDERCOMMAND_ENUMOBJECTS, args, 3);\n<\/pre>\n
\nYuck.\n<\/p>\n
\nLet’s assume that the shell provides helper functions that do all\nthis parameter packing for you.\n(This is\n\nmore than certain plug-in models give you<\/a>.)\n<\/p>\n
\nHRESULT ShellFolder_ParseDisplayName(\n    HSHELLFOLDER hsf,\n    HWND hwnd, LPBINDCTX pbc, LPWSTR pszDisplayName,\n    ULONG *pchEaten, PIDLIST_RELATIVE *ppidl, ULONG *pdwAttributes)\n{\n  VARIANT args[6];\n  args[0].vt = VT_BYREF;\n  args[0].byref = hwnd;\n  args[1].vt = VT_BYREF;\n  args[1].byref = pbc;\n  args[2].vt = VT_BYREF;\n  args[2].byref = pszDisplayName;\n  args[3].vt = VT_BYREF;\n  args[3].byref = pchEaten;\n  args[4].vt = VT_BYREF;\n  args[4].byref = ppidl;\n  args[5].vt = VT_BYREF;\n  args[5].byref = pdwAttributes;\n  return InvokeShellFolder(hsf, FOLDERCOMMAND_PARSEDISPLAYNAME,\n                           args, 6);\n}\nHRESULT ShellFolder_EnumObjects(\n    HSHELLFOLDER hsf,\n    HWND hwnd, SHCONTF grfFlags, HENUMIDLIST *pheidl)\n{\n  VARIANT args[3];\n  args[0].vt = VT_BYREF;\n  args[0].byref = hwnd;\n  args[1].vt = VT_I4;\n  args[1].lVal = shcontf;\n  args[2].vt = VT_BYREF;\n  args[2].byref = &heidl;\n  return InvokeShellFolder(hsf, FOLDERCOMMAND_ENUMOBJECTS, args, 3);\n}\n... (etc) ...\n<\/pre>\n
\nThe naming convention above is kind of awkward, so let’s give them\na bit less clumsy names.\n<\/p>\n
\nHRESULT ParseShellFolderDisplayName(\n    HSHELLFOLDER hsf,\n    HWND hwnd, LPBINDCTX pbc, LPWSTR pszDisplayName,\n    ULONG *pchEaten, PIDLIST_RELATIVE *ppidl, ULONG *pdwAttributes);\nHRESULT EnumShellFolderObjects(\n    HSHELLFOLDER hsf,\n    HWND hwnd, SHCONTF grfFlags, HENUMIDLIST *pheidl);\n... (etc) ...\n<\/pre>\n
\nOkay, now that we have a flat API,\nlet’s convert\n\nthe original code<\/a>.\nThe first function now goes like this:\n<\/p>\n
\nHRESULT BindToCsidl(int csidl,\n    \/\/ REFIID riid, void **ppv<\/strike><\/font>\n    HSHELLFOLDER<\/font> *phsf)\n{\n HRESULT hr;\n PIDLIST_ABSOLUTE pidl;\n hr = SHGetSpecialFolderLocation(NULL, csidl, &pidl);\n if (SUCCEEDED(hr)) {\n  \/\/ IShellFolder *psfDesktop;<\/strike><\/font>\n  HSHELLFOLDER hsfDesktop;<\/font>\n  hr = SHGetDesktopFolder(&hsfDesktop);\n  if (SUCCEEDED(hr)) {\n   if (pidl->mkid.cb) {\n    \/\/ hr = psfDesktop->BindToObject(<\/strike><\/font>pidl, NULL, riid, ppv<\/strike><\/font>);\n    hr = BindToShellFolderObject(hsfDesktop,<\/font> pidl, NULL, phsf<\/font>);\n   } else {\n    \/\/ hr = psfDesktop->QueryInterface(riid, ppv);<\/strike><\/font>\n    *phsf = hsfDesktop;\n    hsfDesktop = nullptr; \/\/ transfer to owner\n    hr = S_OK;<\/font>\n   }\n   \/\/ psfDesktop->Release();<\/strike><\/font>\n   if (hsfDesktop) ShellFolder_Destroy(hsfDesktop);<\/font>\n  }\n  CoTaskMemFree(pidl);\n }\n return hr;\n}\n<\/pre>\n
\nWhat happened here?\nThe IShell­Folder<\/code>\ninterface was replaced by a\nHSHELL­FOLDER<\/code> flat handle.\nFlat APIs use handles to refer to objects instead of interface pointers.\n<\/p>\n
\nA method call on an interface pointer becomes a flat API call.\nIn general,\npInterface->VerbNoun(args)<\/code> gets flattened to\nVerbInterfaceNoun(h, args)<\/code>.\nBut that’s just renaming and doesn’t change the underlying complexity\nof the issue.\n<\/p>\n
\nI could’ve added reference counting to these flat objects,\nbut then I would be accused of intentionally making it look like COM,\nso let’s say that these flat objects are not reference-counted.\nTherefore, we have to be more careful about not destroying the object\nwe plan on returning.\n<\/p>\n
\nOn to the next two functions:\n<\/p>\n
\nvoid PrintDisplayName(\n    \/\/ IShellFolder *psf,<\/strike><\/font>\n    HSHELLFOLDER hsf<\/font>,\n    PCUITEMID_CHILD pidl, SHGDNF uFlags, PCTSTR pszLabel)\n{\n STRRET<\/a> sr;\n \/\/ HRESULT hr = psf->GetDisplayNameOf(<\/strike><\/font>pidl, uFlags, &sr);\n HRESULT hr = GetShellFolderDisplayNameOf(hsf,<\/font> pidl, uFlags, &sr);\n if (SUCCEEDED(hr)) {\n  PTSTR pszName;\n  hr = StrRetToStr(&sr, pidl, &pszName);\n  if (SUCCEEDED(hr)) {\n   _tprintf(TEXT(\"%s = %s\\n\"), pszLabel, pszName);\n   CoTaskMemFree(pszName);\n  }\n }\n}\nvoid PrintDetail(\n    \/\/ IShellFolder2 *psf,<\/strike><\/font>\n    HSHELLFOLDER hsf<\/font>,\n    PCUITEMID_CHILD pidl,\n    const SHCOLUMNID *pscid, PCTSTR pszLabel)\n{\n VARIANT vt;\n \/\/ HRESULT hr = psf->GetDetailsEx(<\/strike><\/font>pidl, pscid, &vt);\n HRESULT hr = GetShellFolderDetailsEx(hsf,<\/font> pidl, pscid, &vt);\n if (SUCCEEDED(hr)) {\n  hr = VariantChangeType(&vt, &vt, 0, VT_BSTR);\n  if (SUCCEEDED(hr)) {\n   _tprintf(TEXT(\"%s: %ws\\n\"), pszLabel, V_BSTR(&vt));\n  }\n  VariantClear(&vt);\n }\n}\n<\/pre>\n
\nNot really all that different.\nLast function:\n<\/p>\n
\nint __cdecl _tmain(int argc, PTSTR *argv)\n{\n HRESULT hr = CoInitialize(NULL);\n if (SUCCEEDED(hr)) {\n  \/\/ IShellFolder2 *psfRecycleBin;<\/strike><\/font>\n  HSHELLFOLDER hsfRecycleBin;<\/font>\n  hr = BindToCsidl(CSIDL_BITBUCKET, &hsfRecycleBin<\/font>);\n  if (SUCCEEDED(hr)) {\n   \/\/ IEnumIDList *peidl;<\/strike><\/font>\n   HENUMIDLIST heidl;<\/font>\n   \/\/ hr = psfRecycleBin->EnumObjects(<\/strike><\/font>NULL,\n   hr = EnumShellFolderObjects(hsfRecycleBin,<\/font> NULL,\n     SHCONTF_FOLDERS | SHCONTF_NONFOLDERS<\/a>, &heidl);\n   if (hr == S_OK) {\n    PITEMID_CHILD pidlItem;\n    \/\/ while (peidl->Next(<\/strike><\/font>1, &pidlItem, NULL) == S_OK) {\n    while (EnumerateNextShellFolderObject(heidl,<\/font> 1, &pidlItem, NULL) == S_OK) {\n     _tprintf(TEXT(\"------------------\\n\"));\n     PrintDisplayName(hsfRecycleBin<\/font>, pidlItem,\n                      SHGDN_INFOLDER, TEXT(\"InFolder\"));\n     PrintDisplayName(hsfRecycleBin<\/font>, pidlItem,\n                      SHGDN_NORMAL, TEXT(\"Normal\"));\n     PrintDisplayName(hsfRecycleBin<\/font>, pidlItem,\n                      SHGDN_FORPARSING, TEXT(\"ForParsing\"));\n     PrintDetail(hsfRecycleBin<\/font>, pidlItem,\n                 &SCID_OriginalLocation, TEXT(\"Original Location\"));\n     PrintDetail(hsfRecycleBin<\/font>, pidlItem,\n                 &SCID_DateDeleted, TEXT(\"Date deleted\"));\n     PrintDetail(hsfRecycleBin<\/font>, pidlItem,\n                 &PKEY_Size, TEXT(\"Size\"));\n     CoTaskMemFree(pidlItem);\n    }\n   }\n   \/\/ psfRecycleBin->Release();<\/strike><\/font>\n   DestroyShellFolder(hsfRecycleBin);<\/font>\n  }\n  CoUninitialize();\n }\n return 0;\n}\n<\/pre>\n
\nSo we see that flattening the API didn’t really change the code\nat all.\nYou’re still invoking methods on objects.\nWhether you use a flat API to do it or an object-based API\nis just changing the decorations.\nThe underlying logic doesn’t change.\n<\/p>\n
\nOne disadvantage of the flat version is that it requires everything\nto be mediated by the shell.\nInstead of invoking a method directly on the object,\nyou have to call the flat function in the shell,\nwhich then packages up the call and dispatches it,\nand the recipient then needs to unpack the parameters\n(possibly with help from the shell)\nbefore finally getting around to doing the actual work.\n<\/p>\n
\nIt also means that any interface change requires an operating system\nupgrade,\nsince the mediator (the shell) needs to understand the new interface.\n<\/p>\n
\nBut if this whole object-oriented syntax\nreally annoys you and you want a flat API,\nthen feel free to add the line\n<\/p>\n
\n#define CINTERFACE\n<\/pre>\n
\nbefore including COM header files.\nIf you do that, then\nyou get the old flat C-style version of COM.\nInstead of the\np->Method(args)<\/code> new hotness,\nyou can stick to the old trustworthy\np->lpVtbl->Method(p, args)<\/code> version,\nor use the\nInterfaceName_MethodName(p, args)<\/code> helper macro.<\/p>\n","protected":false},"excerpt":{"rendered":"
Steve Wolf suggests that the sample program would have been much simpler had the shell extension model been a flat Win32 interface. Okay, let’s try it. Since this is an extension model, each extension needs to specify the callbacks for each namespace operation. Perhaps it could have been done like this: HRESULT (CALLBACK *SHELLFOLDER_EXTENDHANDLER)( void […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-2313","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
Steve Wolf suggests that the sample program would have been much simpler had the shell extension model been a flat Win32 interface. Okay, let’s try it. Since this is an extension model, each extension needs to specify the callbacks for each namespace operation. Perhaps it could have been done like this: HRESULT (CALLBACK *SHELLFOLDER_EXTENDHANDLER)( void […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/2313","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=2313"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/2313\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=2313"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=2313"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=2313"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}