## 7 Discussions  
Before this paper, the Windows registry has been considered as a storage for configurations or meta data. In this section, we discuss features of WR-Store in terms of the general-purpose data store. **Large-scaled storage:** Table 10 shows some limitations of the Windows registry [28]. Registry keys are used for indexing in WR-Store. 255 characters of the key name and 512 depths of keys are enough for making a scalable index. As discussed in Section 3.2, the hash result is represented in hexadecimal. This means that we can create 16\({}^{255}\) combinations for one-level of the registry, and we can make 512 levels of the registry. The size limitation for the value name is 16,383, and accordingly, the maximum length of the key for WR-store is 16,383. Typically, keys are represented in decimal. Thus, we can deal with 10\({}^{16383}\) keys, which is enough to store large-scaled key-value pairs. Even if the size limitation of the value in the Windows registry is stated as an available memory, Microsoft recommends to store values whose sizes are less than 2 MB for efficiency [28]. Typical recent sources to collect key-value data such as social networking services and search engines deal with data whose sizes are much less than 2 MB. For example, Twitter allows 280 bytes (i.e., less than 1 KB) for a Tweet; Facebook allows 63,206 bytes (i.e., about 61 KB) for a post; Google crawls 500 KB of a Web page as the maximum size ([[https://developers.google.com/search/reference/robots_txt](https://developers.google.com/search/reference/robots_txt)]([https://developers.google.com/search/reference/robots_txt](https://developers.google.com/search/reference/robots_txt))). Furthermore, we can store large-scale of values by working with the file system. That is, we store a large-scaled value as a file in the file system and maintain only a path for the file in the Windows registry. **Migration:** We can easily migrate the data stored in WR-Store into another machines only if the Windows operating system is running on the target system because all the Windows versions support the Windows registry. We can easily export data stored in one WR-Store and import them \begin{table}
\begin{tabular}{c c} \hline \hline
**Registry Element** & **Size Limitation** \\ \hline Key name & 255 characters \\ Depth of the registry keys & 512 \\ Name attribution in the value & 16,383 characters \\ Data attribute in the value & Available memory \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Limitations of the Windows registry [28]. into another WR-Store in the other machine by using a Windows built-in command (For exporting data stored in \"HKCU\DBName\", the following Windows built-in command can be used: \"regedit/E export.reg 'HKCU\DBName\"', which stores the exported data into export.reg. For importing data, the following command can be used: \"regedit/S export.reg\", which imports the exported data into the other systems.). In addition, for the other environments that do not support registry, we can migrate the data in WR-Store into any other environments that support existing key-value stores by using the ETL (Extract-Transform-Load) method proposed in Section 5. **Portability:** WR-Store can be used in every Windows version (e.g., Windows 7/8/8.1/10 and Windows server 2008/2012/2016) because the Windows registry and associated APIs can be worked in any versions of Windows. The executable file compiled by one environment can be worked on other Windows environments without any modifications. **Stable operations:** The Windows registry is always accessed from the Windows applications. Especially, the system processes such as explorer.exe and services.exe are always working even if the users do not execute any applications at all. They use the built-in APIs provided by Windows to access to the Windows registry, which has been shown in Table 1. WR-Store is also developed based on the same APIs.