* Thu Jul 21 21:25:55 JST 2016 Naoyuki Sawa
- 仭傾僾儕働乕僔儑儞偑丄Windows偺帺摦僗働乕儕儞僌偵塭嬁偝傟側偄傛偆偵偡傞偵偼丄儅僯僼僃僗僩僼傽僀儖偱'<dpiAware>true</dpiAware>'偡傟偽椙偄偺偱偡偑丄偦偆偟偰偄傞偵傕娭傢傜偢塭嬁傪庴偗傞帠偑桳傝傑偡丅
  劆偦傟偼丄儊僀儞儌僯僞偲僒僽儌僯僞偺僗働乕儕儞僌偑堎側傞応崌偱偡丅
  仩儊僀儞儌僯僞偲僒僽儌僯僞偺僗働乕儕儞僌偑堎側傞応崌丄僒僽儌僯僞忋偵懚嵼偡傞僂僀儞僪僂偵懳偡傞憖嶌(Win32偺EnumDisplayMonitors(),GetWindowPlacement(),MoveWindow()丄DxLib偺GetWindowPosition()摍)偑丄僗働乕儕儞僌偺塭嬁傪庴偗傑偡丅
  劆椺偊偽丄儊僀儞儌僯僞偑2880x1620偱200%偱丄僒僽儌僯僞偑1920x1080偱150%偺応崌丄EnumDisplayMonitors()偼僒僽儌僯僞偺嬮宍傪丄埵抲=(3840,0),僒僀僘=(2560,1440)偲曉偟傑偡丅
  劆偙傟傜偺悢抣偑偳偙偐傜棃偰偄傞偐悇應偡傞偲丄
  劆丂2880 * 200% / 150% = 3840 劍 僒僽儌僯僞偼儊僀儞儌僯僞偑(200/150)攞偺僒僀僘偵尒偊偰偄傞丅
  劆丂   0 * 200% / 150% =    0 劊
  劆丂1920 * 200% / 150% = 2560 劍 僒僽儌僯僞偼帺暘偺僒僀僘偑(200/150)攞偺僒僀僘偵尒偊偰偄傞丅
  劆丂1080 * 200% / 150% = 1440 劊
  劆僒僽儌僯僞偐傜尒傞偲丄慡懱偑(儊僀儞儌僯僞偺僗働乕儕儞僌亐僒僽儌僯僞偺僗働乕儕儞僌)攞偵尒偊偰偄傞偺偩偲巚偄傑偡丅
  劆僒僽儌僯僞偵懳偡傞憖嶌偼(帋偟偨尷傝偱偼)慡偰忋婰偺攞棪偑揔梡偝傟傞偺偱丄傾僾儕働乕僔儑儞偵懳偟偰摟夁偱偁傝丄傾僾儕働乕僔儑儞偑堄幆偟側偔偰傕帺慠偵摦嶌偡傞傛偆偱偡丅
  劆梫偡傞偵丄傾僾儕働乕僔儑儞偐傜尒傞偲丄僒僽儌僯僞偑杮摉偵2560x1440偺儌僯僞偱偁傞傛偆偵尒偊傑偡丅
  仩尨懃揑偵偼忋婰偺捠傝丄傾僾儕働乕僔儑儞偑堄幆偡傞昁梫偼柍偄偺偱偡偑丄摿庩側働乕僗偱栤戣偑惗偠傞働乕僗偑桳傝傑偡丅
  劆偦傟偼丄Tcl/Tk傪暪梡偡傞応崌偱偡丅
  劆傾僾儕働乕僔儑儞偑Tk_Init()傪屇傇偲丄EnumDisplayMonitors()偵懳偟偰偼忋婰偲偍傝僗働乕儕儞僌偝傟偨抣偑婣傞偺偱偡偑丄MoveWindow()偺嫇摦偑曄傢傝丄(3840,0)偑僒僽儌僯僞尨揰偱偼側偔丄杮摉偺(3840,0)偺埵抲傊堏摦偡傞傛偆偱偡丅
  劆椺偊偽丄MoveWindow(hWnd,3840,0,2560,1440,FALSE)偲偡傞偲丄Tcl/Tk傪巊偭偰偄側偗傟偽僒僽儌僯僞尨揰傊堏摦偡傞偺偱偡偑丄Tcl/Tk傪巊偭偰偄傞偲僒僽儌僯僞偺嵍塃敿暘偁偨傝偑僂僀儞僪僂嵍忋偲側傞埵抲傊堏摦偟偰偟傑偄傑偡丅
  劆側偤偙偆側傞偺偐丄傑偩挷嵏弌棃偰偄傑偣傫偑丄嫲傜偔丄Tk_Init()偑Windows偺僗働乕儕儞僌婡擻偵懳偟偰壗傜偐偺柧帵揑側愝掕曄峏傪峴偭偰偄傞偺偩偲巚偄傑偡丅
  劆尨場偑偼偭偒傝偡傞傑偱丄埲壓偺偄偢傟偐偺巄掕懳嶔偱夞旔偟偰壓偝偄丅
  劆丂儊僀儞儌僯僞偲僒僽儌僯僞傪摨偠僗働乕儕儞僌偵偡傞丅(偙傟偑堦斣椙偄曽朄偱偡偑丄寚揰偲偟偰丄巊梡幰偑帺暘偱僨傿僗僾儗僀愝掕傪曄偊傞昁梫偑桳傝傑偡丅)
  劆丂Tcl/Tk傪巊傢側偄丅(儕儕乕僗娐嫬偱Tcl/Tk傪暪梡偟側偗傟偽偄偗側偄働乕僗偼婬側偺偱丄偙傟偱傕椙偄偐傕抦傟傑偣傫丅)
  劆丂儅儖僠儌僯僞傪巊傢側偄丅(嵟屻偺庤抜)

* Thu Aug 11 23:59:25 JST 2016 Naoyuki Sawa
- x64僾儘僌儔儉偱偼丄main偑幚峴偝傟傞慜偵屇傃弌偝傟傞丄儐乕僓乕娭悢偺掕媊曽朄偑丄x86偺応崌偲偼堎側傞帠傪妛傃傑偟偨丅
  埲壓丄嶲徠帒椏偐傜偺堷梡偱偡丅
  劕劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒
  劔乽Microsoft Developer Network - Linker bug? data_seg(".CRT$XIU") not merged into other .CRT segments乿
  劔(https://social.msdn.microsoft.com/Forums/en-US/7737e56f-c813-4c96-a632-5db7a26ef2fc/linker-bug-datasegcrtxiu-not-merged-into-other-crt-segments?forum=vcgeneral)
  劔
  劔仭幙栤劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅
  劔Using the x64 cross-compiler running on x86, linker and cl.exe file version "8.00.50727.42 (RTM.050727-4200)",
  劔the following code that works in x86 with the x86 cl.exe and link fails:
  劔
  劔#pragma data_seg(".CRT$XIU")
  劔static int (*initptr)() = APreCppInitFunction;
  劔#pragma data_seg()
  劔
  劔The problem occurs because cl.exe seems to create the data_seg as a DATA segment type (in x86 it gets generated as CODE),
  劔and link.exe does not merge the .CRT$XIU segment into the correct alphabetized sequence among the other CRT code segments (.CRT$XIA, etc.).
  劔
  劔Here is a sample from the x64 mapping file that results:
  劔  0001:00000b28 00000008H .CRT$XIA   CODE
  劔  0001:00000b28 00000008H .CRT$XIAA  CODE
  劔  0001:00000b28 00000008H .CRT$XIZ   CODE
  劔  ...
  劔  0004:00000000 00000008H .CRT$(XIU) DATA
  劔
  劔In x86 the map is as expected:
  劔  0001:000005a0 00000004H .CRT$XIA   CODE
  劔  0001:000005a4 00000004H .CRT$XIAA  CODE
  劔  0001:000005ac 00000004H .CRT$XIC   CODE
  劔  0001:000005a8 00000004H .CRT$XIU   CODE
  劔  0001:0000059c 00000004H .CRT$XIZ   CODE
  劔
  劔Questions:
  劔- Is this a known issue?
  劔- Is there some cl.exe setting or #pragma setting that would let me ensure the data_seg gets compiled as a CODE segment?
  劔  I tried changing this to a code_seg but the segment then does not appear in the map because it's really a read-only data segment.
  劔  data_seg() has an optional third param that is ignored (according ot the docs), so that does not seem like a possibility.
  劔- Is this fixed in VS2005 SP1? I cannot find a similar issue listed in the hotfixes for that release.
  劔
  劔仭夝寛劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅
  劔Resolved:
  劔It turns out that on x64 the .CRT$XIU segment was being allocated as a short segment by default,
  劔which did not match the long segment settings of the CRT-defined .CRT$XIA and other segments.
  劔This prevented the linker from merging my new segment into the existing ones.
  劔The solution then is to use a #pragma section directive to set the properties of the segment:
  劔
  劔#pragma section(".CRT$XIU", long, read)
  劔#pragma data_seg(".CRT$XIU")
  劘劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒劒
  梫偡傞偵丄x64偱偼丄x86偲堘偭偰丄
  劆#pragma section(".CRT$XIU", long, read)		仼仼仼仼仼仼仼仼仼仼仛仛仛仛仛廳梫仛仛仛仛仛
  劆#pragma data_seg(".CRT$XIU")
  劆static void* p_init_func = init_func;
  劆#pragma data_seg()
  偲偄偆姶偠偱彂偔昁梫偑桳傞偲尵偆帠偱偡丅
  偙偆彂偐側偄偲弶婜壔娭悢偑屇傃弌偝傟側偄帠偲丄偙偆彂偗偽弶婜壔娭悢偑屇傃弌偝傟傞帠傪丄VS2015偺x64僾儘僌儔儉偱(彮偟偩偗偱偼偁傝傑偡偑)妋擣偟傑偟偨丅

* Thu Dec 15 21:02:01 JST 2016 Naoyuki Sawa
- 亀ImageMagick亁偱丄傾儖僼傽晅偒png傪丄傾儖僼傽柍偟png偲丄傾儖僼傽僠儍僱儖偺僌儗乕僗働乕儖png偵暘棧偡傞曽朄:
  (仸傾儖僼傽柍偟png偲丄傾儖僼傽僠儍僱儖偺僌儗乕僗働乕儖png偼丄png埲奜偺宍幃(jpg摍)偱傕峔偄傑偣傫丅)
  仩嶲峫帒椏乽ImageMagick v6 Examples -- Masks乿(http://www.imagemagick.org/Usage/masking/#alpha_off)
  劆 - Alpha Off or "+matte"
  劆   This is just a simple switch on the image, which turns off any effect the transparency has on the image.
  劆   It does not actually delete or destory the alpha channel attached to the image, it just turns off any effect that channel has on the image.
  劆   Similarly no operator will effect the attached alpha channel while it has been turned off.
  劆   For example let's use the 'crescent moon' image (from a CopyOpacity Composition example), and simply turn the image alpha channel off.
  劆   劇劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劉
  劆   劆convert moon.png -alpha off alpha_off.png 劆
  劆   劋劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劊
  劆   Alpha Extract
  劆   The 'Extract' method will simply copy the 'alpha' mask of the image as a gray-scale channel mask.
  劆   劇劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劉
  劆   劆convert moon.png -alpha extract alpha_extract.png 劆
  劆   劋劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劊
- 亀ImageMagick亁偱丄傾儖僼傽柍偟png偲丄傾儖僼傽僠儍僱儖偺僌儗乕僗働乕儖png傪丄傾儖僼傽晅偒png偵崌惉偡傞曽朄:
  (仸傾儖僼傽柍偟png偲丄傾儖僼傽僠儍僱儖偺僌儗乕僗働乕儖png偼丄png埲奜偺宍幃(jpg摍)偱傕峔偄傑偣傫丅)
  仩嶲峫帒椏乽Stack Overflow - How to combine RGB image and 8-bit alpha image into single PNG file with Imagemagick?乿(http://stackoverflow.com/questions/5647840/how-to-combine-rgb-image-and-8-bit-alpha-image-into-single-png-file-with-imagema)
  劆Q. Imagine I have rgb.jpg and alpha.png. How to combine them into rgba.png with Imagemagick?
  劆A. Since you didn't specify, I'll assume a sufficiently new version of ImageMagick being run from the command line. This was tested using ImageMagick 6.6.9-7 on Linux (from Debian).
  劆   If alpha.png is an image from which you want to copy the alpha channel, or it is a greyscale image with no alpha channel, you can use the following:
  劆   劇劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劉
  劆   劆convert rgb.jpg alpha.png -compose copy-opacity -composite rgba.png 劆
  劆   劋劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劊
  劆   Otherwise, you will have to do a bit more processing on alpha.png. For example, this converts alpha.png to greyscale and ignores the alpha channel:
  劆   劇劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劉
  劆   劆convert rgb.jpg ( alpha.png -colorspace gray -alpha off ) -compose copy-opacity -composite rgba.png 劆
  劆   劋劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劊
  劆   Note that you may have to escape the parentheses in the latter command, depending on your command-line environment.
  劆   If necessary, you can also invert the greyscale image before using it as the alpha channel:
  劆   劇劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劉
  劆   劆convert rgb.jpg ( alpha.png -colorspace gray -alpha off -negate ) -compose copy-opacity -composite rgba.png 劆
  劆   劋劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劅劊
