ScrollWindow?

[roozbehid]

Hi,

Thanks for your great API. I am using it for a very interesting project, and will soon also contribute back my changes to your code, but meanwhile I was wondering if you have any plans to have Scrolling APIs implemented? like ScrollWindowEx?

Also what is that black lines always appearing at lower right of screen? Is it a known bug or something?

[ghaerr]

On Jan 2, 2019, at 11:31 AM, roozbehid notifications@github.com wrote:

Hi,

Thanks for your great API. I am using it for a very interesting project,

Thank you, it’s always nice seeing Microwindows being used.

and will soon also contribute back my changes to your code,

Thanks, when you’re all done, send a patch against the current GitHub, if possible. I happen to be heavily involved cleaning up the make system right now, so I definitely suggest staying with the source tree you’re working in for a bit longer.

but meanwhile I was wondering if you have any plans to have Scrolling APIs implemented? like ScrollWindowEx?

When I originally wrote the win32 API in Microwindows, the drivers didn’t include any fast blit routines, so ScrollWindow wasn’t easily implemented. Around 2010 the drivers were all rewritten to use fast blits, and the current win32 BitBlit can be used now and it directly calls the fast blits.

There’s an example of BitBlit being used to scroll a window in the win32 terminal emulator demos/mwin/mwterm.c in EmOutChar().

We could probably write ScrollWindow/Ex quickly using BitBlit but I haven’t been deeply into win32 for a while and I would need a simpler sample program to make sure it gets properly written. Let me know if you have any.

Also what is that black lines always appearing at lower right of screen? Is it a known bug or something?

Are you talking about when running the Emscripten port? Please send a screenshot. I know of no display problems on frame buffer or X11.

I haven’t actually ever run/seen emscripten, but was pleased to see it ported. Georg Potthast did all the work, I’ve cc’d him on this email. If the black lines are occurring on X11 or desktop, I’ll fix the problem once I see it.

Regards,

Greg greg@censoft.com mailto:greg@censoft.com

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/6, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5X08IgRFnOgzYfsjtmcp1pYvsDaCks5u_QkGgaJpZM4ZnHRK.

[roozbehid]

On Jan 2, 2019, at 11:31 AM, roozbehid @.***> wrote: Hi, Thanks for your great API. I am using it for a very interesting project, Thank you, it’s always nice seeing Microwindows being used. and will soon also contribute back my changes to your code, Thanks, when you’re all done, send a patch against the current GitHub, if possible. I happen to be heavily involved cleaning up the make system right now, so I definitely suggest staying with the source tree you’re working in for a bit longer. but meanwhile I was wondering if you have any plans to have Scrolling APIs implemented? like ScrollWindowEx? When I originally wrote the win32 API in Microwindows, the drivers didn’t include any fast blit routines, so ScrollWindow wasn’t easily implemented. Around 2010 the drivers were all rewritten to use fast blits, and the current win32 BitBlit can be used now and it directly calls the fast blits. There’s an example of BitBlit being used to scroll a window in the win32 terminal emulator demos/mwin/mwterm.c in EmOutChar(). We could probably write ScrollWindow/Ex quickly using BitBlit but I haven’t been deeply into win32 for a while and I would need a simpler sample program to make sure it gets properly written. Let me know if you have any.

For my case I want it to enable scrollbars to scroll something. Looking at wine implementation it seems ScrollDC is also required but as you said that one seems easy. But I do not have a simple sample right now. Will see if I can come up with something!

Are you talking about when running the Emscripten port? Please send a screenshot. I know of no display problems on frame buffer or X11. I haven’t actually ever run/seen emscripten, but was pleased to see it ported. Georg Potthast did all the work, I’ve cc’d him on this email. If the black lines are occurring on X11 or desktop, I’ll fix the problem once I see it. Regards, Greg greg@censoft.com

Yes I am talking about Emscripten port.

[roozbehid]

Just to give you an idea of my fun project :

https://webassembly.z19.web.core.windows.net/

This is C# Winforms running inside Browser!

[georgp24]

Hi roozbehid,

the mwtest2.c example shows scrollbars with the MWin API.

Georg

[georgp24]

Sorry, I did not intend to close this.

[ghaerr]

On Jan 4, 2019, at 11:28 AM, roozbehid notifications@github.com wrote:

For my case I want it to enable scrollbars to scroll something. Looking at wine implementation it seems ScrollDC is also required but as you said that one seems easy.

Yes, we can use BitBlit to fairly easily implement ScrollDC, and then use InvalidateRect to have the app paint the newly exposed area.

However, a full-blown implementation of ScrollWindow will require running the existing client-oriented scrollbars in a new non-client area of the window, which could be tricky. I am guessing that win32 uses clipping when the application is drawing in a scrolled-off portion of the window, which we handle now off the bottom, but the top is always 0, which would need fixing up to clip to the scrollbar-set top.

But I do not have a simple sample right now. Will see if I can come up with something!

Ok

Regards,

Greg

[ghaerr]

On Jan 4, 2019, at 11:37 AM, roozbehid notifications@github.com wrote:

Just to give you an idea of my fun project :

https://webassembly.z19.web.core.windows.net/ https://webassembly.z19.web.core.windows.net/ This is C# Winforms running inside Browser!

That is pretty cool, indeed! What code is actually drawing the forms, is it your project’s re-implementation of C# winforms running on win32 API?

The display looks like it’s not using any custom controls, everything is drawn using win32 API, right?

I can see the bottom black lines you’re talking about in the screenshot. I don’t know what method the emscripten microwindows port is doing to draw the screen. Is it the scr_fb.c frame buffer Georg, or something else? First guess is that the buffer reported to emscripten is too large by about a frame line and a half.

By the way, I live in SLC also!

Regards,

Greg

[roozbehid]

Yes everything is drawn using GDI. I actually also ported gdiplus to use MW too. It is mostly using gdi+ to do the drawings.

Oh thats cool. Maybe we can have beer or something sometime!

[ghaerr]

Just wanted to check in with you, I've been making big changes cleaning up a lot of the make system and demo files.

I've taken a personal interest in the EMSCRIPTEN port from Georg and will be adding it to the mainline build. We now have a very complete SDL2 backend that allows fast blit frame buffer copies with no pixel conversion. Do you have many changes in src/engine or src/mwin?

I thought it would be interesting to see them so I don't get too far behind your work.

Regards,

Greg

[roozbehid]

Thanks. I am trying to think how can I make my project compatible with your changes. The problem is I need so many stub functions with no actually code in them in order for my project to build. And also many many more defines are required which are missing in your code.

There were also some bugs and some additional features. I can start by those bugs and those fully implemented features...adding those missing windows definitions wont hurt, but on the other side they are used mostly in some features that you did not implement, so I dont know what is the correct path there.

[ghaerr]

I will accept the IsWindow(), SetParent()/GetAncestor() and mouse bit changes you've sent over, but will pull down your source and edit them slightly since for instance GetAncestor() needs to have some include/GA* defines to compile, and the recently submitted devmicemouse driver uses the hold hard-coded mouse bits and needs to be updated.

With regards to stub functions and large headers of internally unused defines, I would rather keep those out of the project, since accepting them would not generate a compile/link error and the programmer may think the function is implemented, when it is not. We could perhaps throw them into a microwindows/src/extra directory however and devise a method to include them for your compile if that makes sense to you. It might be better to keep all those stubs with your project though, I'll take a closer look at your fork.

Go ahead and send other pull requests you think should be included, especially bugs and new features, and I'll continue to add items so we can get our source trees closer.

I do have a question about some of your "WINAPI" changes - are you creating dll's where it is necessary to have this correct, as the function's data segment needs to be loaded on entry?

I would also like to see any "__stdcall" changed to STDCALL so that we don't have compiler-specific keywords in the source.

[roozbehid]

For sure. I did everything to get sooner to proof of concept,so I am sure I did not follow any good convention or even good code!

My intention was mostly to make things work for WebAssembly, and I do statically link everything so I wanted to disable export status for WINAPI. as it add "_" (I guess) to symbol name. For Windows (which I use MSVC) I still needed WINAPI and exported status. I do recall there are some functions with missing WINAPI though, I will send a pull request for them too.

On STDCALL, you are right. I will do that on my side too.

Also do you want fixes for MSVC compiler too?

[ghaerr]

I have produced a diff with all changes you've made to Microwindows since your fork and have reviewed the entire diff. I can see a path forward to get the required changes integrated into my source tree quickly. However, I suggest that almost all the stub routines and extra .c files be pulled out of their current locations with the tree and moved to src/mwinextra/winextra.h or various .c files. You can then set a -I option to cause them to be included from windows.h and this should allow you to produce an WIN32 and EMSCRIPTEN library for use with linking your application.

I have very brief comments in the attached rooz.txt, please let me know if you understand what I'm talking about and I can then start on adding all the internal changes immediately. The diff it refers to is pass1.diff.txt, also attached for reference. I did this rather quickly, let me know what you'd like to discuss, and I can produce a framework for you to copy files to quickly once we agree. rooz.txt pass1.diff.txt

[ghaerr]

I forgot to answer your questions directly:

On STDCALL, I can make this and all the WINAPI changes on my side, but I need to know what your building for with _MSC_VER: if it is for Windows, then these can be #if WIN32 in my source, and then for EMSCRIPTEN both WINAPI and STDCALL will be blank. I still recommend not using __stdcall at all unless Windows forces you to.

I have all the MSVC fixes, but find the following guards for them, and we can only pick one: _MSC_VER, WIN32, _WIN32, _WIN64 and !defined EMSCRIPTEN. (The last option won't work, as it breaks all UNIX, for instance). I suggest guarding everything with #if WIN32, as that's what Microwindows currently uses. However, there still may be issues with this and MINGW32. Thus my interest in knowing more about your target, as we may need to separate out compiler issues versus platform issues.

[roozbehid]

Thanks for all your effort, I highly appreciate it, I also feel bad that I wrote that much of shitty code :D

I think I do agree with all the changes you proposed, but I do have some questions.

• Why "can't use pragma pack(1) for WNDCLASSA or MSG" ? Because I am using inter-op of compilers, I need to be sure that alignments are correct. pack(2) or pack(4) can also work, but some kind of alignment I think is required.

• LOGFONT was deleted, because A or W usually in Windows are picked based some definition that is your program using wide chars or not. So it makes sense that for example CreateFontA only uses LOGFONTA and CreateFontW only uses LOGFONTW, based on some definition, we define CreateFont as CreateFontA or CreateFontW. Anyway as MW doesnt have much W version, not that important yet.

• Why "cant add include math.h"?

• I totally agree with __stdcall problem. Lets keep everything clean and use STDCALL.

• Lets use WIN32. We might end up using MSC_VER to distinguish between MING or MSVC. But lets assume it is just MSVC for now!

• I have no idea on those libc functions with _, if they are supported in linux/other platforms or not. But it could be a simple re-def of them so you wont need to change your code. (I mean _read vs read, _close vs close). But if MSVC compiler msg is correct it seems they are long deprecated and users should use underscore version......dont know!

• My targets so far was Win32/x86/SDL1/Dynamic Library and WebAssembly/SDL2/StaticLibrary. I know you deprecated SDL1 (which I agree) But I couldn't build previously for SDL2 on Windows, some functions seems to be missing or took other parameters. I will try again and let you know.

• I also agree with src/mwinextra or maybe we can name it like contrib or some place deeper if you dont want to pollute your main src tree.

I think the best way forward is you apply the changes you are comfortable with then I start from scratch and create pull requests. I also like to use my Visual Studio project files, they can also reside in any folder structure. No need for them to be in the root of project. Maybe contrib/vcxproj or contrib/project or project.

Another suggestion: How about setting up Appveyor or Azure Pipeline for this project for CI part. They are both free and good and I do have experience with them. That way we can try to build project for many configurations and thus know if everything works fine or not. Appveyor supports Linux and Windows images. Azure supports Windows/Linux/Mac images. Also github recently introduced their own pipelines which is also cool too. It is enabled for me but if you dont have it you have to sign up and I guess they will enable it. Everything is done inside dockers, so we can also choose different dockers to do the builds.

[ghaerr]

Thanks for your quick response. See my comment below.

On Jan 30, 2019, at 11:13 AM, roozbehid notifications@github.com wrote:

Thanks for all your effort, I highly appreciate it, I also feel bad that I wrote that much of shitty code :D

No worries - looks like you’re doing a great job actually!

I think I do agree with all the changes you proposed, but I do have some questions.

Why "can't use pragma pack(1) for WNDCLASSA or MSG" ? Because I am using inter-op of compilers, I need to be sure that alignments are correct. pack(2) or pack(4) can also work, but some kind of alignment I think is required.

I just mean to say that I can’t add #pragma pack into the Microwindows tree source. But there’s no reason for it - you’re not using the two compilers (MSVC and EMCC) for the same link, so I don’t see why you’re worried. Are you passing MSG structs around?

In looking at MSG, each member is already at a 32-bit boundary, so pack(2) or pack(4) wouldn’t make any difference anyways. Almost all modern compilers pack to 32-bit boundaries.

Same comment for WNDCLASSA, I don’t see how its needed.

LOGFONT was deleted, because A or W usually in Windows are picked based some definition that is your program using wide chars or not.

I understand that. In Microwindows, we don’t support any of the W functions and thus LOGFONT and LOGFONTA are the same thing. In some instances, the user may #define an A function but I haven;’t complicated the tree with all that junk, since W functions aren’t supported anyways.

So it makes sense that for example CreateFontA only uses LOGFONTA and CreateFontW only uses LOGFONTW, based on some definition, we define CreateFont as CreateFontA or CreateFontW. Anyway as MW doesnt have much W version, not that important yet.

We may have to create a LOGFONTW if you must use CreateFontIndirectW. Does your app require the W font function? If so, this could possibly be handled in another fashion, although I doubt the font name is stored in the filesystem in unicode, just ascii specified as unicode.

Why "cant add include math.h"?

Just saying that I can’t accept a patch adding this to windows.h. I have taken great care not to have includes within includes, except where absolutely needed. Does Win32 include math.h in windows.h? Or why exactly was this needed?

I totally agree with __stdcall problem. Lets keep everything clean and use STDCALL.

I’m not sure you understand my issue here: I was suggesting that you not use __stdcall or STDCALL at all: why exactly do you need it? This is usually only required for calling INTO other Windows DLLs, but we aren’t doing any of that, right?

Lets use WIN32. We might end up using MSC_VER to distinguish between MING or MSVC. But lets assume it is just MSVC for now!

Ok. I will take a first pass at getting all this working.

I have no idea on those libc functions with _, if they are supported in linux/other platforms or not. But it could be a simple re-def of them so you wont need to change your could. (I mean _read vs read, _close vs close). But if MSVC compiler msg is correct it seems they are long deprecated and users should use underscore version......dont know yet!

I have a fix for this with a modified unistd.h, which will define the _open and other functions.

My targets so far was Win32/x86/SDL1/Dynamic Library and WebAssembly/SDL2/StaticLibrary. I know you deprecated SDL1 (which I agree) But I couldn't build previously for SDL2, some functions seems to be missing. I will try again and let you know.

Thanks, I get it now. Let me know if you can get SDL2 working with Windows.

I also agree with src/mwinextra or maybe we can name it like contrib or some place deeper if you dont want to pollute your main src tree.

Ok, I’ll take a pass at this also.

I think the best way forward is you apply the changes you are comfortable with then I start from scratch and create pull requests. I also like to use my Visual Studio project files, they can also reside in any folder structure. No need for them to be in the root of project. Maybe contrib/vcxproj or contrib/project or project.

Ok, I will take a first pass at this also.

Another suggestion: How about setting up Appveyor or Azure Pipeline for this project for CI part. They are both free and good and I do have experience with them. That way we can try to build project for many configurations and thus know if everything works fine or not. Appveyor supports Linux and Windows images. Azure supports Windows/Linux/Mac images. Also github recently introduced their own pipelines which is also cool too. It is enabled for me but if you dont have it you have to sign up and I guess they will enable it. Everything is done inside dockers, so we can also choose different dockers to do the builds.

Sounds interesting, I will look into this, thanks.

Regards,

Greg

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ghaerr/microwindows/issues/6#issuecomment-459049863, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbi5dbYAKc_UxZmKOzCbFBMEG3yog5mks5vIeDkgaJpZM4ZnHRK.

[ghaerr]

I have reviewed your Microwindows fork and have added all internal .c and .h changes, with only the exception of the stdcall usage. stdcall is now defined in WINAPI, CALLBACK and STDCALL #defines.

All internal changes are included using -DWINEXTRA=1 and -DWIN32DLL=1 and all extra files required for Microwindows to compile with your changes have been added to src/contrib/winextra/. You can add any other *.h headers to that directory or another separate directory (using -I) to compile your WinForms project. In this way you can decide whether to include zillions of ancillary .h files needed just for your project, versus those needed for Microwindows to handle your project internally.

I have tested the compilation of all your changes using the Config/config.winextra config script, and everything compiles and runs using SDL2. A single winextra.h includes all additional header files and the mwin/Makefile adds all additional .c files required for Microwindows for your project.

I have included important compilation instructions in src/ROOZ.txt (also attached) which you will need to add to your VS project. With the exception of some discussion on the actual need of using STDCALL/__stdcall, you should have everything you need to get your project running under the new tree with little work.

I have attached a diff of the changes NOT applied from your fork to Microwindows (not including the large mass of wholly new *.h windows files required for your project to compile). notdone.txt

Let me know if you have any questions, and thanks!

Greg ROOZ.txt