I have a macbook air m1. I am developing a projects on Net Core. But i have a problem System.IO.Pipe.
How do I solve this problem ?
I develop this project with my team. My team have Windows 10.
It appears that PipeTransmissionMode.Message is not supported on *nix system.
You'll have to use the stream mode and define message boundary yourself (e.g. prefix the message with length), or use other protocols like UDP for communication.
Related
Specifically, I have single platform version 2.1 with single device version 2.0 and I want to use C++14 features which supported only in OpenCL 2.1. Should I be able to? What matters when it comes to capabilities limitation: platform or device? What's even the point of platform version since it always comes down to using device anyway?
What's even the point of platform version since it always comes down to using device
anyway?
Platform = version of the codebase and API etc.
Device = Capabilities of the hardware.
The sense is that a platform update may change the way you write your code USING the API, while the device capabilities may change with the hardawre chip.
I'm doing Windows based testing using Winium.
How is winium.storeapps different to winium.desktop? How either of these can be integrated with Selenium?
One is for Mobile and the other one is for Desktop applications. Both are based on WebDriver protocol (old spec called JSON Wire Protocol) and can be used with Selenium bindings. One can think of Winium drivers as one of the implementations of WebDriver, just like ChromeDriver or Appium are implementations of WebDriver.
Winium.StoreApps is a selenium-based tool for testing applications on
Windows Phone/Windows Mobile Emulators.
Winium.Desktop is a
selenium-based tool for testings desktop applications on Windows
Desktop.
We are currently finishing merging Winium.StoreApps and winphonedriver, next step will be to rename it into Winium.Mobile, so that there is no confusion.
UPDATE We finished merging drivers. Now we have Winium.Mobile and Winium.Desktop
Disclosure: I am the author of Winium.StoreApps.
We are converting directx9 to directx10 and we are getting an error: Cannot open include file :dplay8.h .
Please provide the solution how to resolve this and also the steps that might required to convert from directx9 to direct10.
DirectPlay is a deprecated legacy component. The last version of the legacy DirectX SDK to include the headers for it was August 2007. See DirectX SDKs of a certain age. It is not available in any Windows SDK.
It exists in the Windows operating system today for appcompat only. There are a number of important limitations to keep in mind:
DirectPlay Voice is not supported on Windows Vista or later operating systems. See KB970978
The NAT helper object is unsupported on Windows Vista or later
On Windows 8.x and Windows 10, DirectPlay is an optional Windows feature so it's not present by default. It has to be enabled by the user.
In short, you shouldn't use it. You should plan to rewrite the multiplayer support for that porting project, or strip it out.
DirectPlay's primary value was back when networking was a complex and evolving world: modem play, head-to-head serial ports, IPX/SPX, TCP/IP over modem, and TCP/IP. At this point TCP/IP is the only network solution that matters so using WinSock directly is far preferable. There's are also a number of security implications around use of UDP (datagram) vs. TCP (virtual circuit) that modern games need to take into account. The lobby mechanism of DirectPlay is also woefully outdated.
There are numerous modern game services (such as Xbox LIVE, Valve's Steam, etc.) that are designed to provide the match-making, NAT-traversal, and other features that are essential to modern multiplayer. You use WinSock in combination with service-specific libraries.
In a related note, there is absolutely no reason to use DirectX 10. DirectX 11 supports much more hardware, is supported on all the same operating systems (Windows Vista SP2+), and has numerous replacements for legacy support libraries that don't exist for Direct3D 10.
I have a telecom desktop application(EMS) developed in java Swing. Its an old application developed and maintained in swing from last 10 years. Now we are planning to update GUI pages using javaFX technology for better and clean look & feel.
I had gone through various stack overflow discussion stating difference between javaFX and Swing. Please someone help me to understand the challenges in upgrading to javaFX GUI considering below constraints:-
-Application needs to be deployed in Unix, Solaris, HPUX, MAC and window 7/8 OS
-Some third party jars are also used along with JRE
-Current supported JRE is java 7
-There could be a plan to support android/apple/blackberry handheld devices
-We are not using Database for persistence but live data to display.
This answer is based on the detailed constraints of the question and is not a general comment on Swing to JavaFX ports. Parts of this answer will inevitably get outdated, perhaps fairly quickly.
Given your constraints, you can't upgrade your application to JavaFX.
Solaris and HPUX are not supported deployment platforms for JavaFX and that is unlikely to change.
The only way you could get JavaFX to work on Solaris or HPUX would be to use an unsupported configuration such as running a VirtualBox VM on Solaris or HPUX as the host OS, and in the VM run a supported OS, such as RedHat 6 or Oracle Linux 6, then running your JavaFX application within the supported OS - this may or may not work.
Also, I think it unlikely JavaFX would be ported to run on blackberries any time soon. There are ports of JavaFX to other mobile platforms, and they work for simple applications. I haven't tried them and think of JavaFX applications targeting such ports as a bit experimental at this stage. Such ports do not execute on an Oracle JVM and JRE, so if you use external libraries they have to be compatible with the port runtime (e.g. the Android Development Kit, RoboVM libs etc).
If you ported parts of your application to JavaFX, I would recommend running on a minimum of Java 8 rather than Java 7. Many bugs were fixed and many new features were implemented in JavaFX for Java 8. In particular for a Swing->JavaFX port, the integration capabilities of JavaFX and Swing were improved in Java 8 with SwingNode. To help ensure your target systems have the correct runtime installed you can package your application with an appropriate JRE as a self-contained application.
Of course, if you can relax your constraints a bit, there are many positive points for JavaFX.
I have recently gained access to a Mac. I am wondering if anyone has any tips/advice for setting up Mono on a mac for development and execution of ASP.NET? Most resources point to Linux implementations which tend to differ a lot from the way Mac's do things. Any tips or advice would be helpful
To launch the development ASP.NET server, just open a terminal window and run the "xsp2" command from the Mono installation.
The only thing that is missing from the Mono distribution on the Mac compared to Linux is the Apache module, that one you will have to compile yourself if you want to deploy your application in production on OSX.
Since I first worked with mono osx, they've added Cocoa# and ObjC#, but the ASP.NET core was pretty solid (about 3 years ago). You can in fact write web applications according to the Onion book, and port 'em to IIS with little or no difficulty.
Honestly if you want to run ASP.NET you probably don't want to struggle with getting it to run via mono on MacOS. Intel-based Macintoshes can boot Windows, and Apple provides Windows drivers for their various devices as part of Boot Camp.
Alternately you can buy Parallels or VMWare Fusion for less than $100. I use VMWare Fusion. There is also a Mac version of VirtualBox from Sun which is free, though I have never used it.
For MacOS development (not .Net) you really should try Apple's XCode. It is free. It primarily focuses on Objective C though Python, Ruby, and other languages can be used to develop native Mac applications.
Edit 9/22: I'm sorry neither you nor Kev found this a useful answer. Let me try to expand a bit: the Macintosh has a long history of software being ported in from Windows, applying a theme to make the GUI elements look Mac-like but otherwise being content with a minimum cost port. Such software never behaves like a real Mac application: it doesn't respond to AppleEvents, it won't be scriptable, it handles only the cross-platform clipboard formats, etc.
You're free to do whatever you want, including running ASP.NET using mono. If its for your personal use, knock yourself out. However if you're considering it as a way to offer your web-enabled product in a Mac version, I urge you to reconsider. The Mac market has for the most part rejected such products. You'll get some sales, but nothing like you would get for an app which behaves like a native Mac application.
Now, let the down-voting continue.
You can also run ASP.NET via NGINX - easy to install using:
sudo brew install nginx
See installation tutorial: http://www.robertmulley.com/tutorial/nginx-install-and-setup-mac-os-x-mavericks/
See configuration steps for your app: http://www.mono-project.com/docs/web/fastcgi/nginx/
(Note: see my pull request as the fastcgi-mono-server4 should now be used - https://github.com/mono/website/pull/82/files)
Why use Mono on a Mac? Run Parallels, VMWare, or Boot Camp.