This looks good, can you make the following additional changes

1. Use asset path for

   electron/shell/common/asar/archive_win.cc

   Lines 29 to 37 in d7ef8b7

   	base::FilePath exe_path;
   	if (!base::PathService::Get(base::FILE_EXE, &exe_path)) {
   	LOG(FATAL) << "Couldn't get exe file path";
   	}
   	base::FilePath relative_path;
   	if (!exe_path.DirName().AppendRelativePath(path_, &relative_path)) {
   	return std::nullopt;
   	}

2. Add a unit test that default app.getPath('assets') matches the path where the exe is located path.dirname(app.getPath('exe')) to confirm no-op of this change.

Add a unit test that default app.getPath('assets') matches the path where the exe is located path.dirname(app.getPath('exe')) to confirm no-op of this change.

@deepak1556 I started working on this but then got pulled into other work for awhile.

What I've found by adding some tests is that app.getPath('assets') on Mac returns Electron.app/Contents/Frameworks/Electron Framework.framework/Resources
rather than Electron.app/Contents/Resources. This might make it tricky to reconcile the Mac asset paths without breaking changes, because I believe Chromium looks for resources under Electron.app/Contents/Frameworks/Electron Framework.framework/Resources while Electron looks for resources under Electron.app/Contents/Resources. Fixing these to be consistent would probably require updates to Electron app packagers at the very least, but if any apps are hardcoding resource lookups, they could still be broken if we change resource locations.

Thanks for looking into the tests, if it would make things easier, we can expose the assets key to just windows and linux in this PR. MacOS can be follow-up if there is interest in changing asset dirs for this platform.

My initial comment for tests was also specific to windows and linux since the code paths touched in this PR are specific to those platforms.