📌MacType needs your help

[sammilucia]

The MacType rendering engine is a long-term, mature project that has come a long way since it first began in 2012.

There is still a lot of work to do, however, especially in making MacType more accessible to the average user, and improving the apps surrounding MacType (for example, rewriting MacType Tuner and MacType Wizard to make them more modern and maintainable).

If you're an developer, translator, or tester, and you are interested – or know someone who might be interested – simply reply here, or message us directly at @snowie2000 or @sammilucia and let us know. We'd love to hear from you 😊.

[wmjordan]

for example, rewriting MacType Tuner and MacType Wizard to make them more modern and maintainable

The Wizard appears to be decently good to me. I don't think it needs any rewriting.

For the Tuner, is it possible to monitor MacType.ini and the AlternativeFile (user ini) and automatically reload after those files are modified, reflecting the changes immediately?

After that, it enables MacType enthusiasts to write their own "tuner" application, which provides better interface to edit the .ini files. Since the changes are automatically reloaded, the "tuner" application has no need to offer a preview window, which significantly reduces the technical requirements for the programmers, yet still serves good user experience.

[snowie2000]

Monitoring a file and reload on change is not something hard to implement. However, it would be hard to sync all the switches and trackers on reload.

I'm thinking of adding another mode where users can type in a built-in editor freely and the preview windows will reflect what the profile would look like simultaneously.

[wmjordan]

another mode where users can type in a built-in editor freely and the preview windows will reflect what the profile would look like simultaneously

This is a typical way of implementation. It is OK if the full preview feature is hard to implement.

On partial preview versus full preview, I have a VS extension which allows users to modify syntax highlight settings offers preview window. The scenario is somewhat similar to the one in MacType Tuner. However, the most intuitive way is to present the effects on the whole editor, where various syntax highlighters are working and the ultimate effects are demonstrated. Thus the users of my VS extension can not only see their changes immediately on the preview window, but also on the editor window, where they can then observe the overall effects.

The full preview is extremely useful and helpful since the user can switch to other windows and immediately see how his rendition settings will come.

I am sorry that I don't know about the implementation of MacType, and it is so difficult to "sync all the switches and trackers on reload".

[snowie2000]

I was thinking long long long ago about a so-called debugging mode where mactype disables all the cache and hot reload the profile on-the-fly so that it can demonstrate what the final result looks like in real-time.

The problem is that:

1. Without cache, mactype is very slow.
2. Some settings require mactype to rebuild its alpha blending table which is also slow.
3. Applications with sandbox such as Chrome don't allow mactype to read files from disk.
4. It's easy to crash the system if you made a fatal mistake (especially like replacing a system font with an incompatible one, which happens from time to time)

So I eventually give up the idea.

[wmjordan]

You don't have to abandon the cache.

The slowness makes sense. Full preview does not essentially mean to be real time preview. Issue 1 and issue 2 are not big problem actually. Do what it has to do, including cache. Tell the user to "be patient", and it is possible to optionally or temporarily suppress the preview if necessary in the Tuner. For instance, the full preview only occurs after pressing a button named "refresh", or a check box titled "full preview" being checked...

Problem 3, 4 are some problems. But they are irrelevant to the full preview. If reading from disk is disallowed, it is disallowed by any means. With or without preview, it is the same. Thus it is another problem. If it is to crash, it has to crash. A red-alert should be presented to the user what he is going to do is dangerous.

[snowie2000]

If what you want is to reload the profile without unloading and loading the mactype, the "Restart" item in the context menu of the mactray is what all you need. It calls an internal method to ask mactype to clear all its cache, reload settings from file and reinitialize everything necessary.

Replacing font is always dangerous. The problem is we don't know how dangerous it is until we apply it...

[sammilucia]

The Wizard looks and works fine, the only problem with it is it's difficult to maintain (Delphi).

These are good ideas, and good ideas are certainly a big way of helping! What I'm looking for also is people who can / will help with programming, UX, translating, testing, etc.

[snowie2000]

Anyone who would like to write a new wizard is totally welcome and possible. The interface current wizard used to generate thumbnails is open source. All the loading modes implementations are not secret either.

The reason I didn't publish the source of the wizard is that it relays on my private library and some modified commercial components and, it is a very early product of mine. It is so badly written that I'm not willing to do any large scale work on it.

The popular framework electron allows you to make beautiful and feature-rich applications which is great. However, it is way too big that it is sort of against the principle of MacType.

[ChicoThorn]

Hi! Well it looks like Microsoft is up to its old tricks... They've made some changes in Notepad.exe; exactly what I'm not sure... but in the newest version released with Insider's Build 18963 the text in the edit window as well as the menu items themselves are not being rendered with MacType. I did some experimenting and found that the new Notepad's text and menus will not render at all if using Registry mode. However when running in Services mode the text will render, the menus as well, but the cursor must first be hovered across the menu items or the whole window minimized then restored. In MacTray mode the rendering seemed to work sometimes, but not others. This was true in both Stand Alone and Compatibility options.

I saved a prior copy of Notepad from Build 18941 that still functions properly with all text rendered by MacType. See below for samples of both, as you can see the difference is pretty obvious. I also included the only blurb Microsoft provided in the Insider's blog about the new Notepad, although there's no mention of any change in how text is handled...

Maybe you guys can make sense of it... 😁

2019.08.20· Notepad Build 18963 vs. 18941 Comparison.zip

[snowie2000]

I think they have changed it to a metro app or a win32 transcoded UWP app which is, according to issue #494, not fully supported.

[ChicoThorn]

@snowie2000, Interesting... crazy how they have so many different ways to do the same thing (open apps, render type, etc.). I guess I'll stick with my workaround of using an earlier "unbroken" version of Notepad. Any hope that this odd type of app will be supported in future MacType releases? It'd be great if it were, especially if Windows starts to use this scheme for more apps in the future... 😉

[sammilucia]

@snowie2000 @ChicoThorn I think Microsoft's CEO Satya Nadella will move towards Metro for everything, and eventually deprecate the old systems in Windows (and other products). It makes sense from a business point of view

[snowie2000]

That means we need to figure out how the metro processes are spawned internally.

[ChicoThorn]

@sammilucia and @snowie2000. — I'm baffled as to why the new Notepad can be rendered by MacType in Service mode, but not in Registry mode. In my mind that would indicate that the necessary bits to make it work are present, but for some reason aren't being invoked in Registry mode... ? Is this a fair assumption? ...and if it can work in Service mode then it also seems there must be a way to get it to work in Registry mode as well.

Why am I so stuck on Registry mode? It seems to be the best and most complete way to enjoy MacType's rendering throughout the entire UI, without any unpleasant non-rendering surprises (that is until this new Notepad showed up on the scene). In Registry mode I don't have to fuss with hovering over a type element to invoke MacType's rendering (as is the case with several apps and programs when in Service mode; i.e., Task Manager, and the new Notepad). Registry mode's more seamless experience allows me to forget about font rendering issues and to focus on my work.

Any chance that maybe some tinkering would get Registry mode to work with the new Notepad? 😃

[sammilucia]

@ChicoThorn it could be that the new Notepad has code injection protection. Registry mode uses AppInit_DLLs which is not a recommended method by Microsoft.

MS are trying to make their platform more secure so it would make sense if they stop supporting AppInit_DLLs as an educated guess.

Registry mode also won't work if you have Secure Boot enabled (and we recommend you do) - for the same reasons.

Technically Service and Tray modes are the OS friendly ways to implement the kind of integration MacType does. (But yes as you say - not quite as complete.)

@snowie2000 and I threw around the idea of implementing an API for MacType, so other software could choose to support MacType

[ChicoThorn]

@sammilucia Ahhh... interesting about the AppInit_DLLs ... that explains a LOT! Basically I really like the Service mode too (except for the sometimes hovery-over-the-text-to-get-it-to-render thing). I've been running it about half and half the past week trying to settle on one or the other. But I'm going to do some screenshot comparisons to see if there's a real difference or just my imagination (...and I've been known to have an overactive imagination, so testing is essential, lol! 😁)

[ChicoThorn]

@sammilucia, @snowie2000 — Hi! 😀 So after many screenshots I came to the following conclusions: Registry mode renders everything in the UI really well EXCEPT the new Notepad. Service mode renders everything in the UI really well EXCEPT some alert windows (UAC and registry warnings), and that annoying hover-first-see-rendering-after thing that happens in new Notepad and in Task Manager. So I use Notepad a lot more than I need to see some alert screens brilliantly rendered so I've opted to make Serice my new go-to mode.

On my wish list: Fix it so when in Service mode the user doesn't experience the hover-first-see-rendering-after issue by next release ?? 😊

Service Mode vs. Registry Mode.zip

[sammilucia]

This is really great @ChicoThorn !

[Fidelich]

Hi, @snowie2000, want to present my russian translation of macType. Pls, add it to installer Russian.zip

[snowie2000]

@Fidelich Thank you! We'll add it to the public release.

[snowie2000]

@ChicoThorn The reason that Registry mode stopped working is simply that it doesn't work for all UWP apps from the beginning.

You may wonder that it works for almost all the UWP apps like paint, calculator. That's because normal UWP apps are created from a process called runtimebroker.exe which is a normal win32 executable and can be hooked with registry mode, the processes created by it get hooked automatically by parent-children hooking mechanism.

However, as I mentioned before, notepad is a win32 converted UWP. Those apps have a very special launch mode and I'm still very confused about how they are created. MacType's parent-children hooking mechanism doesn't work for it and nor does the registry mode. The reason it "seems" to work in service and tray mode is that the tray application/service works as a process monitor, it detects newly created process and applies mactype to them. The affected application should refresh its interface automatically by design, but for some reason, this auto-refresh method doesn't work in service mode, you have to hover your mouse to the interface to trigger a repaint.

To see the speciality of win32 converted UWP apps, here is an experiment you may like to try:

• start another instance of explorer.exe, there are many ways to do it, the simplest way is to run explorer , from run task dialog. You can start any amount of explorer instance as you like.
• Launch win32 converted apps from the created explorer windows
• Check process tree via process explorer/process hacker
• You'll see that no matter which window you clicked the shortcut, they are all child processes of the very first explorer.exe

---

• Launch any application that can invoke an open file dialog
• Kill all the explorer instances
• Open an open file dialog
• type *.* as a file filter so that you can see all the files
• Find a win32 converted UWP app shortcut and right-click it, select "open" to run it
• You should see a message box telling you an error like "class not registered" or something, and the UWP application can't be launched.
• Launch explorer from task manager and redo the step above.
• You should be able to run those apps again.

Have fun.

[sammilucia]

@Fidelich you are amazing! Thank you so much 😊 😊 I'm adding it right now. As @snowie2000 says, this will be in the next release 😊

[sammilucia]

@snowie2000 I think Win32 converted apps would be virtualised wouldn't they?

Some initial evidence this may be the case https://social.msdn.microsoft.com/Forums/sqlserver/en-US/4f2bf36a-835a-443e-b4fb-97e97a98d141/uwp-desktop-bridge-virtualization-issues?forum=wpdevelop

[sammilucia]

Some further research suggests there are several limitations of converted UWP apps, like they cannot be forced to run as Administrator. I haven't time to look into it in detail right now, but hopefully that helps?

[sammilucia]

@snowie2000 list of APIs supported only in packaged UWP apps https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

[ChicoThorn]

Thanks @snowie2000 ! — I'll give that experiment a try... should be interesting! 😊

[ChicoThorn]

Hi @snowie2000 and @sammilucia ! 😊

In my never-ending quest to find the perfect settings that work in nearly any point size and in either Dark, Light or Mixed Mode I do believe I may be getting very close! Check out my latest screenshots and .ini file. ChicoThorn.ini is now at version 1.5! WooHoo! 😁

First samples of my new settings at 113% scaling:

And here's the same .ini settings applied at 100% scaling:

The rendering settings from v.15 of the ChicoThorn.ini file

The new ChicoThorn - 113% - v.15.ini

ChicoThorn - 113% - v1.5.zip

And finally a .zip file containing all this new stuff...

{ ChicoThorn MacType Settings· 2019.10.11.zip

Let me know what you think! — I notice that the rendering of the Taskbar Jumplist at 100% in Light Mode is a bit thin, but still clear and readable. The grayed subheads on the Settings Page are also a bit light, but again I think they're workable. 😀

Oh! And as for the changes they made in Notepad so it no longer renders... I gave up trying on that one! 😉 Instead I found myself a nice 3rd party Notepad replacement app, which you've probably heard of: TED Notepad. Apparently it's been around for years, and is still being updated from time to time!

Gotta love and admire these independent programmers and coders who devote so much of their own time on these great Windows enhancements – I'm looking at you guys! You're the best! 😊

Thanks again for MacType and for your dedication to developing it further!

—Thorn

[ChicoThorn]

Hi again! So I was bothered by the fuzziness on the 100% rendering I sent above, especially in Light Mode, so I tweaked the settings a bit more and it's clearer now. That brings ChicoThorn to v.1.5.2 ! Since the fine-tuning changes I made will probably only be able to be seen in the original .png screenshot files, I'll just post the .zip with them in it and forego posting the screenshots here in the thread. 😀😁

The .zip file also contains the updated .ini file.

– Thorn

Screenshots .zip file:

ChicoThorn· 113%· v1.5.2· MacType Settings· 2019.10.11.zip

[ChicoThorn]

For 100% Scaling, I've made these adjustments in this ini file. Check them out, they're a bit sharper! 😊

—Thorn

{¢ ChicoThorn· 100%· v1.5.4.ini Settings.zip

[snowie2000]

This one is actually really decent! even on my poor monitor, it is still really easy to read.

I'm wondering why did you set up a bunch of font replacement but left the fontsubtitution off?

[ChicoThorn]

I did? Holy cow! I thought I had it turned on... 😮 It sure behaves on my computer like I have it turned on... I mean I'm seeing the Segoe UI font used everywhere like I like and not Tahoma or Arial. But I'm just guessing on most of this stuff, so if I messed up somehow it's not too big of a surprise, lol!

I currently have this value under the [General] heading: "FontSubstitutes=1". Is this the correct item which controls the font replacement? Should it have a value other than "0" or "1" ? (I thought "1" was on and "0" off?) I've not been using MacTuner lately when I do the fine tuning, just editing the .ini file directly. But when I do open the .ini file in MacTuner it shows I have 37 font substitutions listed... ? Doesn't that mean it's turned on? 🤔 UPDATE: So I think I figured this part out, 0=None, 1=Secure Replacement, and 2=Complete Replacement. Is that right? If so, then I've had it set to Secure Replacement all this time. Is that okay or should it be Complete Replacement? I experimented with it and didn't really notice a difference between the two so I changed it back to Secure Replacement.

Are "FontLoader=0" and "FontLink=1" also used for Font substitution?

After I first saw your comment I thought maybe having "FontSubstitutes=1" parameter under the [General] heading might be the wrong place for it, so I moved it to just below the [FontSubstitutes] heading in a test .ini file then restarted to check it. Everything still worked, I still was seeing Segoe UI everywhere but when I checked the .ini file in MacTuner it now showed that I had 38 font substitutes, not 37, because it apparently counted the moved entry "FontSubstitutes=1" as a font replacement. So I scrapped that idea and moved it back under [General].

So as is often the case when it comes to this sort of thing for me... I'm confused. lol!

As I said, it appears that my system is only displaying the Segoe UI fonts... but as you know I'm also using Font Substitutes in the Registry to assign Tahoma & Arial to use Segoe UI.

To further test this I opened a blank Word 2013 document to check if font substitution was indeed happening and these are the results:

This is the actual Word doc:

Microsoft Word 2013 FontSub & Replacement.docx

My intention was to have FontSubstitutes on and working. 😉 But if somehow I've managed to botch it and actually have it off, please tell me how I can turn it back on.

Thanks @snowie2000 ! 😀

[snowie2000]

@ChicoThorn My bad. I used an older version of your profile 🤣🤣🤣🤣

I switched to your new profile and it's definitely clearer!

[sammilucia]

@ChicoThorn you're quite mad! I've basically replaced parts of my profile until I've eventually ended up with your profile anyway, so I might as well switch!

Have you seen Source Sans from Adobe? Another really lovely font family designed for UIs https://github.com/adobe-fonts/source-sans-pro ... also a great monospaced font, probably my favourite

[ChicoThorn]

Hahaha! @sammilucia , Mad as a Hatter for sure! lol! 😂 Thanks @snowie2000! Whew! I thought I was really losing it there! 😂 It was a good romp for me nonetheless, I learned a bit more along the way!

—Thorn

[ChicoThorn]

@sammilucia That source-sans-pro font is great! Do you have any other good font recommendations? Maybe a real nice Helvetica/Segoe UI replacement? 😀

[sammilucia]

For UI? Sure... Ideally for UI you want something with a pretty complete unicode set (including emoji) ... Apple San Francisco font is another good choice, or Google Roboto or Open Sans, but neither of them really do it for me. I really like Futura as a Windows UI font (there are many variants with many different x heights so experiment) although I'm not aware of one with full unicode.

Some people seem to like Ubuntu font but it hasn't dated well and is not to my taste.

Aktiv Grotesk was styled as a 21st century replacement to Helvetica ;) It's gorgeous in specimens but I haven't put it to use yet.

Proxima Nova and Gotham are two favourites of mine and used heavily in web apps, possibly not a fit for Windows but worth a try :)

These are all fairly "safe" and sane fonts for UI.

Love to hear what you come up with!

[ChicoThorn]

Thank you! These all sound great! I'm a big fan of Futura myself (Segoe UI actually reminds me a bit of Futura, especially with the better MacType rendering).

I'd like to find replacement fonts for Tahoma and another one for Arial with about the same x-height as each but with better horizontal kerning and/or spacing and of much higher quality.

I'll do some testing of the ones you suggested and put up some samples! 😊

[IceMan81]

@ChicoThorn @sammilucia Not sure if you have seen used Inter, its a good UI font, somewhat similar to Roboto

https://rsms.me/inter/

[kcohar]

hey so i saw this thread and i'd love to contribute! mactype is awesome. i don't know how to code but i can test and translate if that's ok

p.s. Cabin might be a nice font, I used to use it as a UI font in linux and macos, and it's free (libre) too

[snowie2000]

hey so i saw this thread and i'd love to contribute! mactype is awesome. i don't know how to code but i can test and translate if that's ok

p.s. Cabin might be a nice font, I used to use it as a UI font in linux and macos, and it's free (libre) too

Any help is appreciated! Cabin looks good, though I used to love Calibri a lot.

[ChicoThorn]

Happy Holidays & Season Greetings everybody! I've been pretty busy lately... I've had quite a bit of success on a couple of fronts: I've hacked a copy of the Segoe UI font so that its cap height, x-height, and width match those of Tahoma. I renamed it's internal font name to "Microsoft Sans Serif" so that's it's used in all the Dialog boxes (In Registry's Font Substitution it's listed as "MS Shell Dlg" and "MS Shell Dlg 2") This font hack and substitute has really made a HUGE difference in the overall look of the entire UI! Much more consistent and uniform and pleasing to work with! I've also continued fine-tuning the ini settings, and have really liked what I came up with recently that I've actually been able to live with it without changing it for over a month (WooHoo! That's a long time for me, lol!). I'll send along screenshots once I find the time to set 'em all up and mark them. In the meantime, here's a copy of the hacked font I created (it also contains my customized glyphs). I named it "Segue" (get it? It's a segue from Segoe to Microsoft Sans Serif, Arial, and Tahoma!). In MacType's Font Substitute list I've replaced Arial, Tahoma, and Microsoft Sans Serif with my Segue font.

I also changed up the scaling with this latest incarnation. I'm leaving the overall system scaling at 100%, but set the Easy Access > Make Text Biger setting to 113%. This has a wonderful combined effect wherein many elements still remain the standard 9pt system font size, yet all of the UWP UI interfaces use the 113%, which really helps make them clearer and easier to render and read. I also use Winaero Tweaker (a great program developed by Sergey Tkachenko @winreview on Twitter) to change the default icon and File Explorer font size to 10pt, which is nearly identical to what is rendered with the Make Text Bigger Setting at 113%! If you haven't tried out Winaero Tweaker, I highly recommend it!

Oh! And by the way, Microsoft decided NOT to convert our good old friend Notepad to a bastardized Store version after all. As of Insider Build 19037 the OS supplied Notepad was back, and rendering beautifully as it had done before their ill-conceived trial. 😃

I'd love to hear what you think of my latest attempts... Cheers, @sammilucia and @snowie2000 and everyone else involved in helping MacType be the new Windows font rendering standard! Hope you all have a wonderful holiday! 😊

— Thorn

UPDATE: I re-uploaded the sample files .zip... I had forgotten to change the .ini files 'Name' field to be the same as the actual .ini filename. It is now correct.

2019.12.23· Ini & Segue Samples.zip

[sammilucia]

Thanks for all your hard work @ChicoThorn ... I'm very interested to see your version of Segoe 😊 Happy holiday season 😊 x

[namazso]

I'm interested in improving mactype, however I couldn't even get it run on my toolchain. After fiddling around some hours I managed to at least get it build, but it currently just instantly BSODs the test VM with CRITICAL_PROCESS_DIED.

Just some things I noticed that were somewhat significant or annoying:

• Hardcoded paths like this
• Files are not in UTF-8 (or UTF-16 for resource files). If I'd edit them with the wrong encoding the non-english comments would likely break. Considering I don't understand them I couldn't notice this either, nor guess the correct encoding.
• Lots of commented out / dead code that coudl've been handled better via version control, making the codebase hard to try and understand.
• I think https://github.com/snowie2000/mactype/issues/648 is self-explanatory
• EasyHook used is very old, the link library changed filename sometime and there's no version stated in the build guide
• (Trying not to come off as an asshole here, but the non-english comments don't exactly help understanding in my case either)

I think improving accessibility towards developers would significantly improve willingness to contribute.

PS: If the main issues that I cannot solve (encoding and getting it build on a "clean" up-to-date environment) would be fixed, I'd be willing to contribute on the rest

[sammilucia]

This sounds sensible!

[snowie2000]

Let me try to explain some of the problems:

---

• Hardcoded paths like this

This is a problem. I haven't used envs or macros to control the include directories and MacType does depend on some other components.

---

• Files are not in UTF-8 (or UTF-16 for resource files). If I'd edit them with the wrong encoding the non-english comments would likely break. Considering I don't understand them I couldn't notice this either, nor guess the correct encoding.

That's MacType comes from GDI++, a project by a Japanese author who used Shift-JIS for all file encodings. I haven't converted all the files back to utf-8 or unicode yet.

---

• Lots of commented out / dead code that coudl've been handled better via version control, making the codebase hard to try and understand.

MacType development is a kind of trial and error work. I used to comment old codes out and add new experimental codes and then borrow some of the old code back later. This happens all the time. So although doing a full version control makes the code cleaner, commenting and uncommenting is simpler for me. I should be using version control more often in the future.

---

• I think https://githubfast.com/snowie2000/mactype/issues/648 is self-explanatory

Sorry for this comment, I'll try to add a patch folder for patches needed for MacType compiling.

---

• EasyHook used is very old, the link library changed filename sometime and there's no version stated in the build guide

Easyhook is an independent component that you're free to upgrade. It's not coupled with MacType. So there is no version of easyhook that's too old and I didn't provided any link library for easyhook.

---

• (Trying not to come off as an asshole here, but the non-english comments don't exactly help understanding in my case either)

Me either. Lots of comments are derived from GDI++ and they are in Japanese which I don't understand as well. Some of the early comments are written in Chinese, I do translation when I see them.

I'm glad to help you with building issues if you like. There are some steps you could try to help you debug problems:

• Build a dll and don't use it with mactray, use with macloader.exe. It only loads mactype to the process you specified. If anything is wrong with your build, your system can stay intact.
• Build with debug profile. Debug mode gives you some messageboxes before runing so you can attach to the process to see what is happening inside.
• Build win32 version first. Most of the systems nowadays are x64. x86 version of mactype won't be injected in to x64 processes, so your system core processes won't be affected.

[namazso]

That's MacType comes from GDI++, a project by a Japanese author who used Shift-JIS for all file encodings. I haven't converted all the files back to utf-8 or unicode yet.

Are you sure about this? Some files like ft.cpp look incorrect in Shift-JIS: However in GB2312 (chinese) it looks like correct japanese: But I don't know either of the languages to judge which one is the correct for all files. Converting them would help a lot! There are also some odd ones with UTF-8-BOM instead of the more common UTF-8

MacType development is a kind of trial and error work. I used to comment old codes out and add new experimental codes and then borrow some of the old code back later. This happens all the time. So although doing a full version control makes the code cleaner, commenting and uncommenting is simpler for me. I should be using version control more often in the future.

Honestly, just a little bit of cleanup of the long-dead parts like Detours would already be good

Sorry for this comment, I'll try to add a patch folder for patches needed for MacType compiling.

thanks

Easyhook is an independent component that you're free to upgrade. It's not coupled with MacType. So there is no version of easyhook that's too old and I didn't provided any link library for easyhook.

I'm referring to these. Both the .lib name and the .dll name was changed to EasyHook(32|64).(lib|dll) sometime, so just adding the latest easyhook release download to the library path will produce linker errors.

Me either. Lots of comments are derived from GDI++ and they are in Japanese which I don't understand as well.

Oh. I assumed you do. I guess I could try and rewrite them as I figure out the underlying code

* Build a dll and don't use it with mactray, use with macloader.exe. It only loads mactype to the process you specified. If anything is wrong with your build, your system can stay intact.

* Build with debug profile. Debug mode gives you some messageboxes before runing so you can attach to the process to see what is happening inside.

* Build win32 version first. Most of the systems nowadays are x64. x86 version of mactype won't be injected in to x64 processes, so your system core processes won't be affected.

Thanks for these useful tips, I'll try another go at it soon.

[snowie2000]

I'm referring to these. Both the .lib name and the .dll name was changed to EasyHook(32|64).(lib|dll) sometime, so just adding the latest easyhook release download to the library path will produce linker errors.

I don't remember I did that before... Those names were changed from their original names intentionally. Some programs are distributed with their own easyhook dlls which usually have the same name and mactype would erroneously load their version and crash the program.

But I don't know either of the languages to judge which one is the correct for all files. Converting them would help a lot! There are also some odd ones with UTF-8-BOM instead of the more common UTF-8

I don't know why Japanese hiraganas can be displayed correctly under Chinese locale... I applied UTF-8 BOM to some files because, without the BOM, the visual studio just opens and parses the file locale by guessing, and it guessed incorrectly.

[sammilucia]

I don't know why Japanese hiraganas can be displayed correctly under Chinese locale...

It could have something to do with native Windows language.

I maintain the installer for MacType and do some organizational stuff. I've been away for a bit due to illness and launching a company. I'm hoping I'll have more time soon.

I'd just like to step in and say that I think fixing some of these issues to make it easier to maintain MacType (for @snowie2000 and @namazso and anyone) is a big step in the right direction. MacType.

As snowie says MacType came from GDI++ and he's done a remarkable job keeping it working, but there are still some very outdated components that "work well enough" but at some point will need to be addressed. (MacWiz and some other tools are Delphi from memory).

Old stuff gets harder to maintain each year, especially as new generations of devs come onboard.

I'm not a dev for some 20 years. My normal work is as a CEO.

We probably need to have a high level discussion of where to go from here - i.e. what is worth maintaining (mactype.dll?) and what would be easier to just rebuild (MacWiz, Tuner, Tray?). I don't know any of them well enough to even cast a vote.

@namazso maybe that gives you a higher level view too?

I love MacType, Windows drives me crazy without it, it's seriously the first thing I install I'd go mental without it - even just for DirectWrite tuning 😂

[kcohar]

I love MacType, Windows drives me crazy without it, it's seriously the first thing I install I'd go mental without it - even just for DirectWrite tuning 😂

My two cents - MacType is amazing, it's literally why I don't need to use a Mac or Linux, why I've switched to Windows after years of not using Windows, and why I can both game and do my work on my computer now and not have to worry about vendor lock-in (or a lack of compatibility). It makes Windows incredibly comfortable to use, especially considering that it works perfectly in Microsoft Office and in Chromium, and Windows fonts look downright strange without it. That said, as much as I love it the way it is, streamlining it is definitely not a bad idea.

By the way sorry to hear about your illness, hope you feel better soon!

[namazso]

I finally managed to build and run it on a completely clean Windows 10 (2004), with latest Visual Studio 2019, latest v142 toolkit, latest Windows 10 SDK. It actually didn't even need that much changes either.

@snowie2000 is Windows XP support really necessary for this project? The latest Visual Studio platform toolkit (v142 / VS 2019) dropped XP support, five years after it's EOL. If you also think it isn't really necessary anymore, I'd also include the platform toolkit change in a PR i'll soon send.

Edit: this is actually slightly more important than it looks, because the last XP supporting toolkit, v141_xp doesn't support (or at least list in VS) the Windows 10 SDK (only 8.1 and older) and this adds complexity to the building process.