Listener is not listening on Win 10 Home (build 15002+)

Hello,
Thank you for rdpwrap!
Unfortunately, on Windows 10 Home edition, it is not working anymore since Insider build 15002.
Rdpwrap is fully updated and says "fully supported", but Listener state is "not listening" for some reason.
Thank you!

Support for 15007 has been added in https://github.com/stascorp/rdpwrap/commit/5814e3fcf126989f1a5d5ecdcffdadb884a16245, try again.

Hello,
I have updated and tested again on 15007, without success.
It is not working on a Home edition, here is what RDPConf is displaying:

wrapper: installed
service: running
listener: not listening

I am experiencing the same thing on a fresh WIndows 10 Home install.

i.e., Listener state: not listening

Try this way, maybe it will help: https://github.com/stascorp/rdpwrap/issues/45#issuecomment-182632817

Hello, I have tried again several times today, and it is not working.
I am nowhere near as good as you are, but it looks like M$ have changed their SLC method again starting with 15002...
15002 have public symbols, but I am not good enough to understand them sorry...

I have the same Problem with 15002.

I'm experiencing the same issue on 15007. Already tried a reinstall.

Issue confirmed in 10.0.15007.1000.

Interesting observation about file sizes between builds:

Build
x86 size
x64 size

10.0.14971.1000
840 KB
998 KB

10.0.14986.1000
840 KB
998 KB

10.0.15002.1001
847 KB
1002 KB

10.0.15007.1000
847 KB
1002 KB

10.0.15014.1000
847 KB
1002 KB

So there's something new added in 15002.

Hello,
Same issue with 15014 and 15019 :-(

Hello,
I have tried to debug the TermService, but I am not skilled enough :(
According to me, it looks like the patching of the global variables (bRemoteConnAllowed...) is done well, but this is not enough: the service does not start listening on RDP port.
Maybe there is a new variable?
Maybe the fact that CSQLQuery::Initialize() is not executed is blocking the service launch?
I fear this issue will be worse once Microsoft releases its next public version (probably in 1 month or so) - could you help me to fix this issue please?

Maybe the fact that CSQLQuery::Initialize() is not executed is blocking the service launch?

@aiugrivef Win 10 Pro have no problems with RDPWrap, so I think there is something other.

Having the same issue on 15048.

Having the same issue on 15048.

Not big surprise.

Win 10 Home does not support RDP I think.

Win 10 Home does not support RDP at all I think.

O RLY?
This is plain Windows 10 (core).

/me too
On a Windows 10 Home Insider Build, Version 1703, Build 15063.0 ("systeminfo"),
OS Name:                   Microsoft Windows 10 Home
OS Version:                10.0.15063 N/A Build 15063
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free

I continue to get
Listener State: Not listening
from RDPConf.exe, although my build is flagged as fully supported. RDPCheck.exe will not connect (to <IP_ADDRESS>)
I have tried
git pull
update.bat
uninstall.bat
install.bat

The irritating part here is "[+] Successfully installed.", where as earlier it complains

[-] This version of Terminal Services is not supported.
Try running "update.bat" or "RDPWInst -w" to download latest INI file.
If it doesn't help, send your termsrv.dll to project developer for support.

File termsrv.dll in %WINDOWDIR%\System32 has a size of 992,256 bytes

With respect to "send your termsrv.dll to project developer for support" - what is the preferred means?

I have experienced the same issue as @shoffmeister
Win 10 build 15063.15 - attached termserv.dll
Here is my termserv.dll:
termsrv.zip
[*] Installing...
[*] Terminal Services version: 10.0.15063.0
[-] This version of Terminal Services is not supported.
Try running "update.bat" or "RDPWInst -w" to download latest INI file.
If it doesn't help, send your termsrv.dll to project developer for support.
[+] TermService found (pid 1096).
[*] No shared services found.
[*] Extracting files...
[*] Downloading latest INI file...
[+] Latest INI file -> C:\Program Files\RDP Wrapper\rdpwrap.ini
[+] Extracted rdpw64 -> C:\Program Files\RDP Wrapper\rdpwrap.dll
[*] Configuring service library...
[*] Checking dependencies...
[*] Checking CertPropSvc...
[*] Checking SessionEnv...
[*] Terminating service...
[*] Starting TermService...
[*] Configuring registry...
[*] Configuring firewall...
Ok.

[+] Successfully installed.

But It's not successfully installed:

As novice can only pay close attention. I hope you can solve it at an early date.

I hope you can solve it at an early date.

Hi.
I am not sure what this means?  Does this mean that the issue is not possible to resolve?

This means it is not so easy to resolve.

Is it possible to provide any technical details so perhaps we can try and contribute to getting this solved?

Is it possible to provide any technical details so perhaps we can try and contribute to getting this solved?

Okay, so there is we already know:

build 10.0.14986.1000 have no issue
build 10.0.15002.1001 introduced the issue

This means the latter build has changed something in the code - it may be termsrv.dll, but may be not.
So, it will require to set up two (virtual) machines with these two different Windows 10 builds. Then enable kernel debugger with serial output, and try to investigate where the behaviour differs.
When we find the actual reason of the listener problem, it will be possible to fix it.

The "Fully supported" is a bit confusing, to be honest, although I now understand this to only to refer to successful hot-patching of the termsrv.dll PE image.
I am not sure whether I'd be up-to-speed to support here; I don't have good tooling (no IDA Pro, for instance) and no awareness / mental model of the peculiar things that happen in terminal server licensing, and do not know the enabling strategy used by rdpwrap.
FWIW, wouldn't it make sense to religiously check the return value of all API calls, e.g. at
WriteProcessMemory(GetCurrentProcess, SignPtr, @Patch[I][0], Length(Patch[I]), bw);
I am not sure whether Delphi has acquired a compiler warning switch which flags these scenarios, sorry.
Anyway, thank you very much for acknowledging the issue, for the service - and happy hunting!

The "Fully supported" is a bit confusing, to be honest, although I now understand this to only to refer to successful hot-patching of the termsrv.dll PE image.

This does not refer to successful hot-patching. This only indicates that INI file includes current termsrv.dll build section.

FWIW, wouldn't it make sense to religiously check the return value of all API calls

Good idea. Since RDP Wrapper have a log file, these events can be logged into it. For now they are not checked for successfull execution.

FWIW, I just realized that the Delphi version is not what I would be running, being that I am on a 64 bit OS. Fortunately, the API result checking strategy in the C++ version matches ;)
This may be a stupid question, but why is there (still) a Delphi version around, as the C++ version seems to be more general? (I do have very fond memories of my times with Delphi, mind you)
And why is the C++ version in C++, given that I see nothing that could not be done easily in plain C, either? (The INI class would be almost a search/replace conversion, at least on first glance). Using C would have the benefit of having a smaller runtime library, with less "magic" going on underneath. If that DLL is mapped into a "foreign" process space, then DLL_PROCESS_ATTACH and DLL_THREAD_ATTACH would be a whole lot less worrisome.  (https://msdn.microsoft.com/en-us/library/988ye33t.aspx)
Anyway, once upon a time, up to and including Windows XP / 32 bit, I was doing (other) hooking and injection - this is only faint recollection of my troubles with, specifically, the Delphi RTL doing unwanted things such as re-init of the FPU control word (but conceptionally totally within the spirit of Delphi, no less).

 (I do have very fond memories of my times with Delphi, mind you)

Delphi compiled binary (rdpwrap.dll) has smaller size against C++ x86 compiled binary.

And why is the C++ version in C++, given that I see nothing that could not be done easily in plain C, either?

Well, that was not my choose, since it was ported by @FusixGit.

The INI class would be almost a search/replace conversion, at least on first glance). Using C would have the benefit of having a smaller runtime library, with less "magic" going on underneath.

I agree with this. Also some days ago I realized that INI class can be replaced by using these APIs:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724353(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms725501(v=vs.85).aspx
etc.

Best way to solve the problem is to buy a win 10 pro version on ebay for 5€.

Do you really think to get a regular license for 5€?

I think so. Otherwise it is not allowed to be on ebay.
http://tinyurl.com/l2hje9t

Also eagerly awaiting for a fix. Thanks to developer(s) looking into it.

Hey my ticket didn't get resolved and was closed?!
I was told it's a duplicate but it's a different issue.
My RDP worked until upgrading to Creators Update (1703) on Win 10 Home but now is "not listening"

@Recka50 it is not different issue, it's the same.

See https://github.com/stascorp/rdpwrap/issues/229#issuecomment-292485948.

"Not listening" after Creators update even with older version of termsrv.dll (14393). Looks like MS insists on "no rdp in Home edition" and introduced some new mechanism outside of termsrv.dll .

I don't know if it helps but I had an updated windows 10 home that used to work, I had to install it from scratch and it ceased to work. I mean: updated version coming from an old version -> works ; updated version installed from scratch -> does not work

Is this a home edition issue or is it for all versions?

Win 7 unlimited sp 1 same issue here, listener state : not listening.

@erdemcc yes, only Home Edition.
@NakKampung your issue is not the same, provide diagnostics screenshot.

I apologize for being off-topic: the link @aphofes provided for 5 EUR  upgrade to pro actually works. I needed to upgrade one of my PC's to professional (for reasons which have nothing to do with RDP), so I decided to risk the cost of pint of beer, and ended up pleasantly surprised. However I still have a bunch of PC's running the home edition, so I value the work of RDPwrap developers and(of course) eagerly wait for its update.
Keep up the good work!

I know about the issue with Creators Update  what I meant was will it get fixed?

@otalado Please be aware that these PRO keys are not legal and the key will most likely going to be deactivated in months. Legal upgrades of Windows from Home to Pro will cost you around 100 USD, unless you are lucky, anything costing less than that was very likely obtained through improper channels and is likely going to be eventually deactivated by Microsoft. They are obtained through MSDN subscriptions for example and then sold to many people.

Got into trouble after installing creator's update 1703 on my windows 10 home on Atom stick. Not able to do remote desktop to that machine after the update. RDPWrap not listening error. Request @binarymaster  to  fix the issue as soon as possible. Waiting for the same..........

Working perfectly on W10 Home x64 before creator's update, now also 'not listening'.
Great job so far, hopefully the clever guys can figure out how to enable it again.

This's a free project so we need to keep calm and wait :)

Is this the best place to look to see when this is fixed?
Same problem, Windows 10 Version 1703, Build 15063.138

I don't have any knowledge with Windows's kernels and such, but would restoring the relevant files to RDP from before this update may be able to resolve this?

Restoring the old version of termsrv.dll does not help. It must be more than only this.
Seems M$ made this more complicated in purpose. I'd pay some moeny for this functionality but surely not 100 or more bucks for the whole Win 10 Pro only to have this feature. The worst thing is that there is no equivalent. Teamviewwer or VNC and similar stuff make it impossible to work in few sessions simultaneousle on one machine :( RDP makes this possible.
@binarymaster - have you perhaps have any progress with the analysis or the fix itself? Great job so far! RDPwrap was one of the key things I applied to my Win10 Home

Home Edition, Starter Edition was fine for both Windows 7 or 10. But after this 15063.138 update from Windows 10 everything stopped.
This version should support RDP out of the box anyway.

Concurrent sessions for one

@Marty56
I think you do not get understand the concept yet. This application unleashes the multi RDP feature on your regular windows, which is officially and only available in Windows Server Platforms. This means multiple users can log-in to the same desktop at the same time.

Guys I have Pro (Enterprise actually) and it doesn't work either. Build 16179 here.

I am using Windows 10 Home Creators edition, and it has broken the listening link.  Can this be updated to function in the creators update ? I hate using Teamviewer

same as above
hope master can fix this

same issue((

I am facing the same hopefully a update will be released for this

Has anyone tried this on Windows 10 Pro build 15063 and had any issues?

Same here, after doing Creators Update on Win 10 Home.
Microsoft Windows [Version 10.0.15063]
RDPwrapper 1.6.1
Fingers crossed it is possible to fix it!

sorry to bother u bt still NOT LISTENING(•̩̩̩̩＿•̩̩̩̩)

@MrObvious

Guys I have Pro (Enterprise actually) and it doesn't work either. Build 16179 here.

Added in https://github.com/stascorp/rdpwrap/commit/8b2e24cecf62dba1cbcbec07cc033541de5516f1, run update.

Hi @binarymaster
Same here, after doing Creators Update on Win 10 Home today night.
Microsoft Windows [Version 10.0.15063]
RDPwrapper 1.6.1
Hope you can find the fix !!!

Same problem with the creator update.

Looks like it's working for me...

Win 10 Enterprise build 16184.

MrObvious ，how do u update to ver. 10.0.16184.1001？
i clicked update.bat and still 10.0.15063.0

Home Edition uses a different build then you. I may just upgrade to PRO if they can't fix it.

Windows build. I'm on the Insider Fast Ring.

so i can't update to ver. 10.0.16184.1001？

http://www.windowscentral.com/how-join-windows-insider-program
I don't know why Home builds would be different.

Home builds do not allow the PC to act as a Remote Desktop host.  That's been true for the last several Windows OSs.

I'm on 16179 and even with last update, still not listening.
I hate this.

@binarymaster wrote:

Okay, so this is we already know:

build 10.0.14986.1000 have no issue
build 10.0.15002.1001 introduced the issue

It means the latter build has changed something in the code - it may be termsrv.dll, but may be not.

Yes.  And as Windows instance generally can be seen as a combination of Files + Registry values, a way to do such minimal incremental change (update) may let investigator use simple comparison between trees of files and registry branches on both instances (versions).
I used such method of blind diffing a lot when debugging Wine circa 2005.

So, it will require to set up two (virtual) machines with these two different Windows 10 Home builds (Pro is not affected). Then enable kernel debugger with serial output, and try to investigate where the behaviour differs (with RDP Wrapper installed).

Right, this is more analytical method.  It would benefit from being able to do an minimal incremental change too.  Does anyone know if there are any other w10home builds between 10.0.14986.1000 and 10.0.15002.1001 ?
I am not w10 guy but got interested.

Does anyone know if there are any other w10home builds between 10.0.14986.1000 and 10.0.15002.1001 ?

Obviously, but they are not publicly released by Microsoft. Both builds available for "insiders".

Thanks for all the work you guys are doing; this app has been a lifesaver!
I installed on windows 10 home (ver 1607 OS Build 14393.0) today and had all the 'not listening' problems at first, then ran the updater batch and the RDPcheck started working!
Now happily remoting from Windows 7 Pro..

@sskras
Actually, i got bug in 16179 Windows 10 PRO
My state it's all fine (actually, should start service manually, doesnt start up when install RDP Wrapper on this version) then, stay everything good BUT "Not Listening".
If i can do some test for look out where is the problem, i will be happy helping.
Thanks

I have two programs running as services that needed to have the AppNoConsole psrameter set to 1 for them to work with the latest build of Windows 10 Home. I think this could be related to RDPWrapper's difficulty with this version.

Passing in to see the progress of the present ...
It seems the latest version still do not listening

@binarymaster - Here is the build of windows home that I am on which still is not working after the latest update:

And just for verification, I am on the latest as of this morning but the listener state is still "Not Listening":

People - I think everyone has the message now.
After the publicly distributed Creator's Update, RDPWrap doesn't work any more.
Let's leave the clever people in peace for a while and hope that they can come up with another great solution for us. And if they do, then please let's have at least as many thanks as these requests.

Calm down dude. We're trying to provide more information to help. Take your holier than thou attitude somewhere else.

@digitalmonarch , the only information your post provides is:

you run w10home without Inside Preview updates;
OS Build (15063.250) differs from minor version of the service (shown in the pic, 10.0.15063.0).

Did I get you right?
If yes, that could have been simply put into two lines instead of making larger post.  Or at least at the start, not the end of it:)
Plus, IMO @cmhowarth just wants to keep Signal-to-Noize ratio as low as possible here – it's doesn't look like an attidude to me, really.  Thanks anyway:)

Thanks to @binarymaster I found some Build 14997.  But it seems to be an Enterprise edition + "rs_onecore_base" branch instead of "rs_prerelease":

10.0.14997.1001.rs_onecore_base.161218-0833_amd64fre_client-enterprise_volume_en-us-CENA_X64FREV_EN-US_DV5.iso

So it would probably be uninteresting as middle testing step for this "regression", right?
Unless it can be somehow turned into Home edition, nah?

If you're looking for older builds, see here:
https://mdl-tb.ct8.pl/products.php?prod=win10ip&lang=en-US

@sskras
If I'm not mistaking, Build 14997 was never released to the insiders (that is why it has the rs_onecore_base), it was only a leaked ISO, and there was only the Enterprise.

@sskras wrote:

I found some Build 14997. But it seems to be an Enterprise edition + "rs_onecore_base" branch instead of "rs_prerelease"
So it would probably be uninteresting as middle testing step for this "regression", right?
Unless it can be somehow turned into Home edition, nah?

Please share termsrv.dll file from this release, both x86 and x64 if possible. It would be interesting to compare file sizes against known values.

@binarymaster

Please share termsrv.dll file from this release, both x86 and x64 if possible. It would be interesting to compare file sizes against known values.

There was also only this one single ISO @sskras mentioned (64 bit I think), so you cannot have both x86 and x64.

termsrv.zip
Im on 16179 and this is the version of Termsrv that i got here.

16179

I don't need this version since I already added it.

Just installed from scratch Windows 10 Pro on VirtualBox, then isntalled and updated RDPWrap as administrator and everything is working fine for me...

termsrv.zip
It was working for me prior to Creators Update. I am now on version 10.0.15063 and it is not working anymore.
I hope my termsrv.dll can help you

@chshkhr (and everyone else), the issue is only for Home edition.

No it's not. I'm having it in PRO version of creators...
El 9/5/2017 14:43, "l33tissw00t"<EMAIL_ADDRESS>escribió:

@chshkhr https://github.com/chshkhr (and everyone else), the issue is
only for Home edition.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/stascorp/rdpwrap/issues/194#issuecomment-300245883,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AbLkIgwvqYc0Xdl1xwXnDRu60MX8_KAPks5r4KXdgaJpZM4LjrPS
.

@gonzalon88 it works fine in the Pro version for Creators update for me. Only Home is having the issue for me.

For god sake. I'm sending my capture.
Maybe in the build that you are running.

El 9/5/2017 17:26, "ManiacDC"<EMAIL_ADDRESS>escribió:

@gonzalon88 https://github.com/gonzalon88 it works fine in the Pro
version for Creators update for me. Only Home is having the issue for me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stascorp/rdpwrap/issues/194#issuecomment-300290911,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AbLkIj1euyymHey6G5fk_eTXT26f1Mikks5r4MvwgaJpZM4LjrPS
.

There are a lot of "it's happening to me too" comments here, but no progress on finding a workaround.
Could anyone with more experience in debugging this issue provide some information on how to tackle this? I haven't done Windows programming since the Visual Basic days (before .NET) so I'm really rusty in this aspect, but maybe with some steps, I or somebody else could provide some more information.
Please don't consider this comment as a rant, I'm just trying to move further on fixing this.

for me on 1703 Creator Pro 10 RDP Wrapper not work, i choose the alternative option und fix the termsrv.dll with a hex editor
search for
39 81 3C 06 00 00 0F 84 53 71 02 00
and replace it with
39 81 3C 06 00 00 0F 84 53 71 02 00
then it works on 1703 Creator Pro 10
but make a backup before for Rollback etc.

@kockott
Both are
39 81 3C 06 00 00 0F 84 53 71 02 00
What is the original intention?

oh sorry - i have edit the wrong value into B8 00 01 00 00 89 81 38 06 00 00 90

Closer adress that i got from original value that must be edit, its this:

I'm doing this in a blind way, im not sure what i'm doing. So, im happy that are lot of experienced people helping here!
Thanks!

I rollback KB4019472 update and RDP Wrapper Worked for me.
As temporary it is possible to use RDP Wrapper.

@binarymaster,

I found some Build 14997. But it seems to be an Enterprise edition + "rs_onecore_base" branch instead of "rs_prerelease"

Please share termsrv.dll file from this release, both x86 and x64 if possible. It would be interesting to compare file sizes against known values.

Finally I got time to install this release:
OS Name:                   Microsoft Windows 10 Enterprise Insider Preview
OS Version:                10.0.14997 N/A Build 14997
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
...
Product ID:                00329-00000-00003-AA883

I agree to @YisroelAdler, it's x64 version only, I guess.
Here it is: termsrv.dll (1,002 KB, 10.0.14997.1001).zip
Of course, RDP Wrapper says "not supported":

This is after I run update.bat:
[Main]
Updated=2017-05-12
LogFile=\rdpwrap.txt

@sskras This version have the same size as 10.0.15002.1001 x64 version, so this build seems to be affected too. INI file updated.

Same problem, Windows 10 Version 1703, Build 15063.296

Exactly the same as @thechrisgregory here. Cannot connect, and RDPCheck also fails with a "Socket connection failed" error.

Any idea to make it finally work again ?

Does this affect Win 10 Pro? - I have turned off updates for now.
Wish I could help.

Exactly as @thechrisgregory and @msiniscalchi.

Same here. Does it means there will be no possibility to get RDP on Home edition anytime soon?

RDP works fine on W10 Pro Creators Update (as it should because it's one of the Pro's features). What wont work on Pro are all the features of RDP Wraper (ex. multisession, console and remote session at the same time, etc...)

@GTT8 - I beg to differ, I have Windows 10 Pro Version 1703 (15063.296), with the creator update and remote desktop multi-sessions work just fine.

You have Pro, remote desktop is a feature of Pro, if you had a home version of win10 you would have this issue

First of all, thanks for providing this software. It's awesome because the only Pro feature I need is RDP.
I had the same problem after applying the Creators Update to Windows 10 home. I rolled back the creators update by using "Go back to an earlier build" in Windows 10. I think this option is only available for 10 days after the upgrade. Could you please let me know if you found a solution? I am waiting to apply the Creators Update until then.

same problem with new w10 Home version...
Trying to find an alternative...
Br

@thechrisgregory You are rightI've reinstalled RDPWrap and it works fine now. Thanks!

GTT8  - what version Windows 10 do you run ?

thanks to all, but not working after installation of Windows 10 Home Creators update.
I run  Windows 10 Home (10.0.15063.296).
I use RDPWrap-v1.6 and I did uninstall, install & update.  Conf is ok, but when Check : it gives "socket connection failed".
I run the same settings on 3 PCs ... with the same result, but before Creators it was fine.
Is the a way to run RDPWinst.exe in a CMD line with some parameters / switches to help u ?
Thanks a lot.  BR

it seems that rdpwrap project is dead, i use "upgrade to Pro version" (Win10 home creators update --> Win10 Pro), this is simple method and quick.
Does anybody knows what method use microsoft to make rdpwrap "not listening"? it looks like a undocumented firewall features or something like this.

thanks to all, but not working after installation of Windows 10 Home Creators update.
Yes, that's what this thread is about.

it seems that rdpwrap project is dead
4 commits this month, must be dead! How about not insulting the developers?

many information at google, just enter another product code (to pass this step just find a code at google)
Sure, if you want a pirated version.

Does anybody knows what method use microsoft to make rdpwrap "not listening" at home version?
Nobody is sure yet, that's why it doesn't work. You could have read this thread to find out.

Mika3444  said "upgrade to Pro version" (Win10 home creators update --> Win10 Pro), this is simple method and quick "
but this is not a free upgrade,  RIGHT ?

termsrv.zip
mrpentium, a legitimate upgrade to Pro from Home is $139 Canadian, which I guess is likely $100US. You can do the upgrade yourself from the Settings About screen using the link "Change product key or upgrade you edition of Windows"
Listener state: Not listening
I'm currently running x64 Home v10.0.15063.332
termsrv.dll is from 2017/03/18 4:58pm v10.0.15063.0
v1.6.1 of RDP Wrap library
[] Current update date: 2017.05.29
[] Latest update date:  2017.05.29
[*] Everything is up to date.
I am open to suggestions. I can use a Hex editor. I can replace my termsrv.dll and re-apply the correct permissions to it. I have faith in binarymaster to solve this. I'm the admin for a fairly hefty Windows 2016 Hyper-V server with a 150Mbps synchronous Internet connection, so if you (binarymaster) have any VMs for me to play around with or test while logging with Process Monitor, reach out and let me know if I might be able to help.

@mrpentium, i just didn't find other way to make it works. i wasted а time (one week), wait rdpwrap updates and then upgraded w10.
I also tryed HEX editor, different term.dll, and it fail.

Well, I am still hoping and waiting for rdpwrapper to work on Home version 15603.  I keep installing and updating the wrapper, but of course, as of now, it doesn't work.  So my question is:  Should I uninstall whatever I have installed?  I see an uninstall.bat file in the directory.....should I use it? Thanks in advance for any advice you can provide.

Hi, I used it on two computers with Windows 10 Home - on both it worked fine before the creators update, but on both it is no longer working since creators update. Both computer are not fresh installations - one is a upgrade from the first Win 10 build and the other is a upgrade from Windows 7 to 10 and then to creators.
Nothing written above seems to work :-(

Thanks a lot for RDPWrap.
It will cost me ￥808 to upgrade my windows 10 to pro edition, which is a lot of money for a undergraduate student. (With ￥799 I can buy myself a new Android Phone)
Hoping and waiting for rdpwrapper to work on Home version.

I see that "RDPWrap-v 1.6.1 Stoped wroking after Windows 10 Creatore Edition 1703 #256" was closed, but it still not working for me. Anybody helps me plz.

Umm, because 256 is marked as a duplicate of this issue and this issue is still open? There's no need for 20 issues that say the same thing.

Is it real to fix for Windows 10 Home 1703?

Hi,
I have the same issue (Surprise!), but this is not the reason of my message.
All the negative messages telling you that something does not work should not hide the fact that you made an awesome work ! Thank you for your work and your time !

I compared System32 files that have "rdp" in their name between Win 10 Home 10.0.15063.0 ("not listening") and Windows Server 2016 10.0.14393 VM (works by default) and it seems that some of the files from Server are missing in Home and most of the dll and sys files have different sizes, both files starting with "term" are also different. If you need those files I can upload them.

Comparing different editions is incorrect strategy. You should compare different builds of the same edition.

I have Windows 10 Home install files on a USB drive, I think it is from before the creators update, I will try installing it on a VM to compare.

I have both a pre and post creators update Home version. What are the files that you want to compare and what comparison? I could possibly forward the files.

Same problem on 15063.

I can confirm, same issue on 15063.

CTRL-F is your friend 👍

A new update broke the work of the PDP.
Many people have a salary of 300-500$ and cant buy a licensed Windows 10 pro (250$) .
Go to ebay, and buy OEM key 2-4$  win 10 pro. All working.
Now i have win10 pro and working RDP, thank you!
Спасибо за проделанную работу, очень крутая штука.

I tried editing termsrv.dll as suggested to no avail. So I used the Recovery option "Go back to an earlier build" which took me back to Version 1607 and RDP wrapper is working again. Of course the first thing Windows does is download the Creator's Update. So for now I won't Install Updates hoping for a fix eventually.

Same issue after updated to version 1703.

Can i do something to help with finding a fix?

Thank you Steklorez.  I did as you suggested and paid $2.08.  I bought from instant-pc-activation on eBay.  I now have Windows 10 Pro and do not need to worry about this going forward.

Is there any progress on this yet?  I am not sure if I missed something with the fix in it.

Nope, still no progress.
When this will be fixed, issue would be closed.

Upgrading to windows 10 pro is a fix.  I paid under $3 for a oem license on eBay.  Cheap and No more worrying about this breaking after windows updates.

@beefsupreme13 can you provide a link to the ebay listing you purchased? I'd like to find another one like it. Thanks.

Excuse me, but this:

Upgrading to windows 10 pro is a fix

... isn't a fix.  It's a workaround at best.  And then this:

can you provide a link to the ebay listing

... is an offtopic.
At the moment we need some Windows debugging skills.
Please stop the noize:)

@chapaj search for windows 10 pro oem.  This is where I bought from, but they don't have any left.
http://www.ebay.com/itm/WINDOWS-10-PRO-32-64BIT-PROFESSIONAL-LICENSE-KEY-ORIGINAL-CODE-OEM-SCRAP-PC/282389196016?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
@sskras relax, your comments helped no one.  Use you skillz to fix the code if you don't want to use an easy cheap workaround that also future proofs the problem going no forward.

And another important point to remember: rdp under Win 10 Pro permits only ONE console application at any time. This prevents you from RDPing into localhost to conveniently open two or more sessions which can be very useful. RDPWrapper conveniently bypasses this limitation.
Again what we need here are coding/debugging skills.

only ONE console application at any time. This prevents you from RDPing into localhost to conveniently open two or more sessions

This is client-side (mstsc) limitation, try using rdesktop or FreeRDP.

You can also use this workaround to enable multiple sessions..
http://woshub.com/how-to-allow-multiple-rdp-sessions-in-windows-10/

@beefsupreme13 Thanks for a great tip

Will Rdesktop or FreeRDP work on Windows Home ?

Go site http://www.vanskeys.com to get genuine windows key here.

Tareiner, stop spam.

I have the same problem with build 15063. I don't know anything about coding so I'm just anxiously waiting for this problem to be resolved - how will we know when the problem is fixed? Do I check to see if v1.6.2 comes out?

Also, I'm not sure if anybody in this thread suggested going back to Windows 8, but that might be an option if you're willing to do a clean install and don't like windows 10.

@binarymaster

@bryang22 what?

@binarymaster Sorry - I meant to say:
"I have the same problem with build 15063. I don't know anything about coding so I'm just anxiously waiting for this problem to be resolved - how will we know when the problem is fixed? Do I check to see if v1.6.2 comes out?"
thanks for your work

how will we know when the problem is fixed?

Read this comment: https://github.com/stascorp/rdpwrap/issues/194#issuecomment-314722315

@binarymaster Just wondering, would donating money to this cause speed up fixing the problem? I personally wouldn't donate a significant sum, but a couple of people's beneficiaries together would be remarkable and might motivate the developers to speed up the process a bit.
Or maybe I'm mistaken and already the developers are working at full speed.
I really can't seem to find any other free alternative to RDP wrap.

I have the same problem with build 15063.

For anyone not already aware of it, VNC such as the open-source TightVNC may be a reasonable workaround while waiting for a fix for this. You'd need to install it on both machines as it's a different protocol from RDP. TeamViewer is another popular option which may be easier to use than VNC.

For anyone not already aware of it, VNC such as the open-source TightVNC may be a reasonable workaround while waiting for a fix for this. (...) TeamViewer is another popular option which may be easier to use than VNC.

Unfortunately these options, while very useful, do not allow you to open a true remote session , they only provide "remote control" i.e. let you use the computer as if you were sitting in front of it.
Afaik, the Windows remote desktop is the only tool that will let you initiate a remote session. If there's another tool that offers this functionality, I'd be glad to know!

I agree with @ogerardin. @ivorget , if you find TightVNC or TeamViewer to be a reasonable workaround, go for it. I just find the VNC to be quite laggy (for gaming).
So what is this "afaik" remote desktop tool? Could you comment the link? Thanks.

Afaik = As far as I know.

@ogerardin (and others who may be interrested): I used to control two of my boxes -- those set up with Win10 home edition -- via binarymaster's excellent RDPwrapper, that's how I landed here.
Unfortunatelly, I upgraded one of them to the so called 'Creators Update' (Version 1703, build 15063.483) which, I suppose, is true for most of my help searching comrades here on github. And to make things worse, after the upgrade I immediatelly deleted the old version of Windows 10 -- C:\Windows.old and C:\Windows10Upgrade -- for space reasons, prior to check all functionality I needed. So in the end, on one of my boxes I was not able to revert to a state allowing a RDPwrap to 'wrap' things as it used to do.
To make a long story short ;), I had to search for an alternative solution until my coding hero binarymaster is able to find a solution. Being familiar with almost every 'remote control' software there is for ages, both professionally and in private, and in need of a solution that crosses OS boundaries, and being aware that TeamViewer now runs under surveillance of Britain's GCHQ, I finally bumped into AnyDesk (anydesk.com).
It's free for private/ hobbyist things, it's cross OS(ed), it's fast, and it avoids traffic leaving your own network; if wanted/ needed. Last, but not least, by installing a Windows service on the target machine -- my unfortunate Windows 10 home box running the 'Creators Update' Version 1703, build 15063.483 in the example mentioned above -- you can 'RDP' into the target machine without any hassle and do whatever you need to do (as an Administrator).
However, there is a limit in the free version: one instance into one machine at one time. Anyway, it suits my needs in the meantime.
HTH, Frank.

@efferle Anydesk looks fine, but does it let you open a remote Windows session? I.e. if a user is logged in and using the computer, can you open a second concurrent session without interfering with the local user's session?

Same problem after reinstalling my windows 10 home on new drive

@ogerardin: I am afraid no. You can't establish a 'new' session in terms of functionality a typical terminal server software would offer. That reads, if a user 'Bob' is already logged in on the target box -- the machine you'd like to control -- you'd have to use Bob's credentials to use his session/ environment. There is no way to open a new session on the target box that allows you to log in as 'Alice' at the same time Bob is working there.
Of course, the Windows built-in functionality of user switching is available -- Bob's session would be halted, and you could work as Alice as long as you need to do so. But again, AnyDesk is just some sort of 'distance-from-your-desk-to-remote-PC' shortener in the first place, it's not a RDPwrapper replacement. or even a piece of terminal server software. Apologies if I made the impression AnyDesk would fit into such a setting.
It's just like a keyboard-, mouse-, and display-extender for machinery located on the other side of the city/ country/ or your office located on top of New York's Empire State Building, while your PCs are in the basement -- and all the elevators are shut down due to maintenance work. ,)
Again, sorry for any confusion I may instilled.

Dear @binarymaster.
after reading this long long thread, post after post i can clearly say there is not a fix yet :)
Can you tell us (Please) from 1 to 100 - how much % you already "Cracked"..
saying to people you are 40-50-60-70 % done will give us hope.. and hope is the only thing we have now my friend.
Thanks buddy! :-)

For those for whom the extra effort is worth it, you can go back and do a clean install of 1607.  ISOs are catalogued here, and per the site the actual download links are from MS and will pass MD5 checks.  You'll still need your own valid product key to activate, unless re-activation of prior valid license is automatic upon recognizing your hardware.
http://windowsiso.net/windows-10-iso/windows-10-anniversary-update-1607-download-build-14393-0/
I don't think the Win 10 media tool lets you choose an ISO to create a USB installer, but the old Win 7 tool will and will successfully make a Win 10 installer USB.
https://www.microsoft.com/en-us/download/windows-usb-dvd-download-tool

Can you tell us (Please) from 1 to 100 - how much % you already "Cracked"..

Actually 0%, because I have no idea what exactly changed in termsrv logic since build 14997.

Hi
I am not a developer but i notice that when i open the "termsrv.dll" with 7zip i notice a change on only 3 files.

I am not sure how to dig more in, and even if it will help to get a fix.
Thanks

@efferle well yes I had some hope, but actually AnyDesk is just a rmote control solution just like TeamViewer or VNC... So no concurrent remote sessions :(

@ogerardin: Right, sorry for any disappointment I might have caused.
It seems there is a (commercial) reason why binarymaster's efforts to allow "terminal servicing" on the low end/ price Windows 10 (Home Edition) has come to some sort of an end: it did suit the needs of the 'average Joe'.
I suppose that is one (or the most important?) reason why Microsoft did change one or two things in respect of binarymaster's efforts. Since these (Microsoft) guys are aware of projects of this scale, I am pretty much sure they did everything they could to circumvent any of binarymaster's approaches to solve the issues regarding "Creator's Update".
And since we all know that this f_cking "Creator's Update (Version 1703)" will be installed by MS-force on all internet connected Home Versions sooner or later, we might seek for alternatives, in some way. Be it by change in doing things, be it by change of operating sytems, be it by 'anything else'.
Given binarymaster's last answer to a well driven question raised by porear, I definitely, and personally, have no hope that he -- my coding hero binarymaster -- will be able to manage MS torpedoing the/ his project.

I am monitoring this thread for quite some time now and I think efferle is right about the situation. MS might have removed some files/processes from the latest build to break rdpwrapper. Technically it should be possible to compare the new situation to the old one and reverse the change made. It might be needed to (re)use some components from other/earlier builds but it would mean a license violation. I am not sure if binarymaster wants to do this. It would be nice if he could give us clarity on this. If he decides to stop further development I would perfectly understand that.

@foxpdll writes:

I rollback KB4019472 update and RDP Wrapper Worked for me.
As temporary it is possible to use RDP Wrapper.
Windows 10 Home 1607 14393.1066 32Bit

Posts like that seems very useful!
This info gives me idea to install clean x86 version 1607 (OS build 14393.0), 3.15 GiB.  Then to install cummulative update KB4015217 for x86 (572 MiB) to get the build 14393.1066 used by @foxpdll to ensure the project functionality is OK on another machine too.
In positive case this would give us OS testbed which require only 230.7 MiB size Delta update KB4019472 for x86 to bring it to build 14393.1198.
Now if this breaks the project, installation of 230 megabytes package would be a lot easier to bisect than usual / uncontrolled / unknown online process of updating the OS.
That's the plan I've improvised.  Fingers crossed for finding some time to set up it like that in a VM.

Same problem. I BELIEVE IN YOU GUYS!
(Seriously, please find a fix for this and don't let this project that helped so many people die.)
Thanks for all your efforts!

@binarymaster you mentioned kernel debugging with serial output way back, https://github.com/stascorp/rdpwrap/issues/194#issuecomment-292202816 , i am wondering if this is something you want done still? i have got some time and can play around, but i need som help or pointers to enable the serial output and kernel debug.

@zapy85 see these links:

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/boot-parameters-to-enable-debugging
https://msdn.microsoft.com/en-us/library/windows/hardware/ff542187(v=vs.85).aspx

@binarymaster cool, i actually work a lot with serial communication so that shouldnt be a problem, the versions i should compare is what you commented before i assume?
ill see if i can ge a hold of the isos and install them on an older laptop :)

Compare between 10.0.14986.1000 and 10.0.15002.1001, with and without RDP Wrapper.

@zapy85 it is probably easier to use VMWare player free or VirtualBox for the testing.

yeah, ill see whats easiest to setup

cant seem to find the 15002 build anywhere :(

https://tb.rg-adguard.net/dump.php?seach=15002&str=25&lang=en-US

@l33tissw00t good try but it only gives me " Attention!!!
Generation of links to the software-download.microsoft.com service - is paused. "

http://testmdl.ct8.pl/tb/langs.php?id=284&lang=en-US

cool cool!

@binarymaster btw, what do you mean with with and without rdpwraper? (i assumed i would try the Home edition as thats the one thats having problems?)

@zapy86 I think he means "without and with rdpwrap installed"

@LufyCZ  Home dosnt support remote desktop native, apart from the " Remote Assistance " function thats why i got a bit confused!

Home dosnt support remote desktop native, apart from the " Remote Assistance " function thats why i got a bit confused!

But anyway, the debug log from it would be appreciated.

@binarymaster you on irc or something? iwe gotten so far that windbg connects to the computer, got something that said winterm service etc, but now im not getting it any more :/ could we do a joint effort?

@binarymaster i got this at least, if this is "all" you need (successful connection to 14986
Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...
Connected to target <IP_ADDRESS> on port 49152 on local IP <IP_ADDRESS>.
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows 10 14986 x64 target at (Mon Aug  7 22:36:24.459 2017 (UTC + 2:00)), ptr64 TRUE
Kernel Debugger connection established.
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 14986 MP (1 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 14986.1000.amd64fre.rs_prerelease.161202-1928
Machine Name:
Kernel base = 0xfffff801f221a000 PsLoadedModuleList = 0xfffff801f25247f0
Debug session time: Mon Aug  7 22:36:23.324 2017 (UTC + 2:00)
System Uptime: 0 days 0:06:30.778

Links expire: 8/8/2017 7:18:31 PM UTC
https://software-download.microsoft.com/pr/Windows10_InsiderPreview_Client_x64_en-us_15002.iso?t=c8813332-6b77-4b2a-b66d-1e24277e78d1&e=1502219912&h=be3b8f1062c90bcb0e47e84d07ab42f1
https://software-download.microsoft.com/pr/Windows10_InsiderPreview_Client_x32_en-us_15002.iso?t=c8813332-6b77-4b2a-b66d-1e24277e78d1&e=1502219912&h=03b2f382b44dd4da8cfcdec486c2a7dd
https://software-download.microsoft.com/pr/Windows10_InsiderPreview_EnterpriseVL_x32_en-us_15002.iso?t=dd113cfb-1ecf-424e-be6c-b35649d6e570&e=1502220122&h=8ddc329d7d09a8241cd1c898045088d6
https://software-download.microsoft.com/pr/Windows10_InsiderPreview_EnterpriseVL_x64_en-us_15002.iso?t=dd113cfb-1ecf-424e-be6c-b35649d6e570&e=1502220122&h=a4cde6a00d110ef1e7224c2adbac2e3b
Thanks to @LostED over at MDL.

Here's a fun fact.
I had an intel NUC which came with an included win 10 home licence in the wild with RDP wrapper and clearly was in the same boat as everyone else.
Here's the fun part
You can upgrade Windows 10 home, to Windows 10 pro, using a Windows 7 Pro key.
I expect you can do the same with a windows 8 pro key.
howto:
Go to the store. Search for windows 10 pro.  Choose the enter your own key option and throw in the win 7 pro key, and it upgrades.
You heard it here first

OS BUILD :- 15063.540
VERSION :- 1703 (WINDOWS 10 HOME)
Is there any fix to this or any alternative method?

I found Thinstuff XP/VS Terminal Sever for Windows ( http://www.thinstuff.com/products/xpvs-server/ ). It looks like great alternative to RDPWrap. And, it works :) (see screen from RDPWrap conf). and it is cheaper than Windows 10 Pro https://www.thinstuff.com/licensing/index.php?selected_product=16;14;15

@binarymaster, What @psimkovic says can help you, if you enter the page
(https://www.thinstuff.com/products/rdh/) you can see a note to the right [New version of RDH! Windows compatibility 10 1703 Jun. 26, 2017 Version 1.0.840Registering Changes] If you check the package maybe you can find something that can help you.

@binarymaster +1 from me after creative edition update.  Running services 10.0.15063.0 with wrapper <IP_ADDRESS> with windows Version 1703 (os build 150634.483).  Also, I recommend everyone in this thread send Binary a cold beverage of his choice for all the headache he has to go through to fix this :-)
Till then, I dug out my ancient but still working kvm switcher and I'm good for now.

You could get windows 10 without a product key. Just download and install the windows 10 ISO file from  . The inconvenience is that there is an "Activate Windows" watermark in the bottom-right corner and that you cannot personalize your computer. It's could be kind of annoying, but it's not too bad.

Would using an older build of termsrv.dll help?

@markyi370: Somebody already tried it, and it didn't work

Try this file :rfxvmt.zip.
Unzip it into the C:\windows\system32 folder.
Reinstall rdpwrap.

Do we all owe @youjoy a massive thank you?!?

@youjoy just a heads up, that fix also works with windows build 16251.

Hi all
The fix from @youjoy does not works for me ;-((

it works ................and many thanks to all
BUT using MSTSC to connect somewhere else, the remote screen is not resized as it was before.
May be I neeed to investigate but your solution works.
BR

SORRY your last DLL works perfect (and connections to all W10 computers are Ok now).
Congratulations

@youjoy: It seems I have to extend my personal hall of heroic coders. ,) Works perfectly on my problematic box I mentioned earlier in this thread. What a beautiful experience this is, just minutes before lunch on this sunny sunday afternoon here in the middle if Europe. Thank you, and may the force bless you for your efforts, you really made my day. ,) A million hugs to you.
@astro075: Did you reboot your box? It turned out for me that this was neccessary after hitting RDPWrap's uninstall.bat and before running install.bat again.

@efferle
Yes i tried many times. And i did an unsinstall-reboot-install-update (all this with "Run as admin".
But no way :-((

@astro075: Sorry to read this. And please don't get angry with by repeating what I actually did, just a couple of minutes ago to finally succeed using youjoy's solution.
I myself was a happy RDPWrap v1.6.1 user on two of my PCs running Windows 10, 64-bit, Version 1607 (Build 14393.1593) Home Editions, determined by Start -> Run -> winver -> Enter. A couple of months ago, I upgraded both machines by accepting Microsoft's "Good news! The Windows 10 Creators Update is on its way." dialogue shown by Windows-key + I. Stupid, I know, to upgrade both boxes prior to check all functionality I needed. However, on one machine I could revert the upgrade, but on the other I couldn't because I deleted all relevant files and folders due to space reasons.
In the meantime -- until today's revelation delivered by youjoy -- I helped myself out by using AnyDesk, a remote access software similar to TeamViewer which I used in the past; until I learned by Edward Snowden, Wikileaks and a few other publications, it's the prefered SW used by Britains GCHQ for intercepting remote stuff. ;( But I think I get off the track. ,)
So after waking up today I checked my inbox, downloaded rfxvmt.zip, asked for some help from my older pal virustotal.com -- please don't get that wrong, youjoy ,) --, ran RDPWrap's uninstall.bat, renamed the original rfxvmt.dll to rfxvmt.dll.org, copied rfxvmt.dll to %windir%\system32 -- NOT to the other locations where it is available, like %windir%\SysWOW64, %windir%\WinSxS, and the like -- rebooted the PC, ran RDPWrap's install.bat again and voilà, RDPConf.exe worked the way it was developed by binarymaster.
Finally, I closed the remote session I used to establish by alternative software AnyDesk, opend a regular mstsc.exe dialogue from my source machine and voilà again, my problematic Windows 10 Home Edition, 64-bit, Version 1703 (Build 15063.540) aka Creators Update was connected the way it should.
Again, don't get angry with me because of this post, I just wanted to give a possibly helping hand in case you skipped or missed a file or folder or something. Anyway, good luck, I'll keep my fingers crossed.

Thanks a lot, it worked for me too
@astro075, "Run as admin" is not required, uninstall & reinstall, you don't need to run scripts as admin.

Hi
I am not angry at all. Don't worry about that.
I tried everything even not used "run as admin".
No way, listener is not listening...
Maybe I have a firewall problem.
But thanks at all for your help

From: efferle<EMAIL_ADDRESS>Sent: Sunday, August 20, 2017 2:03:17 PM
To: stascorp/rdpwrap
Cc: astro075; Mention
Subject: Re: [stascorp/rdpwrap] Listener is not listening on Win 10 Home (build 14997+) (#194)
@astro075https://github.com/astro075: Sorry to read this. And please don't get angry with by repeating what I actually did, just a couple of minutes ago to finally succeed using youjoy's solution.
I myself was a happy RDPWrap v1.6.1 user on two of my PCs running Windows 10, 64-bit, Version 1607 (Build 14393.1593) Home Editions, determined by Start -> Run -> winver -> Enter. A couple of months ago, I upgraded both machines by accepting Microsoft's "Good news! The Windows 10 Creators Update is on its way." dialogue shown by Windows-key + I. Stupid, I know, to upgrade both boxes prior to check all functionality I needed. However, on one machine I could revert the upgrade, but on the other I couldn't because I deleted all relevant files and folders due to space reasons.
In the meantime -- until today's revelation delivered by youjoy -- I helped myself out by using AnyDesk, a remote access software similar to TeamViewer which I used in the past; until I learned by Edward Snowden, Wikileaks and a few other publications, it's the prefered SW used by Britains GCHQ for intercepting remote stuff. ;( But I think I get off the track. ,)
So after waking up today I checked my inbox, downloaded rfxvmt.zip, asked for some help from my older pal virustotal.com -- please don't get that wrong, youjoy ,) --, ran RDPWrap's uninstall.bat, renamed the original rfxvmt.dll to rfxvmt.dll.org, copied rfxvmt.dll to %windir%\system32 -- NOT to the other locations where it is available, like %windir%\SysWOW64, %windir%\WinSxS, and the like -- rebooted the PC, ran RDPWrap's install.bat again and voilà, RDPConf.exe worked the way it was developed by binarymaster.
Finally, I closed the remote session I used to establish by alternative software AnyDesk, opend a regular mstsc.exe dialogue from my source machine and voilà again, my problematic Windows 10 Home Edition, 64-bit, Version 1703 (Build 15063.540) aka Creators Update was connected the way it should.
Again, don't get angry with me because of this post, I just wanted to give a possibly helping hand in case you skipped or missed a file or folder or something. Anyway, good luck, I'll keep my fingers crossed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/stascorp/rdpwrap/issues/194#issuecomment-323580706, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AbUlEHWTzsmV8CMSSfEu0JBZvXX7LnNHks5saCCEgaJpZM4LjrPS.

have  you tried to run "update"  after reinstall ?

Yep i did...

it's strange, even if you had a firewall that blocking connections,  you should be able to run rdpcheck and rdpconf must shows listener state listening

@youjoy  thank you so much....that fixed my problem on Windows 10 Home/Version 1703/Build 15063.540

It's great job but...
I would like to try but how can I probe that  rfxvmt.zip is safe to install. (No virus or no malware are in  rfxvmt.zip.)
Am I too scared?

@zefimia virustotal https://www.virustotal.com/#/file/32ff81be7818fa7140817fa0bc856975ae9fcb324a081d0e0560d7b5b87efb30/detection

@zefimia, the rfxvmt.dll file in it is a file readily available in any Windows 10 Pro computer.
I compared the hashes and this one is identical to the original in Windows Pro. And if you have a Windows Pro available you can copy it yourself from there.

@YisroelAdler rfxvmt.dll is present in my one machine with windows home that does not have the creators update. Can anyone with the update installed check the windows.old and see if it's present in there?

@BiteByteBit it is not in windows.old on my device. But is the rfxvmt.dll in the system32 folder and is it the same file then this one? Becuase I found it in the WinSxS folder (basically not used) on my Windows with Creators Update, but it is a much smaller file.

oops.
Thanks for very quick reply. :)
I've win10 pro machine, which upgrade from win7 ultimate,  and I check the sha1sum to the rfxvmt.dll in rfxvmt.zip and it's match.
rf)Sorry for not Engligh but Japanese.
PS C:\Windows\system32> certutil -hashfile c:\windows\system32\rfxvmt.dll
SHA1 ハッシュ (ファイル c:\windows\system32\rfxvmt.dll):
81d4ad81a92177c2116c5589609a9a08a5ccd0f2
PS C:\Uers******\Downloads> certutil -hashfile .\rfxvmt.dll
SHA1 ハッシュ (ファイル .\rfxvmt.dll):
81d4ad81a92177c2116c5589609a9a08a5ccd0f2

Great work -- so nice to see real progress!  But when I run RDPCheck, my logon screen comes up and I enter my password, I get "Access Denied."  If I enter the wrong password, I get the prompt to try again.  When I try to access from another device, I don't even get the logon screen.  Any ideas?

@YisroelAdler rfxvmt.dll on the left is from my windows home machine that was not updated and the one on the right is from @youjoy 's zip. I tried the wrapper with both and both work on my windows home machine that has been updated.

Hey thanks! Now it works.
I takade the rfxvmt.dll file from my other 10 home machine that is (extra because of that) not yet updated.
Uninstall rdwrap, install rdwrap and update. Now is the listener listening!
Works great now! Youpie!

Well, I just went back to my old rfxvmt.dll in place of the one provided by youjoy and am seeing the same behavior.  It says the listener is listening but apparently not hearing anything.  Am I missing something?

+1 on the fix from @youjoy above.  I did not have that file on my machine before I installed, so I just dropped it in, uninstalled, re-installed, updated, and poof, back to working as expected.  Thank you @youjoy !

Yeah, really great work. Ist DOES work on my maschine that did not had the dll before. But on a second one, which had the dll already in place, it DOES NOT work. Replaced the dll, uninstalled/reinstalled rdpwrap but no way. :(

So now just add this dll to the package, and maybe add a bat file to install it.
Maybe it possible to get a fix in the code

@PortlandPaw just disable "Single session per user"

@astro075: Yey, I knew you'd finally make it. ,)
@98jbsz: I am afraid it's not that simple for binarymaster to make this happen. As this problem resolving DLL provided by youjoy is an intellectual 'property' of Microsoft -- as you can see via Window's own property dialogue -- any distribution of it without proper legal permission would result in a copyright violation/ infringement; including all possible penalty charges.

Is the dll different on 32 and 64 bit systems? It works for me on my 64 bit maschine but not on my 32 bit...

@LufyCZ -- Thanks, but that didn't do it.  I can no "logon" from RDPCheck (i.e. get past the logon screen), but it's still not visible from external devices, on or off the network.

I verified the given file against one that I had on my Win 10  pro 15063
installation and upon finding it same copied the latter to the machine I
wanted fixed. Subsequent rdpwrap uninstall, reboot, install and update
later, it started working as before.
@youjoy, Thank you for finding this workaround/fix. I want to hope that
things do not change after further windows updates...
On Sun, Aug 20, 2017 at 1:12 PM, youjoy<EMAIL_ADDRESS>wrote:

Try this file :rfxvmt.zip
https://github.com/stascorp/rdpwrap/files/1236856/rfxvmt.zip.
Unzip it into the C:\windows\system32 folder.
Reinstall rdpwrap.
[image: 2017-8-20 13-10-33]
https://user-images.githubusercontent.com/785060/29492268-2d01c42c-85a9-11e7-9835-0eefb524fcbc.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stascorp/rdpwrap/issues/194#issuecomment-323564111,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcvkrAb7PeUOX6BmF-sR3Q4hFjIsbhdUks5sZ8BEgaJpZM4LjrPS
.

also works on 10.0.16257.1
@youjoy thank you so much!

Nice catch @youjoy . Anybody concerned about the origins of rfxvmt.dll can locate their own copy from a Windows 10 Pro workstation (including Creator's Edition) in the %SystemRoot%\System32 directory. The problem this whole time hasn't been with RDP Wrapper at all. Microsoft re-wrote the remote desktop functionality to include this new system DLL, and made sure it was absent on Home Edition versions of Windows. @binarymaster , I suppose this will have to be a new file to keep an eye on with subsequent MS Windows updates.
I was able to successfully "patch" my Home Edition by uninstalling RDP Wrapper, copying rfxvmt.dll to my C:\Windows\System32 directory, updated the security settings to match the other DLL's in this folder, then re-installed RDP Wrapper. No reboot necessary. Perhaps other people only got this to work because the OS corrected the permissions automatically after a reboot.
To manually set the permissions after rfxvmt.dll has been copied (not Moved) into the System32 directory:

Go into 'Properties' for the file, select the 'Security' tab then select the 'Advanced' button, select 'Change Permissions' button, disable inheritance and have the existing inherited permissions converted to explicit permissions. It's okay to apply these changes at this point.
Changing the file ownership to TrustedInstaller. To do this, click the 'Change' link net to the 'Owner' filed and enter NT Service\TrustedInstaller. It's okay to apply this change at this point.
Add 'NT Service\TrustedInstaller' with 'Full' permissions; edit 'Administrators' and 'SYSTEM' permissions by ensuring they're each only granted 'Read & execute' permissions.

highlight SYSTEM, select the 'Edit' button, select the ling to clear all permissions, put the checkmark next to 'Read & Execute' then select okay.
repeat for 'Administrators'

OK your way out of the file permissions and properties for the file and re-install RDP Wrapper
Voila!
Kudos again to @youjoy for their find and to @binarymaster for enabling this wonderful enhancement to Remote Desktop functionality on all Windows workstations. I'm so happy, and good luck to the rest of you.

@MadDog927ca
Thanks for having a look on the fike permissions. I already thought that it may not work if they are wrong. Corrected them, re-installed RDPwrap (rebootet between), but still "not listening"...

Anything wrong with my permissions?

@bombcheck: I see some difference to my 'Advanced Security Settings' tab on my Win 10 Home Edition box that had problems until youjoy fixed it by providing the DLL. Sorry for providing no picture, but I can see you're on a German Windows, and mine is in Hebrew, so I spare you the 'cryptics'. ,)

SYSTEM: mine has Full control, which oviously translates to Vollzugriff. You got Read & execute (Lesen, Ausführen);
Administratoren: mine has Full control, too, you got Read & execute again;

These are the differences to my box, as I can see.
HTH, efferle.

Hello,
Can anyone post a 32-bit version of the rfxvmt.dll file? I have this problem on a 32-bit system and no other 32-bit systems to copy the file from.
Tnx in advance!

@efferle
Thx for your post. But I THINK my permessions are correct. Checked with the untouched workstation in my office: They are equal.
I may be an issue with 32/64bit as the provided dll  does only work (for me) on 64bit systems...

@bombcheck: OK then, was just comparing your posted file permissions on your not-so-good-working machine to mine, which runs perfectly again after months. ,)
»Nichts für ungut«, as your saying goes. ,)

@efferle
You're welcome. :)
Will set up an w10 pro x32 vm and extract the dll from there. Can somebody confirm please: Update the os to latest patch level and THEN copy dll from there?

FINISHED. Use the attached dll file for your 32bit windows 10 home systems. Please restore file permissions as MadDog927ca pointed out.
rfxvmt.zip

@bombcheck
Thank you very much. Works like a charm!


Check smithy traits

Check all smithy traits to see if they have an implementation in both smithy-swift and smithy-kotlin
internal id: 172587851

Nullable struct generation


Truncate dids in message log

The long DIDs kind of dominate the log, making it difficult to see the message itself.

Or just let the overflow-x scroll instead of wrapping.


People are too willing to slap on allow-2119

Currently if you use a disallowed RFC 2119 keyword in a non-normative section, you get this error:
RFC2119 keyword in non-normative section (use: might, can, has to, or override with ):
I've seen a lot of people just go straight for that last option, not seeming to understand that this rule is there for a good reason, and that exceptions are meant to be very rare.
My best suggestion is that "we" (me, probably?) puts together some documentation about this somewhere, and then we expand the error message to link to it. And maybe even we remove the quick-fix from the error message? So it becomes something like:
RFC2119 normative keyword in non-normative section. Use a synonym, or learn more at https://speced.github.io/bikeshed/#accidental-2119, including workarounds for exceptional cases.
And here's a draft of what that documentation could look like:

A key aid to specification clarity is the distinction between normative requirements and informative notes, examples, and explanations. An important way to signal normative requirements is using the RFC 2119 keywords, "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "not recommended", "may", and "optional". See more discussion of these keywords and their usage in Infra.
Using these keywords in a context marked explicitly as non-normative is confusing spec-writing. The reader becomes unsure whether you are intending to communicate a normative requirement, hidden inside a non-normative section, or whether you are having a non-normative discussion with false precision.
This issue is usually best resolved by using synonyms that have not been given the same magical normative status: e.g., "can" or "might" instead of "may"; "has to" or "will" instead of "must"; "will likely" instead of "should", etc.
In rare cases, this check misfires. For example, when talking about the month of May in an example, or when talking about the optional Web IDL keyword in notes, or when giving a warning about how an older spec required something but modern specs intentionally contradict it. For such rare cases, you can override this check by adding  around the offending keyword, or an ancestor element of it.

Thoughts or refinements? I can try to work on a PR implementing the above if you agree.

I've seen a lot of people just go straight for that last option

Are you seeing this in published specs in the wild, or is it something you tend to catch during review?
Either way: SGTM. And I appreciate the "using synonyms" guidance in the proposed documentation.

Are you seeing this in published specs in the wild, or is it something you tend to catch during review?

It's something I tend to catch during review, but it looks like a few have slipped through: https://github.com/search?q=org%3Aw3c allow-2119&type=code

This looks good to me, I'm happy to have the workaround be pushed further into the docs rather than presented in the error message. PR welcome!


Skip converting malformed OWL expressions to relationships (7.x)

Do not convert OWL expressions where the referenced component was selected against the rules of the
OWL Editorial Guide
https://snowowl.atlassian.net/browse/SO-4949

Changes were merged to 8.x as part of PR https://github.com/b2ihealthcare/snow-owl/pull/922.


OpenType Fonts?

Hello,
I would like to use New York 36 for a personal project, but there are ony images here. Do you have an OpenType Font file (.otf)? Thank you for any help.

Hi there, thanks for the note. Unfortunately these are fairly ancient bitmap font files from the 80s that don’t convert to OTF directly. If you like the New York style, it’s essentially a Garamond and there are many modern Garamond style typefaces you can use. If you want the actual “bitmap” look and feel as well, that’s probably not easily available in modern fonts and might require you to just do something bespoke.


Unify all the macOS diff tags

Please select one of the following

[ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
[x] I am making a fix / change for the macOS implementation of react-native
[ ] I am making a change required for Microsoft usage of react-native

Summary
This PR resolves #1579 by doing a few things:

Aligns all of the various diff tags across the repo. The next person who tried to mass-change the diff tags should have a much easier time now that they all match. Discussion for the tag format happened in #1597 and I'm going with a modified version of Option C (I'm using // macOS] instead of // ]macOS for end tags)
Adds a markdown doc page as docs/DiffsWithUpsteam.md to document the format of the diff tags. This should be helpful to new and external contributors to the repo.
Refactors some code to match the above documentation. Specifically, I:

Swapped some ifdef blocks around so that the original iOS code always came first
Made sure that the first #if !TARGET_OS_OSX had a single line tag, while the other #else/#endif had block tags

I did my best to keep this a comment / format only change. To that effect, I did  quite a bit of manual work and triple checking to make sure things are consistent. Because I'm effectively going through every diff in our repo, I did notice many places we can make simple one line improvements / usptream changes / diff removals. I attempted to document as many as I could in the following GitHub project: https://github.com/orgs/microsoft/projects/620 . However, I'm sure there were a few small changes that have snuck into this change as well (removing unnecessary diff tags, unused imports or variables, etc).
Changelog

[macOS] [Fixed] - Unify all the macOS diff tags
Test Plan
There was a lot of manual going through all the tags. And then a second time. And then a third time 🙃. I'm going to trust the CI to make sure I didn't break anything.

i don't know how i feel about this. bracket means pretty different thing in objc so as i read the functions i would be confused.

i don't know how i feel about this. bracket means pretty different thing in objc so as i read the functions i would be confused.

Good point, that might be why we went with the weirder format of " // ]tag" instead of "// tag]". Open to other ideas. I don't expect to merge this for a while...

One issue I have is that it's a lot easier to search for TODO(macOS GH#774) in our code when we're trying to find specific differences between RN-macOS and RN Core. Simply searching for macOS could give us a lot of false positives.

Update on this PR: I'm currently doing a "final" pass through all the files, but obviously that takes time.. I'm at 159/552 . Once I've gone through them all, I'll add a documentation page and mark as ready for review.

Hello, I am dividing this PR into 3 chunks and assigning one to each of the people tagged. Please read the PR Description and the documentation added in 63648a117972414777b3f1aadbb4923189087a92 to get an idea of what has changed and what to look for! 90% of the changes are mechanical, but there is a 10% that includes changes like:

Adding a Github Issue for a diff block
Swapping the iOS/macOS parts of a #if !TARGET_OS_OSX block to match the rest of the repo
Typo fixes

So please keep your eye out for changes like that!
The blocks are as follows:
Chunk 1: up to Libraries/WebSocket/RCTSRWebSocket.m - @lyzhan7
Chunk 2: Libraries/WebSocket/WebSocket.js - React/Modules/RCTUIManager.m
 - @mischreiber
Chunk 3: React/Modules/RCTUIManagerObserverCoordinator.h +  - @chiuam
Thank you again!


docs: add api doc

What this PR does / why we need it?
This PR add some API doc
What is the impact of this PR?
No Breaking Change
PR relation:

Ref #

CI Settings

CI Usage
Tip: Check the CI you want to run below, and then comment /run-ci.
CI Switch

[ ] Web3 Compatible Tests
[ ] OpenZeppelin tests
[ ] v3 Core Tests

CI Description

CI Name
Description

Web3 Compatible Test
Test the Web3 compatibility of Axon

v3 Core Test
Run the compatibility tests provided by Uniswap V3

OpenZeppelin tests
Run the compatibility tests provided by OpenZeppelin, including OCT 1-5 | 6-10 | 11 | 12-15 | 16-19

@driftluo Please release


Server crash: Mod loading error has occurred.

Hello, im getting crashes when loading the latest version of the mod (1.4.14) on Forge 40.0.32. Architectury API version 4.1.35.
The crash log is here
https://gist.github.com/TehFoxFire/e661e742467c4d932ebc5289d0015c1c

Fixed in 1.4.15


implement custom templated launch for sso browser option

What changed?
Custom browser launch templates were added in #731. This PR extends on the work done there to include this functionality in adding custom launch templates for the sso browser launch process.
The current logic added will prioritise a custom SSOBrowserLaunchTemplate being set, then CustomSSOBrowserPath and finally with os default open()
Why?
Fixes/provides a builtin workaround for #602
How did you test it?

Set up custom template for new SSOBrowserLaunchTemplate

[SSOBrowserLaunchTemplate]
  Command = "open -a Safari {{ .URL }}"

Confirmed safari opened correctly when authenticating with SSO.
Potential risks
Is patch release candidate?
Link to relevant docs PRs

I have updated this PR to work more extensively. Specifically I was attempting to use it to solve this issue: #713
I found the adding the following custom browser launch template would not work due to the spaces in "Google Chrome" and the toml reading did not respect the escaping I tried.
[SSOBrowserLaunchTemplate]
  Command = "open -a Google\ Chrome --args --profile-directory=default {{ .URL }}"

I have added a workaround to get this working:
[SSOBrowserLaunchTemplate]
  Command = "open -a \"Google Chrome\" --args --profile-directory=default {{ .URL }}"

Where Granted will now handle anything within quotes as a single argument in the command.


Library code includes app icons

The library build includes app icons, which makes compilation fail for the project which is included into, because of a manifest merger error, as shown below:
C:\Users\Guillermo\...\app\src\main\AndroidManifest.xml:42:9-41 Error:
	Attribute application@icon <EMAIL_ADDRESS>from AndroidManifest.xml:42:9-41
	is also present at [com.robertlevonyan.view:MaterialExpansionPanel:2.0.8] AndroidManifest.xml:13:9-43 value=(@mipmap/ic_launcher).
	Suggestion: add 'tools:replace="android:icon"' to <application> element at AndroidManifest.xml:39:5-244:19 to override.
C:\Users\Guillermo\...\app\src\main\AndroidManifest.xml:45:9-46 Error:
	Attribute application@roundIcon <EMAIL_ADDRESS>from AndroidManifest.xml:45:9-46
	is also present at [com.robertlevonyan.view:MaterialExpansionPanel:2.0.8] AndroidManifest.xml:15:9-54 value=(@mipmap/ic_launcher_round).
	Suggestion: add 'tools:replace="android:roundIcon"' to <application> element at AndroidManifest.xml:39:5-244:19 to override.

Icons shouldn't be included if the project is an Android libary.
Workaround: If you're using this library, and you're affected with this issue, you have to add the following line to your AndroidManifest.xml in your <application /> node: tools:replace="android:icon,android:roundIcon"

+1 for this, how to fix?

tools:replace="android:icon,android:roundIcon"

If I add this, then my icon just turning to my app "Screenshot"!

@strongville well, your solution didn't works for me, but thanks for creating this issue, because I was have a thoughts it's my problem
Have a nice coding week

please use the latest version


fix application setup issues

fix application setup issues

... aaaand this is the result of Angular setup script:

Again, works well when done with separate commands.


import/no-unresolved

I am using the vscode editor and am having problems with eslint validation of false-positive type. My operating system mac os (high sierra).
More details:
Error:
[eslint] Casing of [relative path] does not match the underlying filesystem. (import / no-unresolved)
module "[module path]"

"eslint": "^4.8.0",
"eslint-config-airbnb": "^15.0.1",
"eslint-import-resolver-webpack": "^0.8.3",
"eslint-plugin-import": "^2.6.0",
"eslint-plugin-jest": "^21.2.0",
"eslint-plugin-jsx-a11y": "^6.0.2",

I guess this is related with #720

+1

@xereda Are you opening VS Code from the command line? I've seen this error come up in Atom when I opened a project using by cd'ing using the wrong casing. ea: desktop/projectname vs Desktop/projectname

@Sage911 I open the project from within the vscode.

I'm having the exact same issue with Atom.

Getting the same problem. ./node_modules/.bin/eslint . works fine from command line, but does not work in terminal in Visual Studio Code. Does not work with the ESLint plugin either - all imports in code files are marked with this error.

@pcguru That seems like an issue with VSCode. The only thing that matters is that it works on the command line; anything else is an editor issue.
I'm going to close this; there doesn't seem to be any issue here that's specific to this plugin.

I am seeing this when via command line when running it through a setup similar to how create-react-app works.
We have a project that houses our webpack build alongside our application boilerplate. I was seeing the error in this app as well until I upgraded all eslint dependencies and it has now disappeared.
After creating a new app using the boilerplate (which is CRA compatible), the new application suffers this problem. This occurs when running eslint via the build script (which uses eslint-loader inside of webpack) and also when running via command line (npx eslint src). The plugin inside of Atom is not affected by this issue for some reason.

It report error ✖:
Casing of ./FormCreate does not match the underlying filesystem  import/no-unresolved
/* eslint-disable import/prefer-default-export */
import FormCreate from './FormCreate';

export { FormCreate };

It does not report error ☑:
/* eslint-disable import/prefer-default-export */
+
import FormCreate from './FormCreate';

export { FormCreate };

@yoyo837 please file a new issue.


[Dev] Provides info on new dependencies added #trivial

I finally got around to writing my first Danger JS plugin by extracting the dependency check from Danger this weekend - https://github.com/danger/danger-js/pull/278
Danger should post some info about danger-plugin-yarn the in comments.

Warnings

:warning:

New dependencies added: danger-plugin-yarn.

danger-plugin-yarn
Author: Orta Therox
Description: Provides dependency information on dependency changes in a PR
Homepage: https://github.com/orta/danger-plugin-yarn#readme

Created24 days agoLast Updated40 minutes agoLicenseMITMaintainers1Releases14Direct Dependenciesdate-fns, lodash.flatten, lodash.includes, node-fetch and esdocKeywordsdanger, danger-plugin and yarn

README
# danger-plugin-yarn

Provides dependency information on dependency changes in a PR

Usage
Install:
yarn add danger-plugin-yarn --dev

At a glance:
// dangerfile.js
import yarn from 'danger-plugin-yarn'

schedule(yarn())

Provides 4 separate rules:

checkForRelease - Provides a 🎉 when there's a package version bump.
checkForNewDependencies (async) - Provides npmjs.com and yarn why metadata about new dependencies.
checkForLockfileDiff - Will warn you when there are dependencies or  devDependencies changes without a yarn.lock change.
checkForTypesInDeps - Will fail the build if you add any @types/[x] to dependencies instead of devDependencies.

And exports a default function to handle all of them at once.
Note: async functions like the default one have be to schedule'd by Danger.
Changelog
See the GitHub release history.
Contributing
See CONTRIBUTING.md.

yarn why danger-plugin-yarn output
Has been hoisted to "danger-plugin-yarn"This module exists because it's specified in "devDependencies".Disk size without dependencies: "256kB"Disk size with unique dependencies: "4.11MB"Disk size with transitive dependencies: "4.97MB"Number of shared dependencies: 7

  Generated by :no_entry_sign: dangerJS

👍🏿


reimplement problem of Fourier Transformer Discriminator

1，As shown in Table 1 of your suuplement, patch size decreases(16->8->4).But in the Figure3. of your paper, patch size increase instead(x2 x2).Quite confusing, which?
2, Instead of NCHW format in  CV, NLP takes [batch, sequence lengh, embedding].
Taking [128,4,64,64] as an example, it will go through patch process like below,
[128,4,64,64] ->  [128,4,4,16,4,16] -> [128,64,256(16x16)][B, C, HW] in which 16 is the patch size shown in your Table 1.
[128,4,64,64] -> [128,4,8,8,8,8] -> [12,256,64(8x8)] -> in which 8 is the patch size shown in your Table 1.
[128,4,64,64] -> [128,4,16,4,16,4] ->[12,1024,16(4x4)] ->  in which 4 is the patch size shown in your Table 1.
I think 256(16*16) in  [128,64,256][B, C, HW]   which means all pixel in a single channel patch is the embdding we want.Why do you take 64 as embedding and 256 as sequence length[128, 256, 64][B, HW, C]?
3, maybe naive, but those questions really confuse me, looking forward to your reply.

The input shapes here are (H/P*W/P)C/4, (H/2PW/2P)C/2, (H/4PW/4P)C/4, (1616)*64 The 16 here means 64/4, that is, the patch size is 4, and then the patch size is increased in turn downwards. size, 8 means 64/8, 4 means 64/16.
You can refer to the NIPS 2021 paper "TransGAN: Two Pure Transformers Can Make OneStrong GAN, and That Can Scale Up" for the transformer architecture, which I also mentioned and cited in my paper, and the baseline structure of Fourier Transformer Discriminator is based on this paper.


Event Listeners not recognised and being removed

Test case: https://codepen.io/davidbrooksio/pen/poWxgLB (updated to Reef 11)
Hi
I have a strange issue with drag and drop event listeners. I have set up a store, app and component. The app has some event listeners set up and the component is calling these listeners (please see my test case).
The first listener ( ondragstart ) seems to work okay. The second one ( ondragover ) gives and error stating that my function ( dragover_handler ) is not defined. The third listener ( ondrop ) has been stripped completely from the code.
Should Reef 11 work with the Drag and Drop API? Am I missing something obvious (likely)?
Thank you

I've just rebuilt my app and made a couple of minor changes and now the only listener that remains is the ondragover="dragover_handler(event)". The ondragstart and ondrop attributes are being stripped from the rendered code.
I haven't updated my test case because the current one still shows the issue will but I can if you need me to.

Just so you know, I have added my event listeners to the document and then delegated to the correct html element instead of using Reef built in listeners feature. This seems to work fine.

I believe this is related to this: https://github.com/cferdinandi/reef/issues/148

+1 for a way to handle this so that onclick (for example) is not stripped in the html. It would help for some smooth templating for it to leave those in. Loving Reef so far by the way Chris, nice work.


Push new update for v0.21

I saw you uploaded <IP_ADDRESS> for v0.21, but the last commit seems to be from 19 days ago. Can you push those changes, so I can build them from the source?

Changes only affect client side(lua), you don't have to build them.
They introduce temporary workaround that affect performance, and the issue is caused by new BeamNG bug. We will wait for developers to fix the issue, so I don't want to push this workaround to git

Ah, understood. I see what you mean, and I think I can figure out how that broke based on the patch notes for v0.21. I just was not sure whether something changed serverside as well.
I take it that you are already in contact with the BeamNG then?
I hope they fix it soon, because KissMP is frankly an amazing project 👍